Say I'm making a game using the new storyboard feature in Xcode and I have the main menu navigation controller as my initial view controller. Then when the user starts a new game I then load the gameplay view controller using a modal segue, for example. The navigation controller would still be my root view controller while I'm doing all of my rendering etc., right?
My question is how much overhead does this take up? Does it hurt the performance of my game to just have the nav controller hanging around back there? If you've built an iPhone game, how have you handled the menus?
I am also thinking about this because I'm building in a little treasure hunt easter egg that uses the GPS. Once you get into that part of the app, you'll never go back to the game. At that point since the GPS is in use, battery life is an issue. Does it hurt anything to have the game stuff sitting back there even though it will never be used again in the current life of the app?
I've tried building a couple custom segues that actually change the root view controller to get around this, but writing custom segues is actually pretty nasty if you try to do anything that isn't simple. I'm also not sure if that's the right move.
Sorry if these are silly questions, I'm pretty new to iOS.
Here are answers on some of your questions :
The navigation controller would still be my root view controller while I'm doing all of my rendering etc., right? YES
Does it hurt the performance of my game to just have the nav controller hanging around back there? a little as memory is used but not to much according to me.
IMPORTANT NOTE : if you are using story boards your application won't work before iOS5.0 which means you will lose a lot of potential users.
Related
I'm in the process of learning Swift. I wouldn't say I'm a novice, but I'm sure like many learning online I have missed a lot of fundamental steps to understanding what's really going on.
After getting pretty far with my app I am now seeing that my memory management is very poor. I am using SDWebImage caching which is definitely impacted by GIFS, but more to the point I am now learning about retain cycles and deinit.
Could someone please explain why a ViewController inside a UITabBarController deinit is never called?, why this isn't a bad thing? (unless it is) and just general advice/direction on memory management when using a tab bar controller. I have looked into retain cycles and why they are caused and fixed, but that doesn't seem to be my issue according to xCodes instrument tools.
Any advice would be much appreciated
Thanks.
A tab bar controller does not create and destroy the view controllers (tabs) it manages. It holds onto all of them so the user can switch between them as needed. Thus the view controllers from the tabs persist as long as the tab bar controller persists.
If your app's root view controller is a tab bar controller that never goes away, neither will the view controllers for the tabs.
If, instead, you create a tab bar controller and push it onto a nav stack, or present it modally, the tab bar controller will be released when it's popped/dismissed, and the view controllers will then be released as well.
Also, another reason an object may not be deinitialized is because of references. Since you are just starting Swift, I strongly suggest that you look up tutorials on Reference cycles, ARC (automatic reference counting) and memory leaks. They’ll teach you about
weak var
And the proper time to use it. When starting, I’d say it’s not too important, but they are valuable later on when trying to get a job in software development.
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/
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 wonder if that hurts performance. I have an test app which is pretty huge regarding view controllers. Rather than changing just from view A to B, I slide everything around. So I have a root ViewController, which is used for the basic application feature areas. It instantiates other view controllers on demand, puts them into UIView containers and slides them around to make nice effects. Those view controllers are considered as root controllers theirselves, and each of them creates another set of view controllers for different stuff.
So at the end I have a hierarchy consisting of about 15 views. Everything is smooth, but it feels a little bit strange. Well I guess it's normal. Just wanna know what you think / do. Am I crazy?
This seems like a fine way of doing things. In fact, the user interface toolkit apple supplies works the same way internally. A button, or any other visual element is in itself a view, with its own view controller. By just adding buttons to the screen you are already nesting views and controllers.