Brilliant!!! It sounds like your motivators are similar to mine for andappstore (we need something, it's not there, this should do the job :)).
I've integrated the code into the AndAppStore system and put some information up at; http://andappstore.com/AndroidPhoneApplications/veecheck.jsp If you can cast your eye over the a generated document (there's one at http://andappstore.com/AndroidPhoneApplications/updates/4!veecheck <view-source:http://andappstore.com/AndroidPhoneApplications/updates/4%21veecheck>) and give me a thumbs up if it looks good I would be grateful. Many thanks again for your help. Al. tomgibara wrote: > 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 >> > > > -- 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 -~----------~----~----~----~------~----~------~--~---
