How do you create a banner (say, above a UITableView or something) that will switch images after a given time, or upon swipe. It then recycles through after a set number of images. See the below provided example from the IF app).
Also, I'm not necessarily looking for code here, but simply general features of Xcode I'd use to make it happen (ie, UIImageView within a ContainerView with gesture recognizers or something). Any ideas?
Here's the first image:
Then the beginning of the transition:
Then the second image in place:
This is an example of how to get that exact behavior using UIPageViewController. From the documenation:
A page view controller lets the user navigate between pages of content, where each page is managed by its own view controller object. Navigation can be controlled programmatically by your app or directly by the user using gestures. When navigating from page to page, the page view controller uses the transition that you specify to animate the change.
Related
I'm making an app for my Independent Study, and I have a UI functionality in mind - I just don't know how I would go about implementing it.
It's very simple in theory.
I want to have an initial view that fills the screen. When the user swipes up from the lower middle part of the screen, I want to do something that acts similar to control center, but for it to be a view that allows for me to choose between each of the 7 days in the upcoming week, displayed as icons with tags, and the user can swipe through them similar to how one swipes through the pages of apps on the home screen.
Similar to control center, the view should animate by sliding in from down to up, take up only part of the screen (In my case, about 1/5 of the screen as opposed to control center taking up more than 1/2) and the view behind it should of course remain running.
I am a beginner with iOS trying to get on my feet.
My question really boils down to this: I am unsure of what View class to use in interface builder for this, and whether or not this requires a segue/new view controller.
My initial thought was to drag and drop a View into the top level view, set its boundaries to how I want it to end up, then set it to hidden until I handle a swipe up, at which point it animates by sliding up.
I have done my best to describe my question but I am willing to clarify further if needed.
You can use 2 scenes in StoryBoard.
One as the mainView and one as the controlPanel.
Design as you like. You can detect user calling it by using UISwipeGestureRecognizer. And call the segue to that controlPanel scene.
On the controlPanel scene, you should set the backgroundColor to clearColor, and add another UIView on it with blackColor and alpha 0.5f.
To present it above the mainView, use modal presentation.
What I'm trying to achieve is basically a Instagram profile type screen.
I'm trying to recreate the segmented control section and what's beneath.
I thought about putting a container view containing the segmented control and a scroll view that switches between 3-4 views.
I saw many ways of implementing this, with or without a scroll view (the one I'm not really a fan of is the .ishidden method).
My main concern is memory. I don't know if it's better to keep them in memory or load them from scratch and also how to do that. Can you point me in the right direction ?
The instagram app doesn't do exactly what you described-- it looks like the only the first two options within the segmented control swap out the view underneath. The last two navigate you to another view
You definitely want to load your views, assign them to strong properties, and then swap them out.
Add a Custom View in Interface Builder, that will be your container, and then connect it to an IBOutlet in your controller. You can instantiate your scroll views when the controller is instantiated, and then you can then add the scroll view as a subview to the container. Then when the segmented control is pressed, you can remove that subview, and replace it with the new subview selected.
Instagram would arguably have some of the largest views, as far as memory allocation is concerned, to swap out (several images). Yet you can tell that the scroll views are stored in memory because you can switch between them without reloading the images
There's a particular control which I'm trying to build properly. I refer to it as an ImageTile. It's basically a little square box, which, when the user taps it, will present the user (via an action sheet in a popover) the option of selecting an image from the library, or taking a photo. Depending on the response, I then either present the UIImagePickerController inside a popover (for selecting an image) or modally (for taking a new picture). Once they take/select the image, I have a modal view which appears and allows them to edit the picture in a few simple ways. When they finish editing, the modal dismisses, and the original ImageTile, rather than being a blank square box, gets filled up with the user's edited image.
The issue is that this ImageTile control is going to be used profusely throughout several different parts of the application, across numerous View Controller hierarchies, and so on... and I really want it to be a basically totally self-contained unit, such that whenever I stick an ImageTile inside a UIView onscreen, all the above functionality is handled by the ImageTile itself.
Initially, I made it a UIViewController subclass (so it could present modals etc), and just added its view as a subview of a "holder" view onscreen. I know this isn't recommended, as the controller isn't part of the VC hierarchy then... and also, I wound up with some really weird behavior regarding things like autorotation, especially when the camera was involved.
What's the "right" way to implement something like this?
I think what you've done by making it a UIViewController subclass is correct. You should just use the methods that UIViewController exposes for adding child view controllers, such as - addChildViewController:.
You will also note that Interface Builder has a Container View object designed specifically for holding a place in the hierarchy for a child View Controller:
Here is what I'd like to achieve:
1) present a fairly large number of screens (about a dozen) with identical layouts but different info. (Basically a set of info pages for different events - dynamically set)
2) the user should be able to use swipe to move between the pages, and the transitions should be animated
3) I'd prefer to manage all the data from a single view controller.
What would be the optimal way to achieve this? I was thinking of keeping only two views in memory, dynamically updating the content of the currently invisible view when the user swipes, and then animating from one view to the other. Should I use one of the container view controllers?
Thanks!
Sounds like you should look at using a UIPageViewController. It is a parent view controller that manages a group of child view controllers that each display a single page of content.
Each page would be an instance of the same class of content view controller that you create.
A page view controller uses a data source and a delegate much like a table view does.
There is an app in the Xcode docs called PhotoScroller that shows how to set up a page view controller using a swipe gesture to switch pages. It's got a lot more complexity than you need in the view controllers that display photos (those photos are large tiled images and the photo view controllers have a bunch of code you can ignore that manages tiled images.)
I'd probably use a UITableView that has cells large enough to take up the whole screen. That'll handle reusing the views (UITableViewCells) for you and you'll need to disable the tableview scrolling and implement paging when the user swipes.
Apply a rotation translation to the tableview's layer and then apply the inverse rotation translation to each of the cells if you want a horizontally-scrolling tableview.
Alternatively, I believe iCarousel will handle view reuse.
Note: I'm not talking about custom view controller transition effects which can be done by using a custom view controllers it's the iOS 5+ API.
I'm talking about transitioning to another view controller, where a view from the presently displayed view controller is animated to the view controller to be presented's view.
EXAMPLE
-you have friendsViewController which displays a list of the current users friends. Each table view cell has a profile picture and name.
-click on a cell, all other cells fade away and the name and picture animate to the top. At this point, UserProfileViewComtroller is displayed.
THEORIES
-I could easily do this by combining the two view controllers, but UserProfileViewComtroller can be launched from other parts of the app.
-if the UserProfileViewControllers view is instantiated, I could convert the coordinates using UIViews methods
I feel like there is a more appropriate/cleaner solution here which is why I'm asking the community for help :)
It seems to me that what you want is exactly about view controllers transition, since you want to do 'something' that would look to the user as if you took a view from old VC and moved it to the new VC.
Then you're in luck, as you're allowed to move a UIView from one view controller to another using [superview addSubview:view] as part of the transition you want to do.
This can be done on any iOS version, although it's easier now as in iOS 7 there's a delegate you write (see <UIViewControllerAnimatedTransitioning> reference) which has access to both VC's view hierarchies and can change them at will (move one view, fade other views) during transition period.
Also, making your new view controller during the transition transparent (or using old controller's snapshot) will help you hide the fact that VC changed.
Not so much an answer but a technique that might inspire a solution. I did an app that had need for a custom transition like this. The original app arranged itself then took a snapshot, so at the last moment the user is looking at an image. The second viewController was created, given coordinates etc, and the image, then shown immediately. It put the image into its view (subview with same bounds).
At this point the second vc has complete control, and can fade in some other content etc. the reverse was more or less as the start - the image is used, swapped, used removed to uncover the real view content.
Note that this took a bit of time to get it working with no glitches etc.
EDIT: if you are concerned in turning the whole original view into an image, then modify the technique. For instance, in the original view, fade all other content to black but the cell, then snapshot the one cell. The second view will start with an all black background, and place the cell image over top it, then go from there.
EDIT2: As mentioned in the comments, you of course push the second view with no animation, so it happens instantaneously. By setting a small image on the second vc, with an agreed upon background, you can quickly "pass the baton" so to speak and let the second controller go to work quickly and seamlessly.