Here's another very basic question. Is there an easy way to rename the rootviewcontroler? Say I decided that I needed to add a page before the current rootview (splash page, mini data snippets from the main app, etc.) How hard would it be to create another rootviewcontroller? I guess you would just take the current one and edit out lots of stuff.
Thanks.
Make a new viewcontroller for any view or set of views that manage different user experiences or tasks. I have a root viewcontroller in most of my apps to handle transitions and provide a few global methods, and then a viewcontroller (VC) for my settings UI, another for my game, another for my high scores list, etc.
Adding new VCs are as simple as the first one you added. If you are a bit timid about VCs, there are other classes that can keep some of the VC handling hidden in their code, like the Navigation Controller.
Please read up on VCs to see how they are intended to be used. Here is one.
Related
Hy everybody
I am a newbie ios programmer and I'm facing many doubts when I must switch the pages of my app.
With the term "page" I mean a UIView that fills the whole screen with some widgets (buttons, textboxes. tables..)
As far as I have understood what I've read I should use an UIViewController to manage each of these pages
since each page should be a screen’s worth of content.
My App starts with a ViewScroller with many buttons and when the user clicks one of these it opens a new page.
The first page is the UIView connected to the RootController Of the Window.
So far to open the new pages I add a child controller to the RootController and it's view as a child of the view of the RootController:
RicLocaliController = [[RicercaLocaliViewController alloc] initWithNibName:#"RicercaLocaliViewController" bundle:nil];
[self addChildViewController:RicLocaliController];
[RicLocaliController didMoveToParentViewController:self];
[self.view addSubview:RicLocaliController.view];
RicLocaliController.view.frame = self.view.bounds;
When the user clicks the "Back" Button I remove the child controller and the child view.
Going down this road I would get a dynamic tree of Controllers with their Views.
So far I have not encountered problems and my app can go up to a third level in the tree and come back. Each page behaves correctly when orientation changes.
But I'm afraid that adding, for each subpage, a child controller and a child view could be not the right thing to do.
I'm afraid that if I nest a lot of pages when the orientation changes the app could respond slowly since also the superviews will do something to manage this event.
So what I wonder is if what I am doing is completely senseless, if I should use Navigation controllers or some other way to manage my page changes.
Unfortunately my boss is not giving me enough time to study well the subject and so I would like an advice to follow the best solution possibly using the most standard and less complex component offered by the framework instead of the newest features.
I read a lot of web pages on the subject but it seems to me that there are many ways to manage the navigation beetwen pages and this makes me confused.
I apologize for my bad english but i'm tired and English it's not my first language.
You HAVE to do some studying. You will spend more time clearing up all your problems later otherwise... but, here are some tips.
Using nested ViewControllers leads to all kinds of trouble so if you are short of time, skip that.
Think of each "Page" as one ViewController. A ViewController has a property called View but that is actually just the top view of a whole hierarchy of views. A view is the base class for any visual object, like labels, buttons etc. All views can have subviews, so you can add an image under a label etc. and do really wierd stuff if you want to. I am just saying this to free your mind about how you can use views.
Now, ViewControllers are supposed to hold to code to ONE view hierarchy. That view hierarchy is for that View Controller only.
When the user wants to navigate to another page, you have a few alternatives:
NavigationViewController - that should be used when the user wants to delve down into data, like opening a detailed view of an item in a list etc. The NavigationViewController gives you help with back buttons, proper animation etc. You "pop" a viewcontroller to go back one level. If the user click the back-button, this is automatic.
TabBarViewController - use that if you want a tab bar at the bottom of the screen. Each tab is connected to a ViewController, that has it's own view hierarchy.
PushModal - If you are in a ViewController and just needs to get some data from the user, which is not part of the normal navigation of the app, you can push a new ViewController modally. This is the way you interact with iOS built in ViewControllers. This is also a good way to get a value back from the view controller.
There you have it. Go learn more. :)
It sounds like, for what you are using, you should be using a navigation controller. This will automatically handle pushing views onto the stack and then popping them off again later. This will also automatically create a back button (it is customizable) in the navigation bar.
If you are using iOS 5 or 6, I highly recommend trying out "storyboards" in Interface Builder. Storyboards allow you to graphically represent transitions (called "segues") between different views.
On top of being easier to design and implement, another advantage is that, if in the future you want to change the design of your application, you don't have to trawl through all your code and manually update each view connection.
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'm currently developing an app for both Android and iOS, thing is... I started with Android and my app has several Activities with different layouts (Screens with different GUI's, if you are not familiar with android), most of them display very different contents; maps, lists with data from databases, images, text fields with buttons and so on (And most of the time the orientation of the screen changes).
The problem comes with iOS:
How do I create more windows from IBActions? (Is this a correct approach?).
Once I create a Window, how do I create a new Interface? (Do I need another .xib file?)
If once the user finishes with one Windows, does the previous window remains in memory and can be re-opened? (Can I use a navigation tab, even though the first windows was not a using it?) This is a major problem since iPhones do not have a back button and Android relies a lot on those...
Also, if I can't split my program in several windows, wouldn't my app use a lot of memory from destroying and building views?
I'm new to Cocoa development and I have already read a book about Objective C programming (which only teaches syntax and so on), another one about simple iPhone apps (all of them were done in one window, changing the views programmatically) and I'm currently reading another one, but i'm unable to find a simple answer to my problem...
I mean I get Obj-C and how to build iPhone apps (well kind-of) but maybe the problem is that I come from a more straight forward development in Android. Each time I see an iOS project, I see it like a total mess, and the documentation in developer.apple.com doesn't help much either, I'm unable to find what I want.
Hope someone has gone through this already and is willing to point me in the right direction, thank you!
I recommend that you start with the View Controller Programming Guide at the apple developer web site. I think you will find it very helpful.
To answer your questions, you can develop each of your views independently. You depending on your purposes, developing each from a nib file could work. In the app I'm working on now, I have some that I develop programmatically and some that I bring in from NIB files. It's all up to you. The guide I mention above discusses both approaches.
Regarding loading views from button presses, you can do that. Depending on the view controller you use, it can be very easily accomplished. WIth the navigation controller, for example, you just create an instance of the view and push it onto the stack. When you're done with the view, you pop it off and your back to your previous view.
With regards to memory, that is always a concern. You might want to take a look at The Memory Management Programming Guide.
Good luck. I'm just starting out with Android development myself.
Chris already provided a great answer but there are a couple of points I want to add to adress specific questions.
iOS apps normally only have a single UIWindow. Within that window you may present multiple views.
Apps are normally organized into several logical screens worth of content, each managed by some UIViewController subclass.
Each UIViewController instance has a root view which may contain many subviews. A UIViewController's view is expected to fill its window or some frame provided by one of Apple's container view controller classes (UINavigationController, UITabBarController, UISplitViewController, and so on). You should not add one UIViewController's view as a subview of another UIViewController's view.
UIViewControllers will attempt to unload their views when the application receives a memory warning if the view is not visible. See the class' life cycle methods like -viewDidUnload. You should support and take advantage of this behavior to reduce your memory footprint. Keeping UIViewControllers in memory without their views loaded should have a minimal overhead, allows you to keep some persistent state, and each controller's view can be reloaded when needed.
Normally to transition between views a control will send a message to the current view controller (often via an IBAction binding). The current controller will then trigger a transition to another view controller. It might do so by creating a new view controller and pushing it onto the current navigation controller or presenting the new controller as a modal. It might have a reference to some existing controller and present that. It might dismiss itself from a navigation stack to reveal the previous controller. It might even pass the message up the controller's hierarchy until some parent switches the visible tab, dismisses or presents a modal, and so on.
You might also trigger smaller transitions by responding to an IBAction by adding, removing, hiding, or moving subviews of a UIViewController's root view.
Flash Builder 4.5.1 Now enables you to build one application and Compile to multiple Devices
UPDATE: Try XAMARIN, it's part of Visual Studio:
https://www.xamarin.com/
I'm tryin to grasp the fundamentals of Cocoa (Iphone) MVC design, but it's being quite tough. I've come accross several example applications, from the web, books.. but I've found nothing related to what I'm searching, since most of the examples just present a simple app (ie, a viewcontroller with a flipside viewcontr and a bit more..). So let's see if someone is willing to help me out in pointing me to the right direction:
My goal is to build a somewhat complex app. I'd like to have the following relation of views:
Presentation view (which would have a controller loading several memory intensive vars)
Main menu view: different options that would result in entirely new complex views. In example, a Begin option to initiate whatever the app permits to do; a second option to do another complex task with different views and actions within it, an Options option to configure options; a help option, an about option, etcetera..
In a first approach I tried to embed several rounded buttons in a view under the MainWindow nib with an associated app delegate. This approach though posed the question to how I manage to switch between views/viewcontrollers. After having uncaught exceptions because I probably don't fully understand the basics, I tried to move on to more 'simple' things.
Then I came accross the Navigation and Tabbar default Cocoa controllers. I don't want a tabbar, although it could come well for other parts of this app. Then the nav controller is what I think is most suitable for this case.
Thus, am I on the right spot if I build a hierarchichal app where its root is a nav controller? I've seen I can customize the main view to display a customized table, where each cell coud act as a button to spawn its respective view+viewcontroller. From here then I can keep building the 'leaf nodes' of this hierarchy of views/viewcontrollers, right? Eventhough I don't like the animation that by default provides the nav controller, I assume I can get rid off it..
So to sum it up in an easy way: I'd like to obtain a menu like those that can usually be seen on Cocos2d apps.
It's frustrating to ask this, I know it has to be easy but I find the documentation quite a mess aswell as the examples I've seen.. GUI programming it's being a tough learning curve :/
Thank you for any answers in advance, and excuse me for this long post.
Thus, am I on the right spot if I
build a hierarchichal app where its
root is a nav controller?
Almost. A nav controller (despite being a subclass of UIViewController) does not control views but rather other view controllers. The nav controller pushes and pops the view controllers which in turn causes the controller's respective views to load and become visible.
Therefore, the "root view" is actually the view that is controlled by the view controller that is in the nav controller topViewController property.
The app delegate serves to hold the nav controller and to tell it which view controller to push on the stack first. After that, the view controllers tell the nav controller when to push and pop them.
Otherwise, you're on the right track. You should always attempt to present information on a mobile platform in an hierarchal manner starting with the most general at the top and growing more specific as you drill down.
And you shouldn't be embarrassed at finding this confusing. 90% of the introductory/tutorial info out there, including books and Apple resources, focus on the gee whiz aspects of the interface and tell you next to nothing about the actual application design or how all the parts fit together conceptually.
You right about how little information is covered about app delegates to nav controllers. I been digging and trying to get all my screens linking etc. Having alot of fun watching my apps start to look more then just some Frankenstein monster UI. ahahah
The Itunes dev videos are great for looking at push and pop stack UIviews theory. I found they moved a little fast but after watching them the hands did make more sense. I have been forcing myself to watch them all and get a really good feel for whats going on. Hopefully have a nice app working soon.
I have been struggling a little with my first real iPhone application and wanted to get some advice on how this should be structured. I am looking for some best practices in terms of creating UI components and linking them together to create the application flow (create views/controllers programmatically vs. with Interface Builder, etc...).
Overview:
I need to show a "Login" view on application start up.
--Show "Signup" view if they click the sign up button.
Once logged in... I have a TabBarController loading 4 views. These 4 views will have to load sub-views (master-detail like).
My question is:
1) What is the best way to piece this navigation structure together? Create each view as a .xib with a corresponding ViewController? How are these glued together?
2) How should I handle the Login/Sign up navigation, no TabBar should be shown on start, but will need it after authenticating the user.
Bonus Point) Are there documented best practices for this kind of stuff? I have been hacking together some workable code, but I got very lost and want to start over doing it the correct way.
I know this may be a little confusing, all and any help is much appreciated.
EDIT: For the Login view on top of the tab bar I used this, pretty simple.
LoginViewController *loginViewController = [[LoginViewController alloc] init];
[loginViewController initWithNibName:#"Login" bundle:nil];
[self.tabBarController presentModalViewController:loginViewController animated:YES];
When you create a new tab bar based application in XCode, you are pretty much already set up the way you would like - there's a main XIB that loads views for each tab from separate XIB files. You have one XIB per tab. Note that as you change types or add tabs you need to specify the proper view controller type in both the XIB with the tab bar, and in the XIB that you use to create your view!
As for the login view, a common approach is to use the tab bar as above, but in the app delegate applicationDidFinishLaunching method present a modal view controller that shows the login screen. The modal controller hides the tab bar and everything else until they are done, then it can be dismissed.
1) What is the best way to piece this navigation structure together? Create each view as a .xib with a corresponding ViewController? How are these glued together?
Use UINavigationController and push your custom views onto the navigation stack as needed. Check out the example Navigation Controller application via Xcode's New Project option to get a feel for how this works.
2) How should I handle the Login/Sign up navigation, no TabBar should be shown on start, but will need it after authenticating the user.
Set up a view for login (I would use a UITableView with one section containing two rows for username and password, but that's my own preference). Set up a second, separate view for sign-up fields (again, I would use a UITableView for this, to keep the layout clean and consistent).
Perhaps use a view animation to pop up the tab bar after successful authentication.
Bonus Point) Are there documented best practices for this kind of stuff? I have been hacking together some workable code, but I got very lost and want to start over doing it the correct way.
You'll end up rewriting your project several times — which is a good thing. Do check out Apple's sample applications (available from the iPhone ADC site) as these contain several "best practice" ways of using several of the UIKit components. As to putting together a larger application, keep your design as simple as possible and reuse as much of Apple's UI components as possible. You can always customize later.
In my opinion, only Cocoa programming examples and very simple applications are suitable for a single nib file. Otherwise you should spread your interface components across multiple nibs. This means each nib is smaller and when loaded into memory will only load those components as necessary. This will improve performance in your application and can help logically organize your program and make it easier to debug when issues arise.
In my tabbar apps I use MainWindow.xib to contain the main window and tabbar but I break up each tab into a seperate nib for the reasons above.
Apple offers the following guidelines:
When creating your nib files, try to keep the following guidelines in mind:
Design your nib files with lazy loading in mind. Plan on loading nib files that contain only those objects you need right away.
In the main nib file for a Mac OS X application, consider storing only the application menu bar and an optional application delegate object in the nib file. Avoid including any windows or user-interface elements that will not be used until after the application has launched. Instead, place those resources in separate nib files and load them as needed after launch.
Store repeated user-interface components (such as document windows) in separate nib files.
For a window or menu that is used only occasionally, store it in a separate nib file. By storing it in a separate nib file, you load the resource into memory only if it is actually used.
For more information you can visit:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4