Home > Archive > Smartphone Developer Forum > April 2006 > Smartphone Home vs. WM5 Today screen plugin lifecycle
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Smartphone Home vs. WM5 Today screen plugin lifecycle
|
|
|
| We're porting an app from Windows Mobile 5 to Smartphone; in WM5 the
plugin DLL stays resident from when it is registered and first invoked;
the lifecycle in Smartphone appears to be quite different with the DLL
being instantiated/streamed to persistent storage/destroyed before
home.exe loads it. If the user changes the home screen layout or turns
off the phone, the whole process repeats. An app implemented in the
context of a DLL that is not always resident will not always be
available.
What's the best way to implement a persistent app like a Today screen
DLL in Smartphone? Needs to be able to intercept/process windows
messages whenever the phone is on. Is there a better alternative than
a plugin?
Thanks!
| |
|
| Dave wrote:
> We're porting an app from Windows Mobile 5 to Smartphone; in WM5 the
> plugin DLL stays resident from when it is registered and first invoked;
> the lifecycle in Smartphone appears to be quite different with the DLL
> being instantiated/streamed to persistent storage/destroyed before
> home.exe loads it. If the user changes the home screen layout or turns
> off the phone, the whole process repeats. An app implemented in the
> context of a DLL that is not always resident will not always be
> available.
I'll spare you the details of whats going on here, but if you feel you
need to have a SP home screen COM dll then I can give you a breakdown
> What's the best way to implement a persistent app like a Today screen
> DLL in Smartphone? Needs to be able to intercept/process windows
> messages whenever the phone is on. Is there a better alternative than
> a plugin?
yes, a service is designed to be persistant:
http://www.pocketpcdn.com/articles/services.html
and this article applies to both ppc and sp.
riki
--
ThemeChanger for Smartphone : http://homepages.inspire.net.nz/~gambit/
AbstractStart for Smartphone :
http://homepages.inspire.net.nz/~gambit/AbstractStart/
Working in groups is difficult when you're omnipotent.-- Q
| |
|
| Interesting - I wasn't aware you could implement services in the sp/ppc
environment.
Other than the count limitation on background processes and the extra
complication of debugging a service, are there advantages/di vantages
to doing it as a service rather than as a background process?
Thanks
riki wrote:
> Dave wrote:
>
> yes, a service is designed to be persistant:
> http://www.pocketpcdn.com/articles/services.html
>
> and this article applies to both ppc and sp.
>
> riki
>
| |
|
| Dave wrote:
> Interesting - I wasn't aware you could implement services in the sp/ppc
> environment.
>
> Other than the count limitation on background processes and the extra
> complication of debugging a service, are there advantages/divantages
> to doing it as a service rather than as a background process?
signing is your biggest divantage, if the service is used on a
software locked device then it needs to be privilege signed.
advantage is keeping the number of system process down, as SP is not to
far from its limit on bootup.
riki
--
ThemeChanger for Smartphone : http://homepages.inspire.net.nz/~gambit/
AbstractStart for Smartphone :
http://homepages.inspire.net.nz/~gambit/AbstractStart/
----Police Tagline----DO NOT CROSS----Police Tagline-----
|
|
|
|
|