NSUserDefaults won't delete object for key - authentication

When the user logs in to my application, I download a token from my JSON server and store it in NSUserDefaults, as such:
[[NSUserDefaults standardUserDefaults] setValue:token forKey:TOKEN];
When the user logs out in a subsequent page, I call this method and return back to the login screen:
[[NSUserDefaults standardUserDefaults] setObject:#"" forKey:TOKEN];
(and before that I called [[NSUserDefaults standardUserDefaults] removeObjectForKey:TOKEN];)
It doesn't matter how I try to delete this user defaults, whenever I load up my app, it always shows me the full token and not an empty string nor a null value.
When reading around, apparently it has something to do with read write cycles? But even if i leave it for a while, the key still remains. Is this a simulator problem?
Whatever the cause, how do i get around this?

It's the simulator problem of caching the memory first. It only happens in xcode and should not happen on a device.

Do you call
[[NSUserDefaults standardUserDefaults] synchronize];
after the key was deleted? Maybe you are not persisting the changes into the database.

Related

Fabric macOS exceptions not caught at times?

Crashlytics shows me everything's going great, when in fact several people are experiencing crashes that aren't being reported - yet I do in fact see some crashes making their way through into Crashlytics. I can't understand what's going on.
I'm doing the usual I always have:
[Fabric with:#[[Crashlytics class], [Answers class]]];
first thing in applicationDidFinishLaunching. I also have:
// We need these flags in order to capture crashes more reliably
if (![[NSUserDefaults standardUserDefaults] boolForKey:#"NSApplicationShowExceptions"]) {
[[NSUserDefaults standardUserDefaults] setBool:YES forKey:#"NSApplicationShowExceptions"];
}
if (![[NSUserDefaults standardUserDefaults] boolForKey:#"NSApplicationCrashOnExceptions"]) {
[[NSUserDefaults standardUserDefaults] setBool:YES forKey:#"NSApplicationCrashOnExceptions"];
}
[[NSUserDefaults standardUserDefaults] synchronize];
directly before I register with Fabric. I also upload dSYMs every time and don't see any warnings from Fabric.
I've got a bunch of users crashing and sometimes they send us crash logs from either the machine or the window they're presented for crashes. Some people aren't seeing neither the crash window nor are they seeing crash logs accumulate in Console.app, nor am I seeing any crashes in Crashlytics - yet they have demonstrated countless times via videos that the app crashes soon after it launches.
What else can I do to ensure I get crashes reported always for a mac app?
This probably doesn't answer the question entirely, however it seems catching all exceptions / crashes on macOS is tricky (as mention by Fabric on their page). It doesn't help when a lot of the code it's crashing on is inlined C / C++ code. I don't think this is a Crashlytics issue as such, however it looks like a limitation where some crashes, including those force exit(..) call deep inside certain 3rd party libraries aren't really crashes and thus aren't caught.

OSX preferences file - removePersistentDomainForName has different functionality in 10.8?

This code works for one of our developers on 10.7 but not for me on 10.8
working = it deletes the preferences .plist file for the bundle. The dev on 10.7 also has a lockfile whereas I do not. It's not a problem of file access - I tried [resetStandardUserDefault] and that made a new file, but that's not exactly we want to do.
NSString *appDomain = [[NSBundle mainBundle] bundleIdentifier];
[[NSUserDefaults standardUserDefaults] removePersistentDomainForName:appDomain];
I am having trouble locating any info about changes in 10.8 - does this sound familiar to anyone?
I have the same issue and indeed there seems to be no info about any changes, also don't get any errors or warnings. [NSUserDefaults resetStandardUserDefault] doesn't do anything for me. What I do currently is simply overwrite the default values to reset them (give [[NSUserDefaults standardUserDefaults] setValuesForKeysWithDictionary:
[NSDictionary dictionaryWithObjectsAndKeys:...]] the same input as originally given to [[NSUserDefaults standardUserDefaults] registerDefaults:
[NSDictionary dictionaryWithObjectsAndKeys:...]].
Not really an answer, but I don't have enough rep to comment..

How to force localization at compileTime or better at runtime

i've got a IOS project with many different images to display depending on the language, and i can't find a way to force loading the correct image at runtime (not switching a language to another).
Actually it seems that the files are loaded before the AppDelegate get a chance to interfer.
if i do in appDelegate (didFinishLaunchingWithOptions:):
[[NSUserDefaults standardUserDefaults] setObject: [NSArray arrayWithObjects: #"es", #"en", nil] forKey:#"AppleLanguages"];
It's already too late, image are already loaded in the wrong language. So in order to accomplish this i have moved the NSUserDefaults into the main() call, and this tricks works. But my questions are: Do Apple will reject my app? And is there a better, clean approach to synchronize a language at compile time (or with plist or something like that)?
Update
it seems that just replacing [[NSUserDefaults standardUserDefaults] setObject: forKey:], further step before calling my nib file did the trick. It's like [NSUserDefaults standardUserDefaults] is called asynchronously. So maybe the setter method was actually evaluated after my nib file was loaded. But can i change the localizable setting via info.plist ?
You can localize the Info.plist (InfoPlist.strings), which lets you set the Default.png for each language.

AppDelegate int value keeps getting reset

In my project AppDelegate file, I have an int declared called correctAnswersCountR1. So in the app they take a small quiz and that variable keeps track of how many correct answers they got. Now somewhere else in the project I use this variable like so:
int r1score=appDelegate.correctAnswersCountR1;
The problem is that apparently if I exit the app and come back, the value isn't remembered, and is set back to its default value. How can I store this number so that it is remembered if the user closes the app and comes back?
You can use NSUserDefaults to store your value:
**Saving**
//Do this right before the app exits
NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];
// saving an NSInteger
[prefs setInteger:42 forKey:#"integerKey"];
// This is suggested to synch prefs, but is not needed
[prefs synchronize];
**Retrieving**
//Do this when your app is loaded again
NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];
// getting an NSInteger
NSInteger myInt = [prefs integerForKey:#"integerKey"];
You could set up core data for your project, though unless you plan on storing more information persistently for your app Core Data might be a bit of overkill. You could also try writing it to a file and just reading it on load.
Edit: For this specific scenario Oscar's answer seems more appropriate, though depending on where you plan on going with your app, CoreData or a file may be a good choice.
You'll want to do some research about NSUserDefaults.
Here is the apple documentation
On another note it's not considered best practice to store data in the AppDelegate
You have to use a preferences storing mechanism. I'm not all too familiar with the iPhone toolkit, but on Mac OS X and Cocoa there's NSUserDefaults. When your app launches, you would load the value from the user defaults (preferences) through [[NSUserDefaults standardUserDefaults] intForKey:#"count"], and whenever the value changes, you would call [[NSUserDefaults standardUserDefaults] setInt:answerCount... forKey:#"count"].
I'm pretty sure that you want to write the value into a file to make it persistent.
This is because an application which moved to the background might be terminated for example if the system measures out that it needs some more memory.
So it kills the application and restarts it when the user switches over.

Using iPodMusicPlayer without giving control to iPod in background

I'm developing an app with a very specific focus on shuffling songs within a selected playlist. When the app launches, it lists all the user's playlists, and then when one is selected it loads it into my music player view and get's going. I'm using an MPMusicPlayerController iPodMusicPlayer to handle doing this because I'm pretty new at iOS development and it handles backgrounding and everything nice and easily for me. I want music to continue playing in the background and I like how whatever I change within my app is also reflected in the iPod app. However, I don't want the user to be able to change things in the iPod app and then return to mine. Since my app is all about shuffling, the user could easily go into iPod and disable shuffle, then come back to my app and the experience is ruined. I also don't want them to change the playlist from within iPod.
Can anyone help me think of a way to accomplish this? Play/pause/skip/prev/volume is no problem from within iPod (I want that to be possible), but I don't want changing the song queue to be possible. Is there a way I could add a handler in my app that catches if the user changed something while my app was in the background (and if so, stop music and reset my app to the initial screen)? I'd really appreciate any suggestions. I'm hoping something like this is possible before I venture into using AVPlayerQueue or the like (as a side note, can you play DRM'd files with AVPlayerQueue?).
What I would do is set a bool when backgrounded:
NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];
[prefs setBool:YES forKey:#"BACKGROUNDED"];
Then, in your handler for the MPMusicPlayerControllerNowPlayingItemDidChangeNotification that you should be implementing so that you have that control, do the following:
NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];
if ([prefs boolForKey:#"BACKGROUNDED"]) {
[prefs setBool:NO forKey:#"BACKGROUNDED"];
exit(0);
}
It might be too abrupt, depending on when it checks this code (I don't know when it does in your project) but that should accomplish your goal. exit(0) is the way to terminate your app without throwing an exception. Is that helpful?