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.
Related
I've been tasked with creating an app, but I have zero experience with iOS development. I have general programming knowledge, particularly with Java, JavaScript and PHP (I'm more a web developer than a programmer). I have dabbled with C, Xcode and various other languages and IDEs in the past, but I remember very little.
I've been following Apple's Developer Library tutorials, and I'm at around the Language stage, where I'm come to a grinding halt. While I slowly progress through learning the basics of Objective-C, there are a few things I'm very confused about regarding development in Xcode that various tutorials seem to completely skip over or just imply that you know what to do, or some just stop right before the part I'm having trouble with.
1) Storyboard - yes or no?
Is it better to start with an empty application and work with the
files or create a template (in my case a tabbed application) and work
with the storyboard?
2) If using a storyboard, do I still need to have a .xib?
Are the User Interfaces more like global templates that the view controllers implement?
If I wanted a different layout for each tab of my app, would I create a .xib for each tab, or just edit the controllers in the storyboard? Am I correct in understanding that the storyboard can have multiple instances/relationships of the same controller, in which case having .xib's would make more sense?
3) If using storyboard, where do the implementation and source files come from?
This is probably a stupid question. I know you can just add them via File -> New, but I don't know how to associate those files with a view controller. Is there a way to have the files created automatically when adding a controller into the storyboard?
Since you're just starting, you should use Storyboards because it lets you link different view controllers(pages on your app, essentially) visually and outside of code. For example, you can link your UITabbedViewController (the part that manages the content of the other tabs) to the pages that represent the content of the different tabs. Basically, your storyboard would have the tabbed view controller in a parent-child relationship with the sub-controllers. You would have one instance of each -- the tabbed view controller, managing an instance of each of the tabs' content and controller. This is the same regardless of Storyboard or xib, but you can connect this more easily in the storyboard.
You can still use a .xib(nib) file for stuff like Custom Table cells or in cases where you want to separate a view element or controller from a storyboard where there are other constraints.
In the storyboard, you subclass the controller class on the sidebar in the visual editor by entering your subclass of say UITabbedViewController in 'Custom Class'. In your file associated with 'MyTabbedController', you implement your stuff.
Great book:
http://www.barnesandnoble.com/w/beginning-ios-6-development-david-mark/1113216077?ean=9781430245124
Good luck!
Storyboards can be appropriate for small applications, where you have ten or twenty screens. When your app contains more than that, you will just get lost in storyboard schema, where all your view controllers will visually look the same.
I prefer not to use storyboard, just separate xib files for each controller.
If you use storyboard, you can create xib files for other parts of application that is not related to SB, and view controllers that is involved in SB has their interface stored in SB, meaning you will have to design them in there, in this one huge storyboard file. I find this very uncomfortable.
As you are new to IB, I would like recommend you to take a look at Auto layout. There is no magic anymore :)
To answer on a point-by-point basis:
I typically use the "Single View" template. It provides everything you need for your first view and can take it from there. It's a clean slate but it already has that first view which will be exactly the same code in 99% of the applications you make.
No, the storyboard file is your xib. You used to have to make a new xib for each new layout, but then Apple introduced storyboards. A storyboard is basically all of your xib's in one file. Rather than make a new xib, drag a new ViewController object onto the document. You typically only have 1 storyboard file or 2 if you want to support both iPhone and iPad layouts.
I don't think you can have it create your source files automatically, but its fairly easy to connect them manually.
Select the ViewController that you want to connect to your source files by clicking on that black bar beneath it. Then go to the bar on the side and go to this panel:
There you enter the name of your custom ViewController subclass where I have put "MyViewController". Hope that helps!
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 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.
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.