I was just reading that this delegate has only been added in iOS 4.2
[CLLocationManagerDelegate locationManager:didChangeAuthorizationStatus:]
Turn out having that method crashed devices with older iOS version.
What would be the equivalent of that method in iOS 4.1 for example?
Thank you,
Tee
In earlier versions, you the locationManager:didFailWithError: delegate method will be called with error saying kCLErrorDenied
Having the locationManager:didChangeAuthorizationStatus: delegate method in your code did not cause your crash. Somewhere you must have sent an authorizationStatus message to the CLLocationManager instance which isn't recognized prior to 4.2.
Related
I am working on an iPad application which is converted to ARC. Application is for os >= ios 5.0. So my doubt is that, how do I manage viewOutlets? I use -(void)didReceivememoryWarning to set ViewOutlets to nil. But in ios 5.0 and 5.1 application shows lots of memory leaks. As -(void)viewDidUnload is deprecated in ios 6.0 , I am not using the same in the application. Is the correct way to manage outlets? Please give me a quick reply.
ARC (automatic reference counting) features is available in iOS 5 and ahead (iOS 6 and so on..) version.
When you are using ARC unable in your project, you dont need to `manually release any object` that you have allocated for your stuff.
ARC will automatic handle this one.so it will beneficial for `Memory Management`.
Hope ,You understand what i m trying to say.
for more clarification , please refer below link:
To ARC or not to ARC? What are the pros and cons?
ARC, worth it or not?
Good Luck !!!
There is NO DIFFERENCE in how you code for iOS 5 vs. iOS 6.
If you are having problems, it's because you don't understand what viewDidUnload does and when it's called.
viewDidUnload is called when the view of the controller is unloaded. In iOS 6, views are never unloaded. In iOS 5 and before, views were almost never unloaded either. So in both cases, pretty much viewDidUnload is never called.
If your program is leaking stuff, it's because you are not releasing things. You always need to release instance variables in dealloc. I suspect that this is your problem.
When the controller's view is unloaded (which only happens in iOS 5 and before, but this is irrelevant), viewDidUnload allows you to optionally discard some resources to save memory, as long as they are resources that will be re-created when the view is loaded again. This usually includes properties and instance variables that are outlets (since when the view is loaded, it will load the Xib again and re-connect the outlets to new objects), as well as any variables that are set in viewDidLoad.
If you coded your program correctly, I can go in there and remove viewDidUnload, and it would not have any effect on the correctness of the program. (Since viewDidUnload is almost never called anyway.)
You should almost never have to use didReceiveMemoryWarning either.
I'm playing around with Julius Guzy's sample code for creating a document based application that can save text files. I ran his code and it works perfectly and the app runs/save files (All in the latest version of Xcode. Though Guzy's sample code compiles using the 10.6 SDK). I'm trying to learn from it and rewrite the code. I have everything in order to compile the app but for the strangest thing in MyDocument.m. I am unable to run it.
#synthesize nsTextViewObj;
Xcode is giving me this error, which I don't really understand it.
Existing ivar 'nsTextViewObj' for property 'nsTextViewObj' with
assign attribute must be __unsafe_unretained
nsTextViewObj; is suppose to be linked to the "File Owners" in IB. I did that in the first place. It beats me why I'm getting that error. SDK conflicts maybe? How can I fix this?
ARC requires some changes to the code. Xcode provides a tool to automatically convert non-ARC code to ARC: Edit / Refactor / Convert to Objective-C ARC…
The Xcode tool is a good start, still I would recommend you to read Transitioning to ARC Release Notes.
I don't know Julius Guzy's code, but probably you should change it to something like:
#interface ifc_name : NSWindowController {
NSTextView *__unsafe_unretained nsTextViewObject;
}
#property (unsafe_unretained) NSTextView *nsTextViewObject;
As the name implies, unsafe_unretained is not safe: when the object is deallocated, your reference is invalid. If you are deploying only to iOS 5 or higher, and OS-X 10.7 or higher, you can use weak instead. With weak your reference will become zero when the object is deallocated.
I have a problem where I'm getting a bad access code for my app running iOS 6. I'm currently segueing to another navigationBar based view, and getting the bad access code inside the class I'm segueing to (during the segue!). The trace goes back to the first thing I release inside of Dealloc (which is just a standard UILabel).
Is this a possible problem with iOS 6? I thought dealloc was deprecated starting in iOS 6? Does anyone have any ideas? Thanks!
You cannot use release with ARC. You probably don't even need to override dealloc.
There is a MFI device that is connected to iPhone 4S (6.0 GM) or to iPad (6.0 GM) via Bluetooth (2.1 + EDR). The project was built on Xcode 4.5 GM. When the app gets EAAccessoryDidDisconnectNotification it will send message [_eaSessionController closeSession];. All these worked nice in iOS 5.1.1 or earler. But on iOS6 with this message I got logs as follows:
-[NSCondition dealloc]: condition (<NSCondition: 0x2e5640> '(null)') deallocated while still in use
Break on _NSLockError() to debug.
Any ideas?
I came across the same issue. This warning is thrown when calling [NSStream close] upon receiving an EAAccessoryDidDisconnectNotification. There should be also some data exchange between the two devices just before the disconnection.
Breaking on _NSLockError will show that at the moment the object is deallocated, some of the threads spawned by the external accessory framework are waiting on conditions. One of those certainly waits on the condition that is being freed, which explains the warning thrown on the console.
I also noticed that the number of threads created by the external accessory framework keeps on growing each time the accessory disconnects then connects, and they seem to be just leaking.
It seems to me that somehow, the external accessory framework does not properly free the resources it allocates, which results in a lot of mess. One of the subsequent effects of this are crashes that happen inside one of those leaked threads during a call to OSAtomicCompareAndSwap64.
I managed to reproduce the issue using a basic sample in which the streams are scheduled on the main thread to avoid any thread management inside the application. I believe it's an accessory management bug on iOS 6 that Apple should be aware of. I'll report it and wait for what they have to say.
Meanwhile, I wonder if anyone of you guys has managed to make any progress on this.
Thanks,
There is no such trouble in iOS 6.1+. To fix this for iOS 6.0 and iOS 6.0.1 please use next solution:
Please note: this is only temp solution allow your users with iOS 6.0 and 6.0.1 continue use your app.
There is a simple hack to avoid application crashes: just create new category and override dealloc method (NSCondition) for iOS 6.0 and iOS 6.0.1:
#import "NSCondition+LeakDealloc.h"
#import <objc/runtime.h>
#implementation NSCondition (LeakDealloc)
- (void) safeDealloc
{
float sVersion = [[[UIDevice currentDevice] systemVersion] floatValue];
if (sVersion < 6.0 || sVersion >= 6.1)
{
[self safeDealloc];
}
}
+ (void) load
{
method_exchangeImplementations(class_getInstanceMethod(self, #selector(dealloc)), class_getInstanceMethod(self, #selector(safeDealloc)));
}
#end
This solution make new leak, after 20 min tests and about 50 BG/FG swithces instruments shows 10 NSCondition leaks (960 Bytes), BUT no one crash!
The issue has been fixed in iOS 6.1.
There are no more leaking NSCondition or external accessory threads. Apple seem to having fixed the issue properly.
i am getting an NSInvalidArgumentException with reason: -[UITapGestureRecognizer initWithCoder:]: unrecognized selector sent to instance
my understanding was that UITapGestureRecognizers were supported in ios4.x?
is it possible to load a different xib file for sub ios5 versions?
As #mit3z states in his comment on the original question, iOS 4.3 supports this feature only when setup up manually with code. It is not supported with Interface Builder.
Apple would have saved us all grief over this if they simply added this as a build-time warning.
I think you have a NSCoding compliant object that is deallocated before the crash. The UITapGestureRecognizer is allocated at its address and when the disappeared object (but not its reference) tries to call initWithCoder on itself, it actually calls this method on your gestureRecognizer instead.
Then your problem comes from that deallocated object but not from your gestureRecognizer.
Be sure to retain all your IBOutlet properties.