I am new to iPhone development... trying to figure out the best design for 70+ views. Do I have 1 Navcontroller and 70 views or what?
I originally thought I would have about 10 XIBs each with their own NavController and views, but I haven't found anyone that seems to think this is correct or not.
I think I understand the iPhone does not handle the memory dealloc by itself so I am assuming that will be a bit choice on how to make this work.
If you are going to implement 70+ views means you have to use both the navigation controller as well as tabbar controller. Then only the user can easily access all the views. If you are using 1 navigation controller and 70+ views means it is very difficult for the user to view all the views.
If you would like to design your views graphically using Interface Builder (built into Xcode4 or separate app for Xcode 3 and prior), I would just have a UINavigationController in your first xib (one with the UIWindow). You can then design each of your other views separately, in their own xib file and load them and push them onto the navigation stack as necessary.
Your understanding is correct; iOS does not support automatic garbage collection, although there is a pretty established paradigm of how to allocate and release memory as needed to avoid memory leaks. 70 views in an iPhone app is quite a bit, but it should be fine in theory, although I can see there being issues if the user has to drill down quite a ways in the hierarchy and each successive view eating up more memory.
Related
What are the advantages of using segues vs managing view controllers and subviews like we did pre-iOS 5.
Pre iOS 5 I might:
Build XIB files for my various Views then do something like [myVC.view addSubView:newVC.view];
vs Segues
You get the advantage of working with storyboards and the functionality of passing data between view controllers (which was easily accomplished pre iOS 5 in multiple ways).
So to me it looks like the only advantage of using segues is that you can use storyboards and pass data between VCs.
Is that right? Or are there other advantages?
one of the down sides that can be added to Kunai Balani's answer is that it makes working with a team with version control more difficult if many people are working on the same storyboard. my svn gets really confused when 2 people make an edit on the storyboard.
if you are not working with a team then you can disregard this disadvantage
There are several advantages :
1) Communication. Storyboard (and thus use of segues) is makes it easy to understand the flow of your application. This gives other developers an ease of understanding of the structure of view controllers without looking through any code or debugging.
2) You save time by using segues. Just imagine doing push and pop everywhere all around your application. If you need to change transition (lets say modal transition animation style) for all your view-controllers you have to go and search for each and every view controller then modify it. With storyboard all of them are at one place. It's easy to modify their transition style with just modifying one attribute.
3) Ease of debugging. Lets say your application crashed during a push in navigation controllers. With story board you get the identifier for your segue which caused this. No need to follow stack trace across your UINavigation Controller.
I'm quite new in iPhone programming. I'm the only objective-c programmer of my company, and I have to create an app almost done for android but for iPhone.
I have 2 basic questions. The app has a lot of screens, a big hierarchy of views and buttons to move between the views.
Question 1: As I need a back button to go back to the previous view, is it a good idea to have like 30 or 40 view controllers and have a back button by using the UINavigationController? Or it would be better to have around 6 or 7 view controllers with many views for each view controller? [This question is made also thinking about memory management]
And Question 2: in the case that the best choice would be have 6 view controllers with many views for each view controller, how can I implement a back button as if it would be an Android app (or a UINavigationController but for UIViews)??
Thank you very much for your answers in advance, I know that memory management is a very important issue in the iPhone programming, a problem that my work-mates (android programmers) don't have, and the back button, another big problem for me depending on the way of programming the app.
Thanks a lot!!
You should have one view controller for each "screen" of content.
For the most part, the key is going to be controlling memory yourself, and ensuring that you're releasing content that doesn't need to be used at a given time. Careful maintenance of your objects should limit any memory issues you're going to have, even with numerous controllers pushing and popping from the stack.
In terms of how many controllers you should use, this is going to vary. Any screens that duplicate functions in a basic way (editing a single text field, displaying an image, etc) can usually share controllers with a little property magic worked on them before you push them.
If each of your screens is very unique, however, then having a number of view controllers won't hurt you at all.
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/
In my iphone, in the section where I can make a call, I can view recent calls and I can also view my contacts.
I am referring to the contacts application.
I'm watching the stanford iphone vidoes, and they recommend creating a seperate NIB file for each view.
From what I understand, each nib/view will be managed by its own subclass of UIViewController.
Can someone, at a high level, describe what the contacts application might be comprised of in terms of nib's, controllers and views and how they would work together?
The contacts app is, unfortunately, a bad example. It's functionality is implemented at a lower level in the OS, as it is shared between the address book app, the phone app, and it can be implemented in your own app if you wish. Thus, the app is really just another front end for the feature.
Basically, the app is a UITableView with search that sends you to a UIView containing a UITableView and some text / image fields. Of course, there are editing and creation buttons to handle CRUD, but basically that's it. Each page would have it's own UIViewController and NIB file (assuming Apple follows their own directions, which they may not) ;)
Underneath, you have a core data store, but there's no much complexity in the data structure there, either. If you really want to analyze the database file, that's possible as well.
Hope that helps
At a high level, you have a UITabBarController that handles the tabs along the bottom and the switching of the five view controllers. Each of the view controllers, with the exception of the "Keypad" tab, uses a UITableViewController as the root controller of a UINavigationController. And it looks like, for the most part, where you are in the UINavigationController "stack" is remembered for each tab.
Each of the UITableViewControllers have a fairly simple implementation of the standard UITableViews. The implementations of UITableView are probably canonical examples of how to use UITableViews -- namely, what action to trigger depending on whether there's a disclosure button and what gets clicked.
Hope this helps!
First up, i realize this application has some design issues and while rewriting a huge chunk of it would probably solve my issues, I'm looking for a way to make things faster right now.
Basically I've got
viewController = [[MyViewController alloc] initWithNibName:nil bundle:nil];
viewController.view;
where MyViewController.xib is a rather complex nib file with a lot of intertwined controllers and views, some of which of course load their views and hierarchies from other nibs, but certainly not all. This takes around 7 seconds to load, which is a really long time considering this is an iPhone application.
The reason for forcing the view to load is that I'm also doing a some network requests in a parallel thread and once those have finished I'd like to set up quite a few things with these views.
My question is: how do I find out which parts of my nib are taking so long and what would be the best strategy to optimize this without completely rewriting the whole app (for now)?
The first thing to do is not to assume that the nib loading is the bottleneck without direct evidence that it is. Nib loading is highly optimized and very efficient. It is more likely that your bottleneck is the network request than the nibs. Use Instruments to get concrete data about where the app is spending its time before you do anything.
Assuming it is the nibs, Andiih answer is the best for profiling but it sounds to me like you've really got a design issue.
It sounds like you need to break your big nib up into smaller nibs.
Its common to have one view per nib. For example suppose you had an app that had a tabbar with five tabs. Then each tab had a table view which would open a detail view. In the normal setup, you would have 11 separate nibs. One nib would define the tabbar, one nib for each tab's view and then one nib per detail view. When the app started, only the nib for the tabbar and the first visible tab would load so you would only load two of the 11 nibs to start.
To optimize, the first thing to do is to break it down into the smallest possible individual nibs. A nib only loads when needed. You should place the functionality throughout your nibs such that you don't load the nib if its view is not immediately displayed.
Nibs are just lightweight data files so don't be afraid to create nibs that 99% identical. For example, I often use separate views for each portrait and landscape view. For the user's perspective, it's one view but I have three separate nibs. I do this in cases when its easy to use an entirely separate view than to rotate a single complex view. Each nib is loaded when when its orientation is used. If the orientation never changes, it's never loaded.
If you have a complex interface which changes significantly depending on a network request, it will be faster at runtime to have separate nibs for each variation than it will be to cram all the functionality into one nib.
I have no idea if this would really work, but you could put logging statements in initWithCoder in each controller which will be called as each sub-xib loads. That might give you some clues.
I guess instruments don't give you anything useful ?