Yes, that's exactly what it's designed to accommodate - you can publish a list of versions and instruct the application differently depending on the version, say directing them to a different web page.
Veecheck is open-source, small, simple, fairly well documented and based on the stable SDK 1.0 APIs; if I ceased to maintain it, I don't think that would cause anyone any distress! It could be that, in the near future, some 'blessed' standard arises for this sort of functionality in which case it would probably make sense to switch to that. What app-store providers need to consider is that they will generally not have exclusivity on the apps they distribute. This means that update notifications will (for the time being) fall to the individual applications, hence the stated focus of the library. This situation will probably persist until there is system service (or some other such component) built into the platform that applications can delegate to for this task. I think its obvious in principle how such a service could work, and if I thought I had a good chance of having it introduced into the platform, I would write one. Tom. On Oct 3, 11:17 am, Al Sutton <[EMAIL PROTECTED]> wrote: > Tom, > > My initial approach is to keep everything server side, so I would be > looking to create a veecheck version document for each app based on the > information in the andappstore database and leave the update checking to > the various applications. If I get the time I am looking to add an > andappstore android app which will check the phones settings (e.g. will > the phone allow install s from non-marketplace sources, etc.) and then > redirect the user to the andappstore website. From what you've said this > andappstore app (if it gets written) could include the veecheck update > check functionality for all of the apps downloaded from andappstore, > which is something I like the sound of :). > > From what you've said about the action, I'm wondering if it would be > possible to direct the user to a web page based on their version?, What > I'm looking at is a kind of combination of the first and second snippets > of your sample versions documents which would allow andappstore to serve > an XML document which contains a versionName and the application URL > which veecheck could use to check the current version and direct the > user to the page if necessary, something like; > > <versions xmlns="http://www.tomgibara.com/android/veecheck/SCHEMA.1";> > <version versionName="1.0.0" > > <intent > action="android.intent.action.VIEW" > data="http://www.example.com/upgrade"; type="text/html"/> > </version> > </versions> > > Is this something that veecheck supports and will continue to support? > (I know I might be being a bit dim, but I wanted to make sure that the > combination isn't something that's among the undocumented features and > may not be supported going forward :)). > > Thanks again for your help, > > Al. > > > > Tom Gibara wrote: > > Al, > > > Broadly speaking, it seems sensible that you could host one such a > > file per application under a URL that included the app_id (though the > > application package name forms a natural id which is probably easier > > to deal with on the client - advantageously the veecheck library also > > has direct provision for this). Inside that file, actions for various > > versions of the application could be specified. > > > What I'm not clear on is whether your app-store application is > > performing the checking (in which case the code needs some changes) or > > whether the individual applications are doing the checking (in which > > case many may not like the GPL very much!). > > > On the subject of the action, that's just a way of communicating > > information back to the mobile app. that is performing the checking, > > it could in principle be anything. I chose an 'intent pattern' to > > encapsulate the data since I felt that resonated with the idea that > > the applications will need to perform some action in response to > > version changes, and that breaking down the information in that way > > would be convenient for developers. > > > FWIW, when I finally release some applications for the phone I'm > > assuming that I will probably just use "android.intent.action.VIEW" > > with a webpage to instruct users about new releases. An app-store > > application could of course use an action that directed them to an > > activity in that application to directly manage the upgrade. > > > Tom. > > > 2008/10/3 Al Sutton <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> > > > Hi Tom, > > > Thanks for the info. Basically what I'm looking at is dynamically > > generating a file from a url such as /version/[app_id]!veecheck which > > would generate the first XML snippet you have in your sample versions > > documents section; > > > <versions xmlns="http://www.tomgibara.com/android/veecheck/SCHEMA.1";> > > <version versionName="1.0.0" > > > <intent action="com.example.app.ACTION_UPGRADE" /> > > </version> > > </versions> > > > As I understand it I would only need to populate the versionName > > attribute of the version tag and replace the com.example.app with the > > relevant package/app name (any pointers on what to call this would > > be good). > > > Have I understood things correctly? > > > Al. > > > tomgibara wrote: > > > Hi Al, > > > > At present the library draws the current version info from the > > current > > > context (ie. the application running) - presumably this would need > > > to be variable for an app-store application; the library was > > > consciously designed in a solo-application-centric way, not with an > > > app-store in mind. Having said that, the library does have untested > > > (and thus undocumented) features that allow the http URL from which > > > the versions document is retrieved to be varied according to the > > > application being checked. > > > > In short, it's probably not a million miles from something that > > could > > > be useful for an app-store app. > > > > Tom. > > > > On Oct 3, 8:05 am, Al Sutton <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > >> Tom, > > > >> I've just put together an app store webapp and I'd like to talk > > to you > > >> about generating update information from the app store which your > > >> library could use. > > > >> Is that something you'd be interested in? > > > >> Al. > > > >> tomgibara wrote: > > > >>> In preparation for releasing apps when Android powered > > handsets become > > >>> publicly available later this month, and since no-one can be > > sure what > > >>> provisions will be in place now, or in the future, for > > updating apps > > >>> via the Google Android Application Market, I've (somewhat hastily) > > >>> produced a small Java library that can be used in Android apps to > > >>> perform the task of periodically polling for the availability of > > >>> application updates. > > > >>>http://www.tomgibara.com/android/veecheck/ > > > >>> Veecheck provides base classes that can be used for periodically > > >>> retrieving a "versions" document over HTTP, and based on that, > > >>> generating a notification to the user that a new version of the > > >>> application is available. > > > >>> It's broadly configurable and may well be useful to other > > application > > >>> developers so I have released it under GPL-v2.0 licence. > > > >>> If you have any question, reply here or feel free to email me > > >>> directly. > > > >>> Tom Gibara. > > > >> -- > > >> Al Sutton > > > >> W:www.alsutton.com<http://www.alsutton.com> > > >> B: alsutton.wordpress.com <http://alsutton.wordpress.com> > > >> T: twitter.com/alsutton <http://twitter.com/alsutton> > > > -- > > Al Sutton > > > W:www.alsutton.com<http://www.alsutton.com> > > B: alsutton.wordpress.com <http://alsutton.wordpress.com> > > T: twitter.com/alsutton <http://twitter.com/alsutton> > > -- > Al Sutton > > W:www.alsutton.com > B: alsutton.wordpress.com > T: twitter.com/alsutton --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
