I've seen a lot of posts and videos on switching views and many of them have vastly different approaches. Some swap the entire view (via a delegate class), some use presentModalViewController:animated:, etc.
So I ask: what is the best, cleanest, and most memory-friendly way to switch views? (I use view switching as a way to show completely new information that might be on the screen for a long time, not a temporary notice.)
Thanks,
Derek
There is no one answer to this question. It depends on the structure of your application, the UI you want to present and how you want the transition to look to the user. In terms of memory, what you do with the old view is more important than how you present the new view.
For example, if your root view switches (occasionally) between two other views, you can present them modally, or with a navigation controller, but when one is not displayed you might want to release/destroy it to save resources. (Actually, if you might switch back, you can keep the non-displayed view around and only release it if you get a memory warning.)
Related
I have a very large form to build in my ipad application and I'm note sure which approach( between create multiple views in or multiple viewcontrollers ) to follow. Well, I have decided to split may form in logical sections, so I want use a splitviewcontroller with a root( a tableviewcontroller with the sections) and multipleviecontrollers for each sections. When the user select a row in tableview I will show the correspondent viewcontroller. I'm saving a reference for each viewcontroller in my app_delegate and the app_delegate also is the responsible for change the viewcontrollers. Is this the best approach? There is other approach to follow? About the multiple view I was thinking to put multiple view in the same xib file and then choose based in tag as the use tap the row in rootviewcontroller's tableview.
Thanks in advance. And sorry for my bad english.. Learning!
I will say this on the subject: currently, having multiple view controllers on the screen at the same time can be problematic if you're not using one of Apple's existing classes, such as a UISplitViewController.
The main issue is that important events your view controllers will want to respond to (rotation events, etc) won't be passed down to them. It's not a huge pain, it's just something to need to take into account - you'd typically create your own parent view controller that could pass these events down to its children.
Now, you are using a split view controller, so alls well on that front. There is no provided way for detail and master controllers in a split view controller to communicate with each other, but Apple recommend you employ a standard delegation pattern. If your application is fairly simple this could certainly happen in your app delegate as you do now.
If you're targeting iOS 5 only there are some changes that are relevant regarding multiple controllers on the screen at the same time, but I can't discuss them on here because of the NDA. You should go to Apple's developer forums (devforums.apple.com) to learnmore.
Sounds like I'm trying to do the same thing as you (large insurance forms here, how about your project?) Unfortunately I can't help out as you're a bit ahead of me. I've been able to flip back and forth between 8 detail views by tapping on the 8 rows in my UITableViewController, without keeping a reference to either the current or previous one anywhere. The data I enter into various TextFields stays where it should.
I currently have a xxxViewController.h/.m and corresponding .xib file for each detail view. That's an awful lot of code, but I couldn't see any other way to do it. Now I'm having a problem getting my button pressed handlers to fire. Also I've still got to put a database behind these screens.
Were you able to overcome your issue?
Thanks,
Jeff in Alabama
I want to hear developers opinions on the best way to swap views on the iphone.
For example, I have a tab bar and one of its tabs defaults to a login view. When The user logs in the view changes to a logged in view.
I was going to just use one view controller and have all the content in one xib hiding and showing content as needed but this seems in no way elegant.
Secondly I was considering having one viewcontroller and simply swapping the xib. I'm a litle reluctant to try this as I've read in an article or 2 that it can lead to memory leaks.
Finally I was considering using 2 view controllers with with 2 seperate xibs. My gut tells me this would probably be the "proper" solution but I so far have failed to hunt down any sample code on the correct way to do it.
Can you offer advice on the best way to solve this problem?
Is there a technique that I have not listed?
Thanks.
I would keep the logic for which view to show in the view controller. The XIB is the view itself, and should have no objects in it that are transient or not always visible for that particular view.
Your second approach (of swapping the views) seems to be the right approach to me, and is always something I, personally, do in these situations. I am not aware of any memory issues if you do it right (remove from superview, followed by loading the new view as a subview of the controller's view). You could perform any custom initialization once the new XIB has been loaded and before showing it to the user.
Multiple view controllers just seems superfluous as then you would ideally require another top level controller to manage the two view controllers.
I've spent too much time walking down dead ends on this project, so it's time to query the hive mind:
I am making a simple iPad game consisting of three locations which the user navigates between when an area of the screen is touched. These locations are represented by fullscreen images and there are a lot of different animations and stuff going on which makes it logical to divide each location into its own UIViewController.
The question is this: Which components should I use for handling the navigation between the locations/controllers?
UITabbarController: After finally managing to hide it away without a white bar at the bottom, I could not get selectedIndex to work in order to swap between view controllers.
UINavigationController: Does not permit more than one view controller inside, and I have three which I want to use. Is it possible to hide it away and still use it?
I could of course cram all my logic into a single UIViewController, but this seems plain wrong. Any advice or solutions for a newbie struggling towards journeymanhood would be greatly appreciated indeed!
If I well understand, everything happens like if you had three view to manage separately. If this is the case, you definitely should have three view controller. Communication between these controllers should then take place in the model. View controllers can be made aware of changes in the model through delegate in this case. If those interaction become too heavy, I suggest you create a super controller (application controller) managing the model and the three controllers.
What is the best approach to implement tabs that look like web applications on the iPhone, like the screenshot below (notice the "Checkin-Info-Friends" tabs)? These are not part of the UIKit standard library, but seems to be very common lately.
I've spent considerable time developing applications for the iPhone, but not developing controls like that one. What would be the best approach here:
create a new UIView for each tab content, and add the three subviews to the mainview straight away?
create new UIViews only when the user clicks on each of the tabs?
Put all the content in a UIScrollView, and just change the page as the user clicks on each tab?
Maybe there are open source controls for this out there? I couldn't find anything.
(source: foursquaregame.com)
My approach to a similar problem was to make all 4 (in my case) tab views, but respond to didReceiveMemoryWarning by releasing all but the current tab view. (Then, of course, you must make sure that you create the new view, if it doesn't exist, when the user chooses a new tab.)
I thought this was a good compromise - a speedy reaction to the user at first (and in my case memory footprint is at its lowest at this point in my app), and then a response to low memory to avoid being shot.
I think it best just to have three UIView* references to the subviews in the parent view or view controller, all initially null, then to have subroutine to hide the other two views if they are visible and either construct and show or just show the new view. Assuming no extraordinary memory requirements.
I think with such a small screen area load/unload concerns at the subview level are unlikely to be a concern, but if the parent views need to be loaded/unloaded, the subviews should all go (be both hidden and unloaded), and on reload, loadView should call the routine described in the last paragraph at startup.
If there is in fact a great deal of memory or resource use by any of the three subviews, then my advice is reversed and each of the subviews and/or any memory-intensive objects behind them should be not only hidden but unloaded whenever possible. I think with your use of Google maps there, a need to unload when hidden might apply to that.
Is this th right point to make? Is there some extra detail I'm missing?
You can have each tab be a real view controller with nib and everything. The only catch is that you must forward on the standard view controller calls you want to receive (viewWillAppear, etc) but it makes the coding much cleaner since you code just as you would for any other view (although for a smaller space).
You call each controllers "view" property to get out the view, which you add as a subview of a container view you have under the tabs.
If all three are table views, you might get away with using a single UITableViewController that changes contents based on the selected tab. Otherwise I second KHG's comment of using real view controllers to back up each of the subviews.
For the tabs themselves consider subclassing UISegmentedControl.
As someone who is fairly new to iPhone development, I've been trying to find good design patterns for managing multiple subviews, specifically where the subviews need the same type of delegate methods to be defined.
For example, I have a view where I need to swap between 2 UITableViews based on user actions. Both UITableViews need a UITableViewControllerDelegate object defined to populate the rows, etc.
Do you more experienced iPhone devs find that overloading the main view controller as the delegate for both subviews is the right way to do things? Currently I have 2 objects defined that each act as a delegate for each UITableView to try to keep things more organized. It accomplishes what I need it to, but is this a good pattern to follow?
I would assume there are some best practices out there to avoid various pitfalls with memory management and fun things like that. Thanks in advance!
You can use views as containers to hold the elements like tables. So in the case you outline, you'd have one container view and swap UITableViews in and out of it...
A good approach would be to have seperate view controllers for each table. Otherwise it just gets too messy trying to keep track of which data set you are supporting across the various table view delegate methods, and makes it harder to do lots of customization to one table that may not apply to another.
The main thing to be aware of when using composed view controllers is the "self.navigationController" and related calls will not return anything (since they are not really children of your navigation controller) so you'll need to pass along that reference or otherwise handle that somewhat differently in the table view controllers.
If there was only a small difference between the two—for example, if table cells are laid out the same way but use slightly different data—I might use if statements, but otherwise I'd go with separate delegate objects of some sort. Separation of concerns is the key here: if you're writing one method that does two vastly different things, that's a sign that your code is not organized well enough to be readable, maintainable, or flexible.
Also, don't forget that view controllers don't have to be magical objects that you can only use with Apple-approved tab bar and navigation controllers. It's perfectly legitimate to write your own "switching view controller" that takes two view controllers and toggles between them. You'll need to do some testing, though, to determine whether you need to call -viewWillAppear: and its ilk manually or not—there's some magic machinery that may or may not do it for you, depending on where you add your view controller in the hierarchy.
That's how I would handle the situation myself. One controller and delegate per UITableView. The datasource can be reused, if that makes sense (i.e. the same data is displayed in both UITableViews) Otherwise you would have lots of ifs in you're delegate methods, checking which tableview send the message.
Switching UITableViews sounds like job for UINavigationController to me. Usually on the iphone, you don't just rearrange your controls. You create complete screens (in code or as .nib via InterfaceBuilder), switching between them using UINavigationController or a UITabBar.