Mark,

thanks for the response.


You are right if the state can be kept in a persistent store, it is
the way to go.

However if you want the widget to be a window to what a service does,
can one of the buttons on a widget start the service, stop the
service, and also collect some stats from the servcie.

In such a case can the widget provider and the service stay in the apk
file and can the update messages rely on the static variables that the
service keeps around.

Thanks
Satya

On Thu, Sep 17, 2009 at 5:59 AM, Mark Murphy <[email protected]> wrote:
>
> Satya Komatineni wrote:
>> The app widget documentation indicates that the "widget provider"
>> being a receiver of a broadcast service may not exist (the process)
>> beyond the completion of the call.
>>
>> If I want to maintain state between two broadcast events, such as say
>> widgetProvider.onUpdate(), can I start a local service and leave it
>> hanging there until my widgets are disabled? If I didn't explicitly
>> stop that service will it be loaded again and resumed when the device
>> wakes up.
>
> Oh, please don't. There should be no need to keep a service in memory
> just to maintain some state. Since the app widget itself does not reside
> in your process, the widget framework allows you to keep your widget up
> to date without consuming much memory.
>
> Just persist whatever state you want to a file, SharedPreferences,
> database, etc.
>
> --
> Mark Murphy (a Commons Guy)
> http://commonsware.com | http://twitter.com/commonsguy
>
> Need help for your Android OSS project? http://wiki.andmob.org/hado
>
> >
>

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

Reply via email to