I currently have my first app, which uses a storyboard. From the first view, I can be 8 model views deep before returning back to the start.
I think using XIBs (not storyboards) is better for my application. I would like to learn how to do all the views in code but all the books and tutorials treat code as a black plague. Hard to learn if no one teaches anymore.
My concern with my 8 deep modal string of views is that memory is consumed by each view and not released until I fall back to the start - releasing each one as I fall back.
My application is a state machine (so I want to simple move from one view to another), releasing all aspects of the view just being left. As I move from one state to the next, I release the current view as I move to the next one.
Can someone point me in the right direction?
Thanks.
You have a couple of choices. You could create a custom container controller (which would exist for the life of the run), and switch out which controller is embedded in it. As long as you have nothing pointing to the one that you replace, it will be deallocated.
A simpler solution, but one I don't really like to use, is to replace the window's root view controller with the next controller you want to go to, which will also cause the replaced one to be deallocated.
Related
The app I am currently working on requires that I do not use ANY storyboards. Therefore I need to do everything programmatically. One thing I seem to be struggling with is switching between two UIViewControllers.
The issue is that every time I call the self.present() method; it creates a brand new instance of the class I would like to show. So when I go into Xcode's visual debugger, I see over 15 different views that are all stacked and are merely instantiations of one another. Ex: View1, View2, View1, View2, View1, View2, View1... This constant repetition of the views is significantly hurting the performance of my app. So my question:
Is there a way that I can switch between my two UIViewControllers without constantly creating a new instance of each one?
Again, I am doing all of this with ALL storyboards DELETED. So the solution I necessary needs to be implemented using ONLY code.
I think you should create main ViewController.
if you keep your two instance view controller, create two controller in mainViewController. Then keep that in main viewController.
And push view controller you want to present in navigation of main view controller
if you want to change second view controller pop navigation controller and push another, or just push other controller.
if you want keep your instance view controller i think it's best option for you
I think that it is really important to realize the fact that the view controller will show up multiple times in the debugger because that is something that can throw off the performance of the app. I really like the way you mention that in your comment. This is one of the main differences that can outstand you from another programmer in the same field. One of the most easiest and simple ways to fix this problem would be using the self.dismiss() method. Another way to dismiss this view controller would be to use a navigation controller to fix this problem. A navigation controller will push the main view controller out of the way and it will not create multiple instances of it. This will be the most efficient as it doesn't require a lot of code and a mere initialization of the UINavigationController class implemented in the UIKit. This is one of the most important tools and resources that you must make use of while coding in xcode and developing your skills in the swift ios field. Since this problem is not one of the most common to find on the internet, it is very beneficial for you to post it on this forum page and will really be helpful for some other programmers unaware of such methods and ways to code. One of the questions that I have for you is the fact that you don't want to use storyboards. Why don't you want to use storyboards and only make it proGrAMitcally? This is one of the very questions that manages to astound me. The storyboard is an implementation that makes it very easy for xcode and swift users to work around the tedious work that has to be done while working in the coding aspect. It only takes a few lines of code and you can get a seGu done very easily. The switch is very easily done and you can find this method on some youtube channels. For this type of work, I recommend VigneshSriniswami Patel and ShaniLakshmiVishnuJiSwami, these content creators will help guide you to becoming an xcode master.
Hope I helped!
New project, using storyboards for the first time. So many things I did easily with nibs is frustrating me to no end.
I want to be able to hop around and shuffle my views at will. I have figured out unwinds and pushes and all goes well as long as I continue linearly forward in the storyboard path. At some point I want to hop laterally back to a view that may already be somewhere on the stack, or not. This doesn't seem to work as expected.
Using UINavigationController.
Say, at one point I have 3 different views moving forward. I push one of them and go about business along that "fork". Now at some point I want to hop over to one of the other 3 paths at that fork without backtracking through the stack.
Previously, I might just instantiate the correct view controller from nib, push, then remove the view controllers from the stack that are between the "fork" and the current view. Or, if that view controller was already on the stack, I could shuffle it around by manipulating the array directly.
How can I do this with segues?
I tried making segues to and from each of the three view controllers at the fork. What a mess. I keep getting errors, segue not found, when I know they are there. I tried "replace" segues, they didn't work as I expected. Not to mention my storyboard looks like a spiderweb.
I don't like to be stuck in the old ways. If storyboards are the future, I want to be on board sooner rather than later but I could have been so much further along if I'd stuck with what I know. Any storyboard wizards willing to school me with suggestions?
Since nobody answered, my solution turned out to be abandoning the navigation controller entirely and use a variation of the method detailed here by Michael Luton:
http://sandmoose.com/post/35714028270/storyboards-with-custom-container-view-controllers
If anyone has need for this, I can say that it works very nicely and is quite simple to implement.
My application is for studying. It will have three screens, one for studying (reading), one for reviewing, and one which acts as the main menu (for managing documents and selecting study or review). The main menu will be the first screen when the app is loaded.
I am trying to decide on the best approach with regards to what view controllers and views I need.
Approach A:
(4 x View Controllers - root, menu, study, review)
This approach has a root view controller with no on-screen controls. It will always contain one of the other view controllers as a subview. For some reason I am attracted to this approach but I have seen no other examples of this so maybe I am being stupid. I am wondering if there is a reason why this is inherently wrong.
Approach B:
(3 x View controllers - root (menu), study, review)
In this approach the menu IS the root controller and the other controllers load in subviews of the menu. I think this is more of a standard way of doing things.
I would be grateful to hear any thoughts on which approach is best. I am a newbie to software development. I have worked through a number of books on iOS software development and messed around for a bit and now I am starting my first app for iPad.
Whenever you're determining how to layout your views and controllers, they're very often based on the application flow (from an end user's standpoint). So from your original question I'm not sure I exactly understand the flow- is the user forced to start at the main menu, and then from there is able to toggle between two mutually exclusive views (study & review)? If that's the case, I would recommend using a tab bar controller for the 'Study' and 'Review' views, as it allows for saving states of the views and switching between them without you having to do any extra work (from both of the approaches you described it sounds like you'd largely be recreating this behavior yourself). Then, for the main menu (which I assume is displayed when the app first starts?) You can simply open it modally (note you don't have to animate the opening, so it can instantly appear instead of sliding up from the bottom, and the user will never be the wiser). Once the user selects what they need to select in the main menu, dismiss the modal view and you're ready to go with your 2-tab controller.
I am looking to to develop an app where there will be "n" number of views created based on the user's interaction. If each of these views are created dynamically with autorelease, when will the view actually be released?
Lets say there are 10 views, all being dynamically created views with autorelease:
View 1 is created and added to a navigation stack, user is shown view 1
User moves to another view "View 2", View 1 is pushed off the stack and View 2 is added. Will View 1 be released here? I would not want it to be released, so should i retain it?
The problem is, i might not know how many views i am creating, so deallocating them manually might be problem, or is there a way?
I am a little confused soul here.
Thanks
You don't add views to navigation stack, you add view controllers.
When you push view controller 2, the 1st one will not get released, no. Navigation controller will always keep all it's view controllers retained until they are popped off the stack. It will only call -unloadView on non-displayed view controllers to free up some memory, but if you are creating your views inside view controllers' loadView method, everything will get recreated automatically.
You don't dealloc anything manually, you can only release it. Since navigation controller will retain any view controller you add on it's stack, you are free to release it yourself.
From the way you ask your questions, I've noticed you are missing some very basic knowledge about iOS SDK, MVC and OOP in general. I would honestly suggest you try creating a much simpler app than that chat app of yours first to learn some basics.
It will help if you post key segments of your code so we can see what you are doing. In short, if a view controller is in the navigation stack, it will be retained by the navigation controller. If it is popped off but you want to keep it, you'll need to retain it from another controller, probably the one that presents it.
I am trying to have the ability to switch views in and out. The screens are generated on the fly and there may be anywhere from 30-100 of them that will be presented sequentially. A NavigationController may work, but I may be creating a hundred or so screens so I am worried it will run out of memory if I push that many views. Maybe this could work if I only ever added one screen at a time to the NavigationController, and when a new one is added remove all screens and then add the new one. But this may cause strange animations.
I tried creating a custom View Switcher that could load each of the views on the fly following the chapter 6 example in the apress book. The problem is that on rotations the events do not make it to the View Controller for the currently visible view. So it ends up doing weird things on screen rotations.
Another approach that I am thinking may work is to use a tab bar controller and make the tabs invisible. Then I can just use tabs 1 and 2 to hold the current view, and the last view and ping pong back and forth. Then memory is not as much of an issue as using a NavigationController.
Does anyone have any other ideas? I feel like there should be an easier way to do this that I am just not seeing.
How about creating a singleton "ScreenManager" that loads, adds and removes your views on your root view controller? This way you can make sure that the view hierarchy isn't convoluted and out of your control. It's also a good idea design-wise and should be very easy and efficient with memory management.