I have created an iPad app that has 10 view controllers that swipe left and right to and from each other, and each have 2-10 pages for a vertical UIScrollView. The problem is only the first controller loads at the launch, so each swipe initially takes 10 seconds to load. After the initial swipe I can swipe back and forth with ease, but I would rather have all the load time at the beginning so the user isn't left wondering what's happening.
Is there a way to load everything at once?
Should I even be using UIViewController subclass for this?
Thanks!
You can allocate and initialize them all in the application delegate (I think these go in the applicationDidFinishLaunching method, but I'm not at my computer to verify that is the best place). You may want to set their isHidden property to YES (except for the one you want to show first).
Once they are loaded this way, the applications view controller can be used to change the hidden property when you want a view to show or be hidden.
If each view really takes 10 seconds to load, you will have an initial load time when the application starts that is 10 seconds times the number of views you are loading. But once they are loaded, you shouldn't have that delay anymore.
Update:
If you want to animate the transitions from one view to another, you will have to use more than the isHidden property (that can't be animated). But you can deal with that later, and still start off by allocating and initializing like I described above.
Related
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.
I have a weird problem. I have a view that's used to set user settings. I have it in a regular menu for common access and when I tap the UIButtons within this scene they execute the IBAction callback only once. Even when you spam the button. Which is a good thing.
Now, for making things faster for the user I also allow access to this same ViewController elsewhere. This time instead of using a push animation I instantiate the ViewController on my own and show it on top of everything else. For some reason in this context if I tap buttons quickly the IBAction is called multiple times.
This is a problem for me because I have a performSegue within the IBAction and it pushes the next view twice. So when the user returns it returns to the same View and if you return one more time it crashes the app.
I don't know how to solve this problem because the same UIViewController is behaving differently in two different contexts...
I'm using xcode 4.5
Here is a screenshot of a view that I have right on my device.
The design issue that I am having here is that the top part of the screen is always going to be static - as far as its placement. The rest of the screen are a row of buttons added to this view programmatically. The arrows represent the idea that you could swipe in 4 directions(from top, from bottom, from left and from right) which would animate a new view onto the screen. This view is the same instance as the view before it. In fact all these views are the same instance but the buttons will be different.( i dont want to get too specific here.)
My design right now calls for pre-loading the views ahead of time. The data for each button for each view will be in core data. I will not know ahead of time how many views there are. One view might just have a view to the right that you can swipe in from the right and that view might have a top and bottom arrow - that would allow you to swipe from bottom or top that would be another view(same UIView subclass). So basically a tree of views.
I guess I am trying to figure out my options. A NavigationController is not really what i want because i have no need for a navigation bar, although in my mind it makes sense that i would have an array of view controllers here each with its view property pointing to each view that is allocated and then as i swipe i would bring in the appropriate view by using the view controller index.(through some animation code)
Another possible option would be UIScrollView but that seems cumbersome and may not be what i would really want.
One of the easiest setups would be to create a XIB file that would consist the top part of the screen and on the bottom an empty UIView that i would programmatically populate with the buttons(and their unique data). The problem that I am havign with this is, is how would i swap the views this way. I guess i could make the rootViewcontroller the first viewcontroller instance with the first view and then swap them.
I guess I am wanting to see if anyone had any questions or suggestions to come up with the easiest(most modular) approach to swiping in different views. Is using an array of view controllers the way to go?
A couple of thoughts:
This screams custom container view controller to me (if iOS 5 and above). See Creating Custom Container View Controllers in the View Controller Programming Guide for iOS.
You talked about using UISwipeGestureRecognizer. You could always contemplate UIPanGestureRecognizer, too. It's nice to have continuous gestures. Think about reading a book where the page swipe tracks your finger, but you can stop and go back, mid gesture. Sure, start with swipe gestures for now, but if your UX lends itself to it, you can always contemplate continuous gestures in the future.
You said that you're planning on "pre-loading the views ahead of time". Generally, given the limited memory capacity of mobile devices, you'd want to be more conservative than that. Maybe load the current view, and the four ones that you're likely to go to in each of the four directions (so that you can present them instantaneously), but leave it at that. Once you go to one of the four possible destinations, then go ahead and release the ones that are not reachable from the current one and tee up the ones that are.
One Xib is enough for you (for this part of your app anyway).
Don't use a UINavigation Controller. The NavController metaphor is one of a stack of cards. You don't have that data structure.
The general idea is one ViewController for one screenful of stuff. If you feel the need for two viewControllers (one for the top part, one for the bottom part) then you are going to have to look at custom container controllers, to ensure that the contained controllers receive their instance methods correctly (viewDidLoad, viewWillAppear, etc). An example container controller managing a pair of viewControllers is the iPad splitViewController. But I don't think you need to do this.
I suggest placing a scrollView on the lower half of the screen and using that to manage your data views. If the upper part of the screen also needs to change (under other conditions) you could even have two scrollViews, one up top, the other below. They can be paged, and contain views that are the exact size of the respective screen portion. They can share their single containing viewController as a common location for their delegate methods.
I can't really help you with more detail, as I don't have a precise enough idea what you want to achieve. Perhaps you should try and implement it one of these ways and come back here with more questions as your ideas become concrete. Start out with the simplest idea (eg scrollView inside a single viewController), only chuck it out when you find you have to break it!
update
following your comments, I do think a scrollView might work for you. I think that managing a stack of view controllers with a custom container controller (as Rob suggests) could get overcomplicated. You will have to create your own custom container controller, the pre-existing ones such as UINavigationController are not appropriate for your data strucure (from what I can gather anyway).
You won't need to manage tons of UIViews, in fact you only need 5 - one for the onscreen portion of the scrollView, one for the screen immediately left and right, and similarly for the immediate one above and below. You can reuse these views as you swipe, much the way that tableViews reuse their cells. The rest of it will be about manipulating your data so the right content is arranged in the views as they come onscreen.
See my answer to this question for some more ideas on this: UICollectionView horizontal continuous loop
I have a test app that uses a custom container controller to switch between 2 child view controllers based on the orientation of the device. In the portraitController, I have a button and a slider -- after one rotation to landscape and back to portrait, the slider still works but the button doesn't. After one more back and forth, both UI elements stop responding to touches.
Meanwhile, in the landscapeController, the button works fine for the first 6 times you switch to that controller, but on the 7th, the button only responds on the far left side, and on the 8th, it no longer responds at all.
The views look fine after the rotations -- everything stays in the right place. There's no methods connected to these UI elements I'm just seeing if they are responsive to touch. I have strong references to both child view controllers, so I am presenting the same instance on each rotation. I can post the code for the container controller if it would help.
Does anyone know what's going on here?
I found the answer after much experimenting -- the "Autoresize Subviews" check box in the container controller's view needs to be deselected. I'm not sure what that does exactly, but it was inappropriately resizing the views of the child controllers.
I am trying to have the ability to switch views in and out. The screens are generated on the fly and there may be anywhere from 30-100 of them that will be presented sequentially. A NavigationController may work, but I may be creating a hundred or so screens so I am worried it will run out of memory if I push that many views. Maybe this could work if I only ever added one screen at a time to the NavigationController, and when a new one is added remove all screens and then add the new one. But this may cause strange animations.
I tried creating a custom View Switcher that could load each of the views on the fly following the chapter 6 example in the apress book. The problem is that on rotations the events do not make it to the View Controller for the currently visible view. So it ends up doing weird things on screen rotations.
Another approach that I am thinking may work is to use a tab bar controller and make the tabs invisible. Then I can just use tabs 1 and 2 to hold the current view, and the last view and ping pong back and forth. Then memory is not as much of an issue as using a NavigationController.
Does anyone have any other ideas? I feel like there should be an easier way to do this that I am just not seeing.
How about creating a singleton "ScreenManager" that loads, adds and removes your views on your root view controller? This way you can make sure that the view hierarchy isn't convoluted and out of your control. It's also a good idea design-wise and should be very easy and efficient with memory management.