Android Question Almost solved: Widget life cycle

[udg]

Hi all,

I'd like to rewrite part of an app as a widget, but I'm not sure about the persistence of a few values so I ask it here.

Originally my app was made up of two services implementing static broadcast receivers and two activities, one for toggling on/off the special actions in the services and the other for config purposes.

Now, drawing the widget, I placed on it two buttons, one for the old on/off action and the other to start the config activity. So far so good.
My doubt concerns the correct placement of those global vars needed for the services proper functioning.
Should I place them in the widget-service globals?

If so, does the widget life cycle assures those vars are always available with their current values to an eventually starting service requesting them? Or are there times when the OS could kill the widget (to recreate it later) and an OS started service could risk not to find the needed var?

If you confirm that a var placed inside the widget-service is somewhat "permanent" I would code my stuff this way:
1. all relevant vars in widget_service globals
2. on widget_service create do all the initialize needed (file, list..)
3. on widget_service start do read vars current values from file
Now, using the buttons on the widget I can modify vars' values and save them to file.
If one of the broadcast receiver starts, it reads current values from the widget_vars globals and all works as expected.

Last point. If the above scheme works, what happens if I remove the widget from its home screen?
I mean, what happens if the OS sends the broadcast set in the manifest? There's no widget running to offer the called service the vars it needs..so what?

Sorry if all the above is worded in a so confused way, but I find it difficult to explain this stuff even to myself :-(

Umberto

 

[udg]

A step closer..

Although I prefer 3 specialized services, I could live with a single service able to both listen to broadcast messages (as set in the manifest) and to the widget relatad ones.
This way, all needed vars are managed by that single service and so are always available when needed.

BUT, what happens when I remove the widget from the home screen?
Will the OS awake the service in order to receive the broadcast set in the manifest? If so, the functionality gets preserved but the user looses the ability to operate on the vars (since it removed the widget) and the service will work on the basis of the last saved config.

Umberto

 

[Erel]

Will the OS awake the service in order to receive the broadcast set in the manifest?

Yes.

 

[udg]

Hi Erel,

thank you for confirming my thoughts.
Do you recommend the simplified scheme outlined in post #2 or having 3 separate services it's the same because the one devoted to widget messages is always active and ready to support the other two with global vars settings?

Umberto

 

[Erel]

Note that it doesn't matter where you place the process global variables. All process global variables will live as long as the process lives.

As Service_Start can be called multiple times you should use Service_Create for any "initialization" code.

 

[udg]

Thank you, Erel.

What I ignore is the expected process life of a widget.
Does it start with a device cold start and stay alive (i.e. loaded in memory and ready to react through its services) until the device is turned off?
Or has it a life-cycle like the one outlined for Activities?

My concern is all about the service used to serve widget-related intents. Is it to be considered always loaded in memory (along with its global vars) or the OS could discard it and eventually re-load it when needed?

Umberto

 

[Erel]

Your process will not stay alive all the time. Only when the user interacts with the widget or when the widget needs to be updated.