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)
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I have a ViewController with a progressView, label and button. A task runs in background in task.swift when user clicks on the button on ViewController. I want to update the label and progressView in ViewController based on progress of tasks in task.swift.
Swift Communication Patterns
You have multiple ways of setting up communication between 2 classes in Swift:
Method call / return
Delegate pattern
Closure
Notification pattern
Publishers subscribers
Respect MVC (Model - View - Controller)
Because you want your model (here Task) to not be aware about the ViewController in order to respect MVC, you cannot apply just a simple method call through the reference.
Pick the right one
However all the others ways are totally valid. Because it seems to be a 1 to 1 relationship between ViewController and Task, the most simple solutions would be to use a delegate or a closure. If your classes relationship would have been a one to many, you could have picked notification. Publishers would be for reactive programming and if you like Combine.
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)
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 9 years ago.
Improve this question
I've seen a data source on a ton of Apple's code; UITableView, UICollectionView, etc.
I am making a custom view which does not use the view reuse like my mentioned examples do. Should I just set the data in the init method/using a property, or should I make a data source protocol on my custom view and get the data right when I want it from the client objects? Or should I do some other thing I don't know about...
Thanks!
Well... it depends.
If your view is presenting a lot of information and optimization techniques are needed to perform smoothly, then a dataSource delegate pattern should be used. If it's just a handful of small bits of data that needs to be displayed, just use properties/init.
UITableView and UICollectionView are heavily optimized views that do a lot to keep smooth scrolling performance. They can also present a large amount of data, which might not be practical to have all loaded in memory.
On the other hand, something like UILabel doesn't usually present a lot of information, so it uses properties to configure the data it needs to display.
When creating a custom view, usually parameters are set in -initWithFrame:(CGRect)frame method, that is called for a UIView only once.
But what if somewhere later you'll need to update smith of them?
In that case i'd make an updateView method, that can be called from another classes and make any changes.
All values that can be changed make a local variables in order to access them in that method.
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
Hi I'm new to Xcode and don't quite understand the difference between all the view controllers. Eg what is the difference between a uiviewcontroller with a collection view on it and a uicollectionview controller it self? Confused as to why I wouldn't use a view controller then add views onto it depending on my requirements eh table, collection etc. Can anyone help to shed some light?
It's based on your requirements. You may change some properties with your View controllers. But when you use as part of its' controllers, you can't change it.
For example you Can´t change UICollectionView Size of UICollectionViewController(see this).
In these case, you must use UICollectionView in viewcontroller. As like this, if you want to customize some property but functionality are same in all.
Here I mention some ref for you: Ref
You can take UICollectionViewController as a template which will have every thing for you. And view controller is simple scracth pad, you have to add things on it. There are some pros and cons in view controller you have to do every thing yourself, but collectioViewController you got controller with collectionView. But you can not change things as easily in it.
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 8 years ago.
Improve this question
I understand the differences between tableVIew:didSelectRowAtIndexPath: and prepareForSegue:sender:. Furthermore, both can be used to display a new view when a cell is tapped. Are there use cases where might one choose tableView:didSelectRowAtIndexPath: rather than prepareForSegue:sender:? If so, what are those use cases?
Historically tableView:didSelectRowAtIndexPath: was available in iOS from the start; prepareForSegue: has only been available recently, with the whole StoryBoard architecture. Thus, these days, prepareForSegue: is preferred.
Note that the actual segue function is prepareForSegue:sender:. When a UITableViewCell initiates the segue the sender will be the selected cell. Thus you've got everything available as you would in tableView:didSelectRowAtIndexPath:.
Also, segues are used when transitioning to another view controller. If your app won't have a cell selection transition to a view controller, then you can't use a segue. For example, if a cell selection, in your app, is going to do something with animation or directly with views, you'd use tableView:didSelectRowAtIndexPath:
I use the 'old way'. Why? Because I'm used to it, and it makes sense to me. It was available from the start.
prepareForSeque:, on the other hand, was added recently. Most people that have use didSelectRowAtIndexPath in the past are used to it, it works, and, besides, if it ain't broke don't fix it!
If you are using a UITableView where the rows are dynamic, you will want to invoke your segue in tableVIew:didSelectRowAtIndexPath
If you look at the screenshots for my iPad app, for example, I dragged out each segue from the static cell.
https://itunes.apple.com/ml/app/h4-spanish-lite/id388918463?mt=8#
Unfortunately, now I want to have French and Chinese language apps. I don't currently have a conjugator for French and it doesn't apply to Chinese. Also, some of the games don't work in Chinese. So, now I need to dynamically create my table. I could create separate storyboards but that seems like a hassle.
With tableVIew:didSelectRowAtIndexPath you're getting the selected item. At the time you know the selected item you can call prepareForSegue: to set up the next UIViewController designed by the use of Storyboard, e.g. initialize some properties.
Edit: You just use prepareForSegue: if you're using Storyboard, available since iOS 5