indeed... i am experiencing this problem. my app uses a background 
service that sometimes gets killed by the system. When that happens the 
sharedprefs are lost. If the app force closes due to some unhandled 
exception the prefs are also lost for good.  Im moving to good old .conf 
files :P...

Beware fo the sharedprefs...


Cheers,
Filipe

scanning_it wrote:
> Yeah well it would be nice if we could find the problem. It is pretty
> annoying to have this problem using the basic SDK features.
>
> On Apr 24, 6:03 pm, bo <bost...@gmail.com> wrote:
>   
>> That's pretty much what I do also (why take any chances?). Now - all
>> that business with & gets me thinking. I'm actually storing some
>> snippets of unescaped HTML (which I actually don't care about much). I
>> think these I'll move to Bundle and see if my "real" preferences will
>> persist
>>
>> On Apr 24, 3:09 am, scanning_it <festival.s...@googlemail.com> wrote:
>>
>>     
>>> Thank you Dianne for joining the discussion.
>>>       
>>> I will look into my code again but I'm sure that this is the only way
>>> I am writting to theSharedPreferences:
>>>       
>>> settings.edit().putString(SOME_STRING, "Hello world.").commit();
>>>       
>>> So there shouldn't be a problem with that one.
>>>       
>>> Is it possible thatSharedPreferencescould get lost when a background
>>> services writes to theSharedPreferencesfile and gets killed during
>>> that process? In my background service I am updating e.g. some shared
>>> prefs that tell me if I have set a specific notification or not.
>>>       
>>> Could this usage in services be a problem?
>>>       
>>> In addition it would be interesting why a lot of users are complaining
>>> that their settings got lost after updating my application? I have
>>> never had that problem testing my own app. But a lot of my users are
>>> reporting that. (My application has 97.000 active installs and is
>>> called "Missed Call")
>>>       
>>> I'm looking forward reading your response.
>>>       
>>> On Apr 24, 10:17 am, Dianne Hackborn <hack...@android.com> wrote:
>>>       
>>>> You really really should commit the data after you make each batch of
>>>> changes, as the docs say.  It is certainly very possible for the system to
>>>> kill your process between onPause() and onStop() if it is under memory
>>>> pressure.
>>>>         
>>>> On Thu, Apr 23, 2009 at 9:56 AM, bo <bost...@gmail.com> wrote:
>>>>         
>>>>> I doSharedPreferences.Editor.commit() in couple of places. 1.
>>>>> Immediately after setting the preference. 2. in Activity#onStop.
>>>>> Nevertheless when I restart the app the preferences are gone. Any more
>>>>> ideas? I do create prefs programmaticaly after harvesting these from
>>>>> user (username/pwd)
>>>>>           
>>>>> On Apr 21, 11:00 pm, Chander Pechetty <cspeche...@gmail.com> wrote:
>>>>>           
>>>>>> Sorry, I was referring to the settings created using
>>>>>> PreferenceActivity screen using xml. Your actual preference values do
>>>>>> not help much in diagnosing the issue.
>>>>>>             
>>>>>> Example snippet from loadingpreferencesfrom xml:
>>>>>>                     <CheckBoxPreference android:key="pref1"
>>>>>>                         android:title="pref1"
>>>>>>                         android:summaryOn="SummaryOn"
>>>>>>                         android:summaryOff="SummaryOff"
>>>>>>                         android:defaultValue="true"
>>>>>>                         android:persistent="true"/>
>>>>>>             
>>>>>> Forpreferencescreated programatically, you can use
>>>>>> Preference.setPersistent(true);
>>>>>>             
>>>>>> If no Settings screen is present, and everything is through your
>>>>>> program, then batchSharedPreferences.Editor.commit()'s should be
>>>>>> fine.
>>>>>>             
>>>>>> I had a similar problem as yours, but have not faced it again so far.
>>>>>> Other than the known issue mentioned in the previous post, I don't
>>>>>> know what else the problem could be unless you post your code
>>>>>> perhaps...
>>>>>>             
>>>> --
>>>> Dianne Hackborn
>>>> Android framework engineer
>>>> hack...@android.com
>>>>         
>>>> Note: please don't send private questions to me, as I don't have time to
>>>> provide private support, and so won't reply to such e-mails.  All such
>>>> questions should be posted on public forums, where I and others can see and
>>>> answer them.
>>>>         
> >
>   


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to