Some of my UIViewControllers consist of several screens. I merged such each MVCs within one xib because the differences in screens were about 10% only (some different labels and buttons). The thing is I need to show concrete screen when pushing concrete UIViewController on screen. So, I have methods like "show screen1 and hide screen2" and "show screen2 and hide screen1" that I'm calling before pushing concrete UIViewController. Now, I know that having a separate MVC for separate screen would be more cleared but I'm a little bit annoyed about the duplicate stuff, so I'm taking an action to split only if there are major differences. How do you deal with such situations?
You don't have to have a separate MVC for every screen—that can get very messy! A controller can easily have multiple UIView outlets that you can hook up in IB and switch around as needed. Remember though, that MVC and other paradigms are a suggested design to make your life easier, not a law. You won't go to the 9th layer of programmer's hell for not using it—in the end, it's up to you. Use whatever makes sense for you and your app!
Related
I am making a multiplayer game. My First screen , should show a login form (not modally). When it finishes, it should call a delegate to my "root class" and the "root class" should remove this view controller and add another.Then when the game ends the "root class" will be called with another delegate method and it should show another screen etc..
I have 3 ideas about it and I would like to know which is going to work better.
a) My root class is a uiviewcontroller and it adds/removes subviews when the delegate methods are called.
b) My root class is NSObject subclass and it changes the window rootViewControoler when it has to.
c) Navigation controller without navigation bar. But how i manage view hiearchy?
What is better logic to manage my view hieararchy? Any other idea than a and b?
Either a) or b) would work. The choice would depend on factors like the degree to which the model layer is used to determine the sequence of presentation of views. If the presentation sequence is dynamic, then the helper class design (your option b) may be purer in terms of MVC separation. Ultimately, the decision depends on the details and complexity of your application.
Generically, some of the questions I ask when making design decisions like this:
How does it affect memory management?
How will the design affect performance?
Does the design appropriately separate concerns?
Is the design flexible? Does it minimize dependencies?
Does the design take advantage of framework/platform design patterns?
Of the options you present, I like c) the best.
Option a) falls short because it ignores the primary rôle of view controllers - to manage full-page views of content. Using addSubview in situations like yours requires you to jump through a bunch of hurdles in order to manage the memory of all those objects in the view hierarchy, and you would just wind up reinventing the UIViewController wheel.
Option b) is ok, but somehow it never seems to satisfy me. Just swapping the root in and out willy-nilly seems risky - this is what UIViewController is made to do, and it will probably do it better than you or I could. At any rate, you lose any benefits of animation if you do this. Which brings us to...
Option c). UINavigationController is programmed to do the work required of your particular situation. You can manage the hierarchy using UINavigationController's - (void)setViewControllers:(NSArray *)viewControllers animated:(BOOL)animated. You could do a normal push, but this will keep the previous VC in memory while your main game VC sits in front and demands resources from the system. In short, I think your c) is easy and effective.
As as post script here, be aware that there are alternatives other than your a,b,c. You might get by with using a UIPageViewController, though I'm not recommending it. iOS 5 introduced UIStoryboard as a method to manage your app's UI, and UIStoryboardSegue to manage transitions. Check out the docs, if you're targeting iOS 5, they might help you as well. But it sounds like a simple nav controller will work for you.
I am developing an iOS 5 application with the following visual structure:
where each square is a separate view. The blue views will be created dynamically (their number, the subviews, the logic behind of responding to the events). I was wondering which approach is better:
Creating different instances of BlueViewController and adding them as child view controllers to the rootViewController or
simple adding different views to the view hierarchy without creating the BlueViewController class and manipulating the views directly via the rootViewController
What are the pros and cons of both approaches?
That depends entirely on what they do. If they are merely views then you should just be adding views to the view hierarchy. E.g. if they are just showing some sort of info, then all you need is a view. If you do it this way, I would still recommend that you use a custom UIView subclass that handles your yellow views inside them and the layout.
If however, you find that each of them need to be doing quite a bit of "controller logic" e.g. handling complex algorithms and calculations then you should implement them as controllers.
Hope this is of help to you :)
Well, both are possible solutions, with pros and cons, and the right choice depends on the behavior of your app.
Using BlueViewControllers requires more lines code, but I think it is the best solution if you want different behaviors and you like well organized approach.
On the other side, adding YellowViews directly to the rootViewController could be easier, especially if your app doesn't have many views and an elaborate architecture.
In general I prefer the first approach, because, even if your project doesn't require BlueViewControllers at the moment of its development, it should help with future updates.
I'm building my very first iPhone application.
It's pretty simple, I'm displaying two lists the user can switch between using a tabbar.
I'm unfamiliar with the IB, so I'm building the UI from scratch, hoping to learn a thing or two about the inner workings that would otherwise be hidden.
My question for SO is:
Do I need a UINavigationController? There are no levels of navigation to this (yet), so the navigation stack described here seems excessive.
What's SO's advice?
Short answer: You don't need a UINavigationController.
Longer less definitive answer: Since you are just starting out I wouldn't mess with the UINavigationController just yet. Get comfortable with the UITabController and the two view controllers you need to show on each tab.
At some point, though, you may want to consider experimenting with the UINavigationController as you may find you want something to happen when a user taps on a list item within one of those lists. Perhaps you'll want to show more detail at that point, show a map, or a form, etc. That's when the UINavigationController is going to come in handy.
Well......... no you dont need one. But yes, I would take the time to use one. The UINavigationController and the UITableViewController are the two most used controllers in the iphone SDK. Better get to know them if you want to be an IOS programmer.
Also.. you said that you dont need "levels of navigation... yet". Better do it right from the beginning or you will be redoing all your code later on.
just my two pesos.
If you have two completely separate views, a UITabBar would be the far better pick.
This just shows a "ribbon" of sorts at the bottom of the screen which allows for choosing an option. The UITabBar is generally used for switching completely unrelated views, such as your use case.
On the other hand, a UINavigationController is used to form a tree-like hierarchy or drilldown and is ill suited for your use case.
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.
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.