Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 7 years ago.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Improve this question
So, I have a navigation controller, which is connected to a view controller. From that view controller you can go to a the same type view controller but with different content. The view controllers are memory intense, so it's quiet expensive to push each new one of them. The problem is that when I click the back button and view controller gets popped, the memory doesn't release itself. Is there something I should do, like set thing that I don't use to nil etc. ? Because, suppose that I have 5 images to display, each of them takes 5-10 mb in memory, when I push a new view controller on top of the one I was on I spend 30-50mbs of memory, and that is okay, but when I click the "Back" button and the view controller gets popped up, I expect these 50mbs to be released. That is not the case, however. Can somebody give me a hint on what should I do to manage this memory more efficiently ?
Also, is there a a nice way to free memory taken by UIImageView in Swift?
So, to be more precise, view controller's deinit doesn't get called when view controller gets poped from navigation stack. The same applies to some custom subviews of that view controller. How can I ensure that they get cleaned by ARC, and are there any tools that can help me track references that keep these things in memory.
Okay, so I solved it. The quick tip for everyone who might be having the same problem.
1)Have all the fields (except numbers and books as optionals). Nil them out in deinit.
2) Nil out everything that can reference your object in memory, a good example, which is easy to forget is delegation. If your view acts like a delegate, don't forget to break this connection.
3)If you are using maps in your apps, it is advisable to use one shared map and redraw and change its delegate every time, rather then instant instinct new maps on every view with them. Maps can be hard to clean from memory(I tried map applyMemoryFix, it didn't work)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I need to implement a screen that lists the data I receive from an API. There is a mode navigation bar button which changes how the data is displayed in the same screen (same view controller)
Added a gif at the end to make it easy to visualize. The concept I have is quite similar, but transition animation is not needed.
The task itself is pretty trivial, but I can't decide what's the best way to handle this "mode switch". I came up with below options.
Option 1: Having 2 different view controllers for each mode. ContainerVC holds a state, and changes childVC when mode is switched. I think this is the best approach when the data is different - such as in segmented control. Since the data used in both child view controllers are same in my case, it may be problematic to manage this.
Option 2: We have 2 different views for each mode (for example tableView - mapView) and we add/remove these subviews based on selected mode in same view controller. With this approach, my view controller can easily be massive and impossible to maintain in a heartbeat
Option 3: Similar to option 2, but instead of add/remove we show/hide one of the views.
I am not sure if there are other approaches that provides a cleaner way to solve this problem, and I'd be happy to read resources/documentation to read you share
If only the position of the views changes you could just update the constraints. If the views are totally different depending on the mode, I would definitely use a container view controller instead of hiding / showing the views for performance reasons. You can store the two view controllers (each of which manages a view for a single mode) in a container property, when the mode changes the container toggles the visible clild (removes the current child and its view, then places the other view controller in the hierarchy). I suggest you to store the data only in the container, then you can pass a container reference to the children (maybe during initialization), so children can access the same model data through the container, this avoids repetition or conflict.
Otherwise you could also use a single view controller with a method that is called when the mode changes. In that method you can simply remove the current views (not just hide them) and insert the others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've been building iOS apps for a few years now. While I'm usually using a Navigation Controller to manage my View Controllers, I'm wandering what would be the impacts of someone building an iOS app using only one UIViewController to manage all it's views. That way, the developer would navigate between it's views by assigning a new view to the only UIViewController.
Let's say that developer is not planning to use Storyboard and that he doesn't mind build Views programmatically.
Is there an advantage to build an app this way? What are the downsides?
Let's be clear, I am not planning to build an app this way. I'm only wandering what would be the impacts from a theoretical aspect.
Is there an advantage to build an app this way? What are the downsides?
There's absolutely nothing wrong with making views come and go nimbly within a single view controller. I do it all the time and so do you, probably.
But now let's consider an extreme case along with the problem of where to put functionality. Let's say I have 10 different views with 10 different sets of subview functionality (buttons that do things, and so forth), all replacing one another in the interface. It's easy to imagine that one view controller governing all of these might get a little top-heavy with code. If each view has its own view controller, on the other hand, each view's controller functionality is in a separate view controller. This will likely make for more maintainable code in the long run.
The navigation controller architecture is a case in point. It separates the code that performs the transition between views (the navigation controller, which moves views in and out and deals with the Back button and so forth) from the code that implements the functionality of those views (the child view controllers that are pushed and popped on the navigation controller's stack). That's pretty darned clean and elegant, and is something you should probably want to use or emulate, not abandon.
Apple chose the one view controller per page approach in it's https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIPageViewControllerClassReferenceClassRef/index.html. That may be in part to maximize generality -- different users of UIPageViewController will obviously have different needs. But another consideration is memory; if you have a few dozen pages in the multiple subviews approach, you'll have a few dozen full-page subviews, and that's a quick way to use far more memory than you actually need at any given time.
If you do go with a single view controller and multiple subviews, consider instantiating the subviews only as you need them, and removing the ones that you don't need from the view hierarchy. Indeed, since it sounds like all your pages use the same format (checklist), it's hard to see why you'd ever need more than a single view for the pages. When the user selects a different page, you'd simply give the view a new set of data to draw.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I plan to develop an check list app that consists of multiple pages. Each page is going to display a list of simple Yes/No questions and a "Next" button at the bottom of the page.
In terms of the app design I see two options
One UIViewController with a stack of full page UIViews (layered, z-index). Switching from page 1 to 2 I'll use sendSubviewToBack
One UIViewController per page. Switching from page 1 to 2 I'll present the new ViewController.
Questions: What are are the PROS and CONS of these two approaches. Any other option that I've overseen? What are your experiences, suggestions?
Apple chose the one view controller per page approach in it's implementation of the same idea. That may be in part to maximize generality -- different users of UIPageViewController will obviously have different needs. But another consideration is memory; if you have a few dozen pages in the multiple subviews approach, you'll have a few dozen full-page subviews, and that's a quick way to use far more memory than you actually need at any given time.
If you do go with a single view controller and multiple subviews, consider instantiating the subviews only as you need them, and removing the ones that you don't need from the view hierarchy. Indeed, since it sounds like all your pages use the same format (checklist), it's hard to see why you'd ever need more than a single view for the pages. When the user selects a different page, you'd simply give the view a new set of data to draw.
Assuming you know how to write good code (reusing views / view controllers), they should have the same pros and same cons.
One pro in favour of the UIViewController approach is that it will most likely result in cleaner code. You also have the view lifecycle events like viewDidLoad, viewWillAppear, viewDidAppear, etc. which give you clearer view of what's happening.
I think it depends of what you are going to do on your views. If both have the same behavior with the datas, I would use just one UIViewController. If you have to make more and different treatments, I would use two UIViewController.
Using two also make easier a beautiful transition (handle by iOS) between them. If you use one, maybe you should use a UIScrollView and add the two views inside and scroll programmatically.
And another way to do that is to use a UITableView to show directly all the datas in one view.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The question is simple, I guess.
I'm looking for general rules of thumb.
I was even wondering if it's possible to create a view controller with a view described in code, but designed in a xib. (Makes sense?)
Closing the question
Although #mckeejm gave an answer where he thinks he had no choice but using code instead of a xib, the question hardly has only one correct answer and it is also very hard for one person to give a response with all the possible correct answers in it, therefore I'm voting to close my question.
But thanks anyway.
One thing you can do when you create views without a .xib file is have views that are derived classes of other custom views. For example, in the application I'm working on now, we have the concept of "cards" where cards have a corner radius and shadow setup prior, with a plain UIView *contentView for the actual content of the card to be placed in. If we want to make a new card, without reproducing that code, we simply create a new class that inherits from CardView and then manually position its content via layoutSubviews. I personally like having a .xib for constraint positioning and things like that, but I couldn't find a way to use our CardView as a base class for the new card style control unless we did it programatically.
Yeah what you can do is make a UIViewController in the storyboard file and connect that to a UIViewController class of your choice. Make the basic design in the builder then in the code you can go through and "customize" it to your need. I.e: when a button is pressed change an image. Does that answer your question?
#crimsonchris is right, this question is too open.
I will say this though: I've built apps that utilize storyboards, xibs, and flat out code. I've always found that writing things out in code is simply the fastest, most lightweight solution. BUT it has to be done correctly. My particular method to get ahead is by subclassing.
Typically, you have a consistent style guide in your app and can reuse a lot of ui elements throughout your app. The downside to writing everything in code is that it requires so much redefinition of object's attributes (font, text color, etc). If you subclass a baselined ui class of say a UITableViewCell you can use it everywhere and don't have to deal with the xib/storyboard nightmare. Not to mention the massive speed difference...
If you are a member of linkedIn, there is an IOS developer group that you can join that is probably more appropriate for questions of this type (coding styles). In the linkedIn group the discussion for this same question is already several pages long.
Personally, I use the XIB for its basic layout capability so I can visually gauge if the view looks good or not. Interface builder is not always an answer specially if you have dynamic screens with several layers - in which case I sometimes use a temp IB just to get the coordinates but build the view via code. Take note:when you use a XIB, the objects in the screens are instantiated by the XIB and is a black box to you - so if I have dynamic views with several objects that appear conditionally, using a XIB will create all those objects before your viewDidload whether or not those objects are eventually useful or not. Necessarily it will affect the way you debug, specially if the problem originates from within the XIB.
storyboards allow you to prototype without typing any code, which means you can show your boss how the app should look like within a few hours, I find it limiting in the way I am able to pass values and embedded class instances between class to class so I hardly use it. It is extremely useful if you can work within its boundaries.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I realize similar questions have been asked before, most of them are for outdated version of ios and do not completely answer the changed aspects from the version.
What types of objects should we set up in these methods in a viewcontroller to get the best performance?
I would like a detailed answer like:
Declaring int variables at x is good because y and so on.
I would like an explanation for NSString, NSInteger, UIImage, UI elements, graphics, network calls, coredata calls.
What kind of objects are we encouraged to get rid of at viewwilldisappear?
If all these are stated together in a complete answer, it would be useful for everybody.
Edit:
Difference between viewDidLoad and viewDidAppear
Bad question
Answer good but does not include initiliaze and viewdiddisappear
init method vs. a viewDidLoad type method
Question and answer left out viewdidappear and disappear
iOS: What is the difference between -init and -viewLoad of a ViewController?
Outdated, uses nibs.
iPhone dev - create array in init or viewDidLoad
I do not agree with the answer, something probably changed from 2009.
Init:
Instantiate any objects that you class will use. Do not add them to the view if they are to be subviews you must do this in viewDidLoad after the view has loaded.
ViewDidLoad:
At this point all you views have been instantiated so you can make any modifications, add subviews etc.
viewDidAppear:
Means what it says. If you want to change a background picture ever 5 seconds, I would start the timer here as you know the view is being seen by the user.
ViewDidDisappear:
The view is not currently being displayed -- so tidy up anything you don't need.
There are lots of other posts that have more detail if you search.
Link to Apple Doc (the first point of call)