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.
Related
My goal is to have a main view, then swipe right to go to the next view, and again for the 3rd (so 3 different view controllers, all showing different information that is related to the main view), which seems to me like one of the most common features in most apps. Creating segues to other view controllers via buttons or tabs is super easy (just click and drag), but for some reason they make this common feature stupidly complicated for something that should be just as easy as simple segues in the storyboard.
I first started out researching the page view controller, only to find out that's not what I wanted and was too annoying to work with.
I think I found out that Container View is what I need, creating child views and what not. Does anyone know a good step by step tutorial to show you how to set all this up in the storyboard, like, a dummy's guide? I'm a severe novice, so a lot of the docs people point me towards have broken links, outdated code, or might as well be ancient Egyptian hieroglyphics.
Oh, and I'm learning Swift, not objective C!
It doesn't sound like you need to do anything other than use multiple view controllers to swipe through, passing data from one to the next, and so forth. I don't think using multiple views (parent / child views) is actually what you're after.
This is a very simple tutorial that will explain how to pass data through segues.
https://www.youtube.com/watch?v=guSYMPaXLaw
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.
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!
If I have a bunch of ViewControllers that are only ever going to deal with a single view, or even if my ViewController is going to deal with multiple views, why should I use another ViewControllers to manage the other ViewControllers? Why wouldn't I just change out ViewControllers at the ApplicationDelegate level?
Maybe I'm thinking about ViewController the wrong way? I'm used to writing in the MVC pattern with Ruby/.NET. For an example, if I were working with widgets I'd probably have a WidgetController and a List view, and a Detail view for the WidgetController.
What is the analogous iPhone MVC construction? I'd assume the WidgetController would subclass the ViewController and I'd have a couple different views depending on how I wanted to look at the widget data. Then, when I wanted to deal with Wodgits I'd make a WodgitController with its associated views and swap the window's subview out with the new Wodgit ViewController.
I don't see what having a RootViewController to control my controllers buys me. Where is the value? What am I missing?
I'll focus on one aspect: Compartmentalization is a very useful design principal. If you separate concerns and put things where they "belong", they will be easier to find, maintain, build upon, and co-opt for new purposes.
Consider this:
All the pipes in your house go to the same place. Do you urinate in your sink, or do you use the fixture designed for that purpose?
In the case of your app, the application delegate is responsible for responding to application events and managing universal application resources. The root view controller is responsible for managing your views and view controllers. As a view controller it has special abilities to do so with navigation control, the ability to present modal views, act as a delegate, etc. While you could create a view controller and manipulate it completely in the application delegate, the task will become exponentially more difficult as you multiply the number of views you are managing, especially if you wish to be a text field delegate, data source, etc. On the other hand, it is easy to split the root view controller into its own class. There is very little cost.
Why pee in the sink when the toilet is a step away?
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.