I am trying to create an iPhone game app with the Swift programming language using Xcode. I created the project as a single-view application, and I have been adding view controllers and connecting them up with segues as I need them, using the Storyboard.
From what I have come to understand after hours of working on this (better late than never), is that VCs do not use a stack, while a navigation controller connected to other VCs does use a stack. So, assuming there is no navigation controller being used, if I use a "show" segue from one VC to another, it won't push the proceeding VC onto the VC that initiated the segue. It will instead show it "modally".
I have a few questions regarding this.
What is occurring when I am moving between the VCs, if they are not using a stack? For instance, when I move from one VC to another, is the previous VC removed from memory, or does the memory keep taking on more and more copies of VCs as I move between them?
Since VCs cannot pop from a stack without initially having a navigation controller, is there any way to keep my app from crashing, such as a particular way to segue between VCs?
When a project is created in single-view application/tabbed application, etc., does this affect what the app will be capable of doing indefinitely, or does Xcode just create a basic template to start from? For instance, could I start off with a single-view application, but turn it into a tabbed-application? I assume the answer is yes, but confirmation is always nice.
Any information regarding these questions is greatly appreciated!
Thanks!
What is occurring when I am moving between the VCs, if they are not
using a stack? For instance, when I move from one VC to another, is
the previous VC removed from memory, or does the memory keep taking on
more and more copies of VCs as I move between them?
The previous VC stays in memory. Each new segue creates a new VC.
Since VCs cannot pop from a stack without initially having a
navigation controller, is there any way to keep my app from crashing,
such as a particular way to segue between VCs?
There is only one segue type that does not create a new VC and that is the unwind segue. You use it to return to the previous VC. Search Stack Overflow for "unwind segue" to see how to set that up.
When a project is created in single-view application/tabbed
application, etc., does this affect what the app will be capable of
doing indefinitely, or does Xcode just create a basic template to
start from? For instance, could I start off with a single-view
application, but turn it into a tabbed-application? I assume the
answer is yes, but confirmation is always nice.
The templates just start you off with the appropriate Storyboard and ViewControllers for that template type. You can easily delete or modify them to change what your application does.
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.
Apps such as Instapaper and Twitterrific launch to views that aren't the root view of their navigation stacks. We know this because the initial view already has a back button. Instapaper launches one level deep (Instapaper > Read Later) and Twitterific two levels deep (Accounts > Account > All Tweets).
What's the most efficient/recommended way to achieve this behaviour using Storyboards (perhaps pushViewController:animated: or performSegueWithIdentifier:sender:) and how does one achieve this whilst taking into account the new state restoration APIs, to reduce the chance of a conflict between the view I want to present and the one the state restoration process wants to present?
You can't initiate a segue via Storyboards only, you'll have to write code. And by writing code I mean you probably want to use UINavigationController's -setViewControllers:animated: method, since segues are generally used to make nice animated transitions and not initial UI setup.
If the view controller is a second one in the hierarchy, I'd simply call UINavigationController's - (void)pushViewController:animated: (with animated:NO) from its viewDidLoad method. If it's deeper, then - (void)setViewControllers: instead of push.
I'm trying to develop an iPhone app that uses 4 views(View-based app), and I want to navigate from one view to the other. It would be ideal if for example the Submit ID button automatically sent a message to UIViewController to switch to View 2, and selecting a cell in View 2 would load View 3.
See a screenshot of the Storyboard here.
I'm not sure how to do that, so I've tried using a separate button to switch between views, but that isn't working either and I can't figure out why.
You can have a look at the source code which I've uploaded to Dropbox.
First, I would suggest posting your code in your question. As appreciative as I'm sure other people are that you provided a dropbox link to the code, most people presumably have little interest in downloading the file to their computer, unzipping, and launching the project (me being one of them).
That being said, let's make sure you're clear on Storyboards and the general view controller hierarchy principles. You have, in your storyboard, four UIViewControllers dragged out into your workspace. So, you're not switching the views of a single UIViewController, telling it to switch from View1 to View2 to View3 and so on. You need to be telling the view controller hierarchy (which, in your case, probably needs to be managed by a UINavigationController), to push and/or pop view controller on and off its stack. It appears that you have some segues set up between your view controllers. Are you calling performSegueWithIdentifier:sender: in your code? Alternatively, you could hook up the Submit ID button to perform a push segue to View Controller 2 in much the same manner.
Once you have that working, you can override prepareForSegue:sender: to send information from ViewController1 to ViewController2 and so on.
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/
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.