OK, I think it's time to make an official place on the internet for this problem: How to make a UIScrollView photoviewer with paging and zooming. Welcome my fellow UIScrollView hackers.
I have a UIScrollView with paging enabled, and I'm displaying UIImageViews like the built-in photos app. (Does this sound familiar yet?)
I found the following project on github:
https://github.com/andreyvit/ScrollingMadness/wiki
Which shows how to implement zooming in a scroll view while paging is enabled. If anyone else tries this out, I actually had to remove the UIScrollView subclass and use the native class otherwise it doesn't work. I think it's because of changes in the 3.0 SDK relating to how the scroll view intercepts touch events.
So the the idea is to remove all the other views when you start zooming, and move the current view to (0, 0) in the scrollview, updating the contentsize etc. Then when you zoom back to 1.0f it adds the other views back and puts things all back in order.
Anyway, that project works perfectly in the simulator, but on the device there is some nasty movement of the view you are resizing, which looks like it's caused by the fact we are changing the contentsize/offset etc. for the view being resized. You have to do this view moving otherwise you can pan left through the whitespace left by the other views.
I found one interesting note in the "Known Issues" of the 3.0 SDK release notes:
UIScrollView: After zooming, content inset is ignored and content is left in the wrong position.
This kind of sounds like what is happening here. After zooming in, the view will shift offscreen because you have changed the offset etc.
I've spent hours on this already and I'm slowing coming to the sad realization that this just isn't going to work.
Three20's photo viewer is out of the question: it's too heavy weight and there is too much unnecessary UI and other behaviour.
The built in Photo app seems to do some magic. If you zoom in on an image and pan to the far edges, the current photo moves independently of the photo next to it which isn't what you get when trying this with a standard UIScrollView.
I've seen discussion about nesting the UIScrollView's but I really don't want to go there.
Has anybody managed this with the standard UIScrollView (and works in the 2.2 and 3.0 SDK)? I don't fancy rolling my own zoom + bounce + pan + paging code.
UPDATE
I deleted my previous answer because of the news below...
Big news for those who haven't heard. Apple has released the 2010 WWDC session videos to all members of the iphone developer program. One of the topics discussed is how they created the photos app!!! They build a very similar app step by step and have made all the code available for free.
It does not use private api either. Here is a link to the sample code download. You will probably need to login to gain access.
Check This
And, here is a link to the iTunes WWDC page:
Check This
I've written a simple and easy to use photo browser called MWPhotoBrowser. I decided to create it as Three20 was too heavy/bloated as all I needed was a photo viewer.
MWPhotoBrowser can display one or more images by providing either UIImage objects, or URLs to files, web images or library assets. The photo browser handles the downloading and caching of photos from the web seamlessly. Photos can be zoomed and panned, and optional (customisable) captions can be displayed. The browser can also be used to allow the user to select one or more photos using either the grid or main image view.
You say you've seen discussions of nesting UIScrollViews but don't want to go there - but that is the way to go! It works easily and well.
It's essentially what Apple does in its PhotoScroller example (and the 2010 WWDC talk linked to in Jonah's answer). Only in those examples, they've added a whole bunch of complex tiling and other memory management. If you don't need the tiling etc. and if you dont want to wade through those examples and try and remove the bits related to it, the underlying principle of nesting UIScrollViews is actually quite simple:
Create an outer UIScrollView and set its pagingEnabled = true. Add it to your main view and set its width and height to your main view's width and height.
Create as many inner UIScrollViews as you want images. Set their width and height to your main view's width and height. Add them as subviews to your outer UIScrollView, each one next to the other, left to right.
Set the content size of the outer UIScrollView to the total of the widths of all the inner UIScrollViews side by side (which is equal to [your main view's width]*[number of images]).
Add your images' UIImageViews to the inner UIScrollViews, one UIImageView to each inner UIScrollView. Set each UIScrollView's content size to each UIImageView's size.
Set min and max zoom scales for each inner UIScrollView and set each of the inner UIScrollView's delegate to your View Controller. In the delegate's viewForZoomingInScrollView, return the appropriate UIImageView for the UIScrollView that is passed. (To do this, just keep each of the UIImageViews in an NSArray and set the corresponding UIScrollView's tag property to the index of the appropriate UIImageView. You can then read the tag in the UIScrollView passed to viewForZoomingInScrollView and return the appropriate UIImageView from the NSArray).
That's it. Works just like the photo app.
If you have a lot of photos, to save memory you can just have two inner UIScrollViews and two UIImagesViews. You then dynamically flip between them, moving their position within the outer UIScrollView and changing their images as the user scrolls the outer UIScrollView. It's a bit more complex but the same principle.
I did some playing around with the native Photos app, and I think I can say with confidence they are using a single UIScrollView. The giveaway is this: zoom in on an image, and pull to the left or right. You will see the next or previous photo. If you tug hard enough, it will even page to the next photo at 1.0f zoom. Flip back and the previously zoomed photo will be back to 1.0f zoom as well.
Obivously I didn't write Photos.app, but I'll take a wild guess at how they did it:
A single UIScrollView and a single UIScrollViewDelegate
Populate the UIScrollView with UIImageView children
Listen for scrollViewDidScroll:
Do some math and figure out what page you are currently on
Listen for viewForZoomingInScrollView:
Return a different view depending on the page index
Listen for scrollViewDidEndZooming:withView:atScale: and optionally do some anti-aliasing, etc based on the content
If you decide to try that out, let me know how it works out for you. I'd love to know how you finally end up getting this to work. Even better, post it to github.
I did some playing around with the
native Photos app, and I think I can
say with confidence they are using a
single UIScrollView. The giveaway is
this: zoom in on an image, and pull to
the left or right. You will see the
next or previous photo. If you tug
hard enough, it will even page to the
next photo at 1.0f zoom. Flip back and
the previously zoomed photo will be
back to 1.0f zoom as well.
This is wrong. I'm using nested scrollviews, and getting exactly the same effect. If you're using some memory management scheme (which I had to start using... my page number is fairly high ('bout 50 each in 2 scrollViews)), then you can use a mechanism similar to whatever you have triggering your page loads / unloads to trigger a zoom reset for the pages -1 and +1 from the current page.
I suspect that apple sets this off as soon as the previous pic has disappeared.
What I don't understand is how to achieve smooth scrolling between pages - there's always a very short hang at the moment of transition. Do not get it. I've gotten pretty deep into fixing it - NSInvocationOperations were my first stop, then I made a reusable views queue for the page views (which retain their image views)... still this durned hang.
I only have one NSOperationQueue running, and I've tried fiddling with the max number of concurrent operations. My thought was that the main thread was getting clogged by competing Queues, or maybe even one queue trying to do to much... still, the hang.
I even tried creating super low-qual versions of my media, in case that was the problem. With each image weighing in at around 10k (these are jpegs, mind you)... you guessed it. The hang's still there.
I'm pretty much resolved to do what I've done before and use TTPhotoViewController from Three20. I've spent some hours swimming through that code, and it's always a great education. At this point, though, I would really like to know where the heck this hang comes from, if only so I can spend my can't-sleep hours wondering about something less brain boiling.
sure would be nice if apple built an image viewer like the photos app into the SDK for us to use. I'm currently using three20 and it works great. But it is a lot of extra stuff to carry around when all you really want is the photo viewer.
i write a code for that , and can be as reference
load current view scrollview and imageview ..
and for the screen next to the current view , only imageview
remove all view when current page load to save memory , so good for many photo project
use tag to differentiate different scrollview
_xxxxxxx
the download link click here
Take a look at https://github.com/facebook/three20/blob/master/src/Three20UI/Headers/TTPhotoViewController.h Not sure if that's what you are looking for
Related
When swiping between stories in Instagrams new feature "Stories" (you know that cube-like transition when going from one story to another) I can't manage to understand how they do it!
First of all, if you dig deeper into the functionality you find that it works exactly like the UIPageViewControllers transition:
- It bounces when swiping fast from one view to another.
- You can pause the swipe in the middle of the transition by touching the screen.
The developing team couldn't have used a solution based on the more known workarounds out there, e.g:
https://www.appcoda.com/custom-view-controller-transitions-tutorial/
Because as far as I know my two statement above is not possible to achieve with anything else than the PageViewController.
This leaves me thinking that the Instagram Developer Team gained access to a new transition style for the PageViewController, also known as Cube-scroll, or is it a workaround that I'm not aware of?
Any ideas?
I took a shot at recreating this functionality a while back. You can check the source code on GitHub: https://github.com/oyvind-hauge/OHCubeView
I'm using a scroll view (with paging enabled) and, for each subview I'm manipulating these as a function of the given view's current x-offset in the scroll view. The actual animations are done on each subview's layer using Core Animation (more specifically, transforming an identity matrix, given by CATransform3DIdentity, using the method CATransform3DRotate).
The shadow effects are also applied to the subview's layers (view.layer.opacity), with the amount of shadow determined by how much of the view is showing on screen.
My implementation solves both of your concerns (bounces when swiping, can pause swipes). I'm sure this could have also been implemented using the a UIPageViewController, but I hate working with those.
I think you are overthinking the controller's part here. The effect can easily be achieved using a CATransformLayer and three-sided cube-like view structure, where there is one view which aligns with the screen plane, and two others rotated -90 and 90 degrees on their y axis. Then, getting a pan gesture to rotate the scene. After a successful 90 degree turn (in either direction), you can either quickly reset the scene (so that keeping on rotating appears as if continues, but actually the camera shifted back to initial position) or you can have a full 360 degree rotation, and just update previous and next "pages". A single controller can handle this scene. If you prefer to have each page as a controller, it is possible, you can still use one controller for the scene, and then use the page controllers as child controllers, and setting their views as described above.
See this article for more information on CATransformLayer. Their example already creates something that is quite close to what you need.
I have been only using Xcode 5 for a little while now and I need help when it comes to auto scrolling a UIScrollView. I am using a single view application. I need the screen to scroll down at a pace that speeds up incrementally. Also I need the screen to keep progressing even when the screen is touched. If someone can explain which code goes where it would be great! Your help will be greatly appreciated. :)
Check out this library: https://github.com/danielamitay/DAAutoScroll
It stops to scroll when the user touches the screen and that's the only solution I see possible. I don't even see why you wouldn't want the user to be able to stop the scrolling..
OK, just adding this from your duplicate question.
I suspect the Piano Tiles game is actually using something like Sprite Kit.
This allows a lot more control over thing like "scrolling" speed.
Instead of using a UIScrollView you would use an SKNode as a layer with the buttons added to that parent layer.
Then using the update game loop you can incrementally increase the speed of the movement based on the time since the game started.
In essence... don't use UIScrollView, don't use UIKit, use SpriteKit.
I can see a few options:
1) suggested by Fogmeister, use Sprite Kit instead.
2) see setContentOffset
3) just use a normal view as parent, then have another child view on top with the full content (would be longer than the parent view), create a NSTimer to periodically call a method which scrolls the child view in whatever direction and speed as required.
Note that might need something on top to mask around the child view from showing the suppose-to-be-hidden sections of the child view.
Hope this helps
I have a UIWebView that loads a new request when the user scrolls a set distance past the end, or before the beginning of the content (ie. into the area that "bounces" back), via the scrollView delegate
Unfortunately, I have found that once the bounce animation starts, it has to complete, and completely bounce back to the edge of the content area, before the UIWebView will display the new content that it has loaded.
Is there any way to interrupt this, and have it not need to bounce back before displaying the new content? I would prefer for the old content just to disappear without needing to bounce all the way back to its edge . Either that, or speed up the animation.
Things to note:
I do NOT want to turn off bouncing.
I have tried importing quartzcore and using -removeAllAnimations on every view I can think of, including the superview, and it doesn't help.
I have tested it, and it is not because of latency in the loading of the request that is causing the delay in displaying the new content.
There are a few UIViewAnimationOptions that look like they could be helpful, but I can't see where I would use them, and I don't really want to subclass UIWebview if I can help it.
Any ideas?
thanks in advance
One of my views freezes up for several seconds when I tap the back button.
In addition, when I tap on one of the items in this view, it shows a popup (custom, not a UIPopoverController). This popup appears quite fast, but when I "flip" the popup to see it's back side, the same long delay occurs.
I suspect the reason has something to do with the complexity of the view. As you can see in the screenshot below, it's a collection view, it has a background and some of the subviews are rotated (UIViewEdgeAntialiasing is on).
I used the Time Profiler in Instruments to figure out what's going on, but I'm stuck.
I don't see anything useful unless I deselect "Hide System Libraries":
If I look at the method names, I think they are related to auto layout. That suggests that it's trying to render something during the segue. But methods such as cellForItemAtIndexPath are not called.
There is also an iPhone version of this app where I don't experience this problem at all. It uses a tableview in stead of a collectionview. It also has a background and rotated pictures.
I took these measurements using the simulator; on my iPad Mini the situation is worse; it can take up to 20 seconds before the animation starts.
Update - Things I've tried thanks to your answers:
turn off UIViewEdgeAntialiasing : no effect on performance
I think this might be due to the UIViewEdgeAntialiasing flag. It seems that your main view (the one with lots of slightly rotated pictures) have lots of antialiased edges and hence is very taxing on the iPad's GPU. The fact that the drawing performance slows down when your popover is spinning (ie when the background is showing again) gives this some credence.
Try turning it off and see if the performance improves. How does it look like?
Rotation was the bad guy here. Each UICollectionViewCell has a UIView as a container view and within that is a UIImageView. I rotate it like this:
container.transform = CGAffineTransformMakeRotation(M_PI * someRandomFloat);
Remove that line and everything is snappy.
I use the same technique on the iPhone, but apparently this kind of rotation has less of a performance impact in UITableViewCell than in UICollectionViewCell.
I tried subclassing UICollectionViewFlowLayout to rotate cell itself in stead of one subview. Unfortunately that causes a similar performance issue.
OK so in my game I need the users to scroll between items, just like you scroll a web page in Safari. Is there any way to do that? If not, maybe scrolling them to the side, like you do in the spriboard? Thanks.
I am not really sure I have understood what you would like to do, but there is a cocos2d extension that seems appropriate to it: CCScrollLayer.
CCLayer subclass that lets you pass-in an array of layers and it will then create a smooth scroller. Complete with the “snapping” effect.
If you are looking for a generic scrolling within your view, I suggest this tutorial or this topic rom cocos2d list.
EDIT:
I have never done it, but I think it should be possible to scale the CCScrollLayer to the size you need.
Otherwise, you might change the contentSize of the layer, or even put the CCScrollLayer into a clipping node.
Anyway, I think that it is much easier to start from this and find a way to adapt it to your specific requirements than start from scratch.