>There are several discussions about this. You should search
>the archives.
>
>Many people are in favor of crippling an application in some
>way, rather
>than expiring it after a period of time. To properly expire a
>program, you
>would have to store a date on the device that would not be
>deleted when the
>application is deleted. Therefore this date would be left on the device
>until a user performed a hard reset. The premise here, is that if every
>application did this, there would be a bunch of garbage on
>your device that
>you could not delete. Unless Hard Resetting.
Wait a minute...
Are you referring to storing the date in feature memory, or as a
"stay open" file stream? Either way, there are very simple ways to
implement cleanup using the Palm API's. Heck, I've seen a number of
apps that do this, and when I browse using ZarfCatalog after deleting
them, I don't see anything suspiciously left over. I think they usually
either use a feature that they free on the eval end date, and block their
app from running using some flag in the application header...or they open
a fileModeLeaveOpen mode file stream and close it when the evaluation
period ends. (They can also use the self deletion code posted by
someone not too long ago in the archives)
Using the application database, it should be deleted when the app is
deleted from the launcher or Z'Catalog or somesuch. But quite obviously,
using the preferences date isn't a very reliable solution. Very easy
to work around. It's better to use a "number of runs" (which is
sometimes not a good idea with Palm apps...especially with ones that
are often started, exited, then started again) or by offering more
features and perhaps conduits with a full version. (aka, as you said,
crippleware)
-Rus
-Rus
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
