windows phone 8, applicationsettings not persisted
Asked Answered
M

2

6

I have the following strange behaviour in my Windows phone 8, C# App.

I am saving a Setting with:

private void SaveProperty<T>(T property, string propertyName)
    {
        if (IsolatedStorageSettings.ApplicationSettings.Contains(propertyName))
            IsolatedStorageSettings.ApplicationSettings[propertyName] = property;
        else
            IsolatedStorageSettings.ApplicationSettings.Add(propertyName, property);

        IsolatedStorageSettings.ApplicationSettings.Save();
    }

When the app runs, I can read all settings I stored in IsolatedStorageSettings.ApplicationSettings.

But when I re-open my app (open it from the app list), the IsolatedStorageSettings.ApplicationSettings-Dictionary contains Zero (0) Keys and Values.

Am I missing something?

I used the ISETool.exe to take snapshots of the IsolatedStorage of my app (thanks to chepene). I saw this behaviour: when I wrote the Settings (that means after the SaveProperty<T>() function finished), and the app is still running, I have the Settings saved in _ApplicationSettings. This agrees with my Observation that I can read from the IsolatedStorageSettings.ApplicationSettings when the app is running. The _ApplicationSettings-file also exists when the is tombstoned or not running (when I can Access it by Holding the back-button of the phone and when the app is closed with the back-button).

But when the app is opened again (via the app list), the _ApplicationSettings-file is gone...

I also see that, when I'm writing a file into the IsolatedStorage with:

SharedStorageAccessManager.CopySharedFileAsync(
    Windows.Storage.ApplicationData.Current.LocalFolder, fileName+"orig", 
    Windows.Storage.NameCollisionOption.ReplaceExisting, fileID);

and when I then don't read this file, it is gone when I open the app the next time.

By the way, to avoid confusion: I am not reinstalling the app each time I open it.

If you need more Information please ask.

Any help appreciated.

Moyer answered 13/6, 2013 at 11:6 Comment(10)
are you using emulator or a device? if emulator is used, are you exiting the application by stopping the visual studio debug session or "back" button in emulator?Unsocial
After Save() method, look (with Isolated Storage Explorer) what files exists in your app isolated storage.Toomey
@Beytan Kurt: I am using a device, but I also checked the Emulator: same behaviour. I am not directly exiting the app, rather than re-opening it by opening it from the app list.Moyer
@Chepene: what files shall I look for?Moyer
I can't tell you exact name right now (if you need, I can tell you it later), but smth like: applicationsettings or appsettings... If file exists, you will notice it at once.Toomey
@Chepene: I was just looking at MSDN (msdn.microsoft.com/en-us/library/windowsphone/develop/…) and they write: "You can’t view app settings that are stored in the local folder in Isolated Storage Explorer. These are settings that the app saved by using the IsolatedStorageSettings class.". So I probably won't see the appsettings...Moyer
Hmm.. it is strange. When I use ISETool.exe ts xd f8ce6878-0aeb-497f-bcf4-65be961d4bba c:\data\myfiles I have a snapshot of all files and file with settings is among them. I will verify everything and come back later.Toomey
@Chepene: okay, you are right and MSDN is wrong (they also said, I couldn't run ISETool when app is running, but it works...). To see what I learned, please read the edited post, as it is a bit longer ;)Moyer
Just to clarify: You close app, file exists, you open app (just close and open without reinstalling), file dissappear, is it?Toomey
@Chepene: that is exactly right.Moyer
M
0

Thanks to quetzalcoatl I found the solution: I am storing all my files in the root Folder of my app. At the start I am then reading all my files (via a DataContractSerializer) and casting it to my model. Since it happens sometimes that my files get corrupt, I delete every file which throws a SerialzationException. But as I read every file, and since _ApplicationSettings is not castable to my model, I am deleting _ApplicationSettings automatically.... So I learned that the ApplicationSettings are,just a file in the root folder, which I am allowed to read and delete. So the quintessence is to never write into the root Folder.

Moyer answered 13/6, 2013 at 19:41 Comment(1)
Great! I'm glad you've found it and that it was not yet another strange WPhone behaviour:) Remember to mark your answer as "accepted" (that "V" tick) so that everyone knows it's solved.Affiche
A
3

With AppSettings, I've seen something similar on WP7/7.5, but it happened only when my property-value's type was a class that was not known to the serializer.

Are you sure that there were no exceptions:

  • during Save
  • during App Exit (since the App may dump the settings at that point)
  • during the time that App loads the settings for the first time after launch?

Note that this doesn't necessarily must mean the app crashing. I mean, any exceptions, those internally silenced or user-handled too. Please check the VisualStudio's Output panel for "first chance exceptions" log. If any I/O or security or serialization exception shows up, then investigate there. If i remember well, there's even a whole set of isolated-storage exceptions that are easily interceptable from debug/exceptions menu.

However, the issues I had with unknown or nonserializable types does not explain at all why your extra non-appsettings files would evaporate.

Another thought: maybe some additional tool performs something like 'clean deploy' for you? I don't remember exactly, but I think that VisualStudio's deployment cycle was quite plain:

  • rebuild
  • remove/uninstall old app from device -- so probably purges isolatedstorage
  • install new app onto device

So, maybe that's the cause? Hm.. on afterthought and re-reading your question again, you've said about running the app from the applist, so that rather is not the case. Be sure to check firstchance exceptions then!

Affiche answered 13/6, 2013 at 13:7 Comment(4)
I got a System.Runtime.Serialization.SerializationException in System.Runtime.Serialization.ni.dll. But now I just tried: IsolatedStorageSettings.ApplicationSettings.Add("test", "testwert"); I didn't do any fancy things. Just add a simple string. That can't be to hard for the Serializer... So, what can I do, now that I saw this Exception? Wait, I forgot to tell you, that this exception occurs when the app starts. Not when the Settings are saved...Moyer
Let's try to intercept it and check what the message says. Stop the app, go to VisualStudio, to Debug menu, then 'Exceptions..' then in the tree find that namespace and exception and check the "When thrown". Now try to launch the app via 'Debug' one or two times. If the exception shows up, then the debugger has great chance of immediatelly stopping. If it happens, you'll get typical 'exception assistant' and you will be able to read the message, check the stacktrace and so on.Affiche
However, the sole "Debug" might erase old app settings.. I don't remember it, sorry. But I'm quite sure that I intercepted and investigate my SerializationExceptions in that exact way (but mine were happening at AppQuit, not AppStart).Affiche
Thank you so much! I found the solution. Please see my own anser as it is a bit longer. Thanks again!Moyer
M
0

Thanks to quetzalcoatl I found the solution: I am storing all my files in the root Folder of my app. At the start I am then reading all my files (via a DataContractSerializer) and casting it to my model. Since it happens sometimes that my files get corrupt, I delete every file which throws a SerialzationException. But as I read every file, and since _ApplicationSettings is not castable to my model, I am deleting _ApplicationSettings automatically.... So I learned that the ApplicationSettings are,just a file in the root folder, which I am allowed to read and delete. So the quintessence is to never write into the root Folder.

Moyer answered 13/6, 2013 at 19:41 Comment(1)
Great! I'm glad you've found it and that it was not yet another strange WPhone behaviour:) Remember to mark your answer as "accepted" (that "V" tick) so that everyone knows it's solved.Affiche

© 2022 - 2024 — McMap. All rights reserved.