I want to support both users running iOS5 and iOS6. But for instance UIViewController's method -viewDidUnload is deprecated in iOS6. So how would I use it for users running iOS5, but not for users running iOS6?
You can continue having this method in your code, it will just not be called. If you really wish to have it called, you can invoke it in didReceiveMemoryWarning. In fact, move the code there for old iOS as well.
Other changes that might interest you are related to rotation. You can implement both the new iOS6 methods as well as keep the old ones, and they will not interfere with each other.
while it is indeed okay to continue to have the call to viewDidUnload …
the information from the WWDC talks on this is that you should not only not have viewWillUnload and viewDidUnload for iOS6 situations, but that you should just go ahead and remove it for code that will be used for both iOS 5 and iOS 6.
the justification given by the apple dude narrating the WWDC slide presentation is that apple did some amount of study, and concluded it solved a whole class of crashers that were avoidable, and dealt only w/tiny bits of memory.
the recommendation is that anything that is currently in one of these that's absolutely necessary to your app should probably be appearing in viewDidDisappear:animated: or in dealloc (for large shared stuff that needs to give back memory), and that there will be many cases where neither is necessary.
(not an advocate, just relaying what i learned from the WWDC material on the subject …)
Related
trying to use the initwithcoder init method in my custom NSControl Class.
It works just fine and does what I need it to do. However and this leads me to asking this question on this here forum -> in the class reference of NCControl when you scroll down to initWithCoder and click on it it states SDKs
macOS 10.10+ which leads me to believe that it would not work and do what I need it to do on versions prior to that... Unless Apple's documentation once again is wrong...
BTW - from Apple's own reference (Online as well as offline) apparently the NSCoder Class is also suffering from this SDKs macOS 10.10+
https://developer.apple.com/reference/foundation/nscoder
The strange thing is that in the documentation describing how a NIB is loaded and which init methods it calls on various objects, it describes initWithCoder as being the designated initializer but that documentation is from before 10.10.
Thanks to anyone who can set my mind at ease ;-)
Yes it will not work before defined version. I think you are checking versions of Swift, if you select objective-c you should see version 10.0+ which i think should work fine for your need. If you change the language, you can put your mind to ease :)
I am assuming if you would like to support things that far back you are going to use objective-c over swift.
Check the below image for NSCoder documentation after you select objective-c on right hand side.
My question is based on the fact that, one might have multiple smaller projects and then wants to integrate them into one bigger one, for coding efficiency.
I saw multiple project's where the App Delegate wasn't used at all, I think the Adium project was one of them. I also was a couple of times able to recreate it in the past, now I cannot remember how.
I figure a basic NSObject inherited class would fit, plus its instantiation and connections.
The question is, is it possible to work without App Delegate (or have a workaround)?
You need an app delegate, if you want to implement some of the methods declared in the NSApplicationDelegate protocol to respond to certain app life-cycle events. If you don't need to implement any of those, you don't need an app delegate. Some delegate methods also have notification alternatives.
OK, from your comment...
I mean having no additional code in AppDelegate
Then yes.
It is not only possible, it is recommended. Exactly for the reason that you have said.
The app delegate is there as a communication layer between the app and the OS. i.e. "the app has started", "the app is about to close", "the app just received a notification", etc...
All of these is what the app delegate is for.
The logic of your app should not go anywhere near you app delegate. Like you said, you may have different apps or different targets in your app that use different app delegates.
If you have code in there then you would have to duplicate it to each copy.
There are many other reasons too.
Here is a quick link... http://www.hollance.com/2012/02/dont-abuse-the-app-delegate/
There are many others about not using the app delegate.
I wrote a OSX App using ARC, just load a tableview without any cells,the memory is up to 50M+,
I want to know any way to optimize it.
(Can not use release , I can not find any other way)
================================= UPDATE========================================
I created a demo Application , just a blank window, the memory is up to 40M+, sigh
There shouldn't actually be a difference between using ARC or not--think of ARC as adding release calls for you automatically. This answer has an illustration of this point.
This is just a theoretical question. It was born from a real problem in my app, but I re-designed the problem out of the application. But the question remains:
If in my app delegate I write my singleton object to disk upon applicationWillTerminate: but also use NSNotificationCenter to call updateSingletonData upon UIApplicationWillTerminateNotification in some view controller, which will happen first? Will my data be written to the singleton, then the singleton be written to disk, then the app terminates? Or will the reverse happen, with the singleton being serialized and then the singleton updated (worse), or will the app just terminate after a certain amount of time if the serialization takes too long (much worse!)?
I guess this shows my lack of understanding of the guts of Springboard... thanks to anyone who can shed some light here.
A couple of things to note here:
Only Apple know the order these will happen in, as they wrote the code that does it.
You shouldn't care about the order these will happen in. If you do care, then you've designed your code badly.
In reality, you could go and check what order the happen in - for your particular device, for your particular iOS version, etc.
But really, you shouldn't care what order they happen in. From the sounds of it, you should be either firing off to the view controller to write the data before saving in applicationWillTerminate:, or letting the view controller handle saving after it's written its data.
This question is old and the response by #mattjgalloway is correct in terms of code quality but, for the sake of the knowledge, I just saw in the docs that the notification is posted after the UIApplicationDelegate method is called (emphasis mine):
After calling this method, the app also posts a UIApplicationWillTerminate notification to give interested objects a chance to respond to the transition.
https://developer.apple.com/reference/uikit/uiapplicationdelegate/1623111-applicationwillterminate
I am an experienced C/C++ programmer, and familiar with memory management issues. I've also shipped a couple small iPhone apps in the past. I am attempting to check my latest app for memory leaks, and I can't make any headway, because there are so many of them. Just starting the app and viewing the first screen shows over 12,000 leaks.
I know I've probably overlooked various things, but I was reasonably cautious in writing the code. I made attempts to release everything I alloc'ed in my dealloc method. It is like my app delegate never gets released, because I can see a couple things that are only alloc'ed once, in the app delegate's init method. They are never modified, and are released in the dealloc method.
This app is built around a tab controller, with around 15 views mainly set up using Interface Builder.
Any help would be appreciated.
Instruments of apple is pretty advanced.. it can show you the exact method that originally created the memory leak, I suggest taking a look at those methods and carefully reading your code ,there usually is this line of code in there and you thought OMG how could I be that stupid.
If that doesn't help, try to "Analyze" with xcode, its pretty good at finding errors and leaks in your code and saved my * a couple of times.