[PaulOBrien]

Downloaded AppToDate? Have some suggestions? Found a bug?

Post your feedback here!

The app is launching very-Beta, so that developers can have input and make sure everything they want is supported

P

[Sponsored Links]

[PaulOBrien]

As mentioned by Mono in the other thread, i'll be adding scroll support to the description box in a future build, together with the option to view it full screen.

Worthy of note is that in the current build the description text is read from the local XML - in the next build this will be read from the online XML (to allow for changelogs etc).

P

[chucky.egg]

A couple of random thoughts:

1. How about an optional "helper" app to silently monitor for updates, without us having to go into AppToDate to discover them

2. An indication of the size of the CAB file, so you can decide whether to attempt it over-the-air (or wait until you've got WiFi perhaps)

[PaulOBrien]

1. Yeah, have already consider this, would be quite cool I think!

2. Good point. I suspect the 'description' area at the bottom might be better as a whole seperate screen, so you can include that sort of info.

P

[Kieren]

chucky.egg, on Apr 3 2008, 19:13, said:

A couple of random thoughts:

1. How about an optional "helper" app to silently monitor for updates, without us having to go into AppToDate to discover them

This should definitely be "off" by default in my opinion, although I do like the idea of a scheduled/automated "check for updates" feature in general.

Quote

Quote

2. An indication of the size of the CAB file, so you can decide whether to attempt it over-the-air (or wait until you've got WiFi perhaps)

2. Good point. I suspect the 'description' area at the bottom might be better as a whole seperate screen, so you can include that sort of info.

I've vote for having the CAB size as a separate element within the XML, rather than incorporating it into the description. That way it can be presented in a standardised format, instead of randomly being remembered or forgotton by a developer./ From a developer perspective, it's oddly easier to "remember" you need to include that info if it has a tag of it's own

For my own suggestions/requests:
3) Separate entries in the XML for digitally signed and unsigned CAB files.
As developers, we want to make sure users get the best experience they can get, which means we digitally sign our CAB files for use with WM5+ devices...but this process renders them incompatible with older devices, so we have to distribute two separate CAB files to support the full range of operating systems (and this doesn't even get into non-touchscreen devices, where there's some preference still to allow for separate CAB files to support non-touchscreen devices).

So where the XML currently states:
http://www.camerawar.../cameraware.cab

Could we have something more like:
http://www.camerawar.../cameraware.cab
http://www.camerawar...ware.signed.cab
http://www.camerawar...raware.wmsp.cab

From the AppToDate side, a Windows Mobile Smartphone or WM6 Standard device would detect the platform and present the file for preference, falling back to if not present in the XML. A WM5 or later Pocket PC/WM6 Classic/Professional device would preferentially choose , and again fall back to if the other isn't present.

This is one of those features I'd consider pretty much critical for AppToDate to do support application delivery the way I prefer it, but I can understand if it's too complex to be considered at the moment

Kieren Smith
Producer, Astraware

This post has been edited by Kieren: 08 April 2008 - 12:40 PM

[PaulOBrien]

Platform detection wouldn't be a problem, but I just assumed you'd have seperate CABs for seperate device types, and therefore seperate XML files? After all, would you ALWAYS update SP and PPC at the same time?

P

[Kieren]

Paul (MVP), on Apr 8 2008, 12:56, said:

Platform detection wouldn't be a problem, but I just assumed you'd have seperate CABs for seperate device types, and therefore seperate XML files? After all, would you ALWAYS update SP and PPC at the same time?

Given the XML doesn't currently include any distinction between platforms and WM5/WM2003 versions, unless you include it in the product name (which feels ugly and kludgy to me), there'd be no distinction between:

<application>
<name>CamerAware</name>
<version>3.08.03.29</version>
<description>CamerAware Safety Camera alerting from MoDaCo</description>
<versionurl>http://www.cameraware.net/apptodate/cameraware.xml</versionurl>
<caburl>http://www.cameraware.net/apptodate/cameraware.cab</caburl>
</application>

And

<application>
<name>CamerAware</name>
<version>3.08.03.30</version>
<description>CamerAware Safety Camera alerting from MoDaCo</description>
<versionurl>http://www.cameraware.net/apptodate/cameraware.xml</versionurl>
<caburl>http://www.cameraware.net/apptodate/cameraware.wmsp.cab</caburl>
</application>

I can see that what I am suggesting still has a problem in that you need to have some way to allow for different files per platform...maybe my example below will illustrate what I'm trying to get at better:

<application>
<name>Bejeweled</name>
<files>
	<platform>touch</platform>
	<version>1.30</version>
	<description>Astraware Bejeweled 2 for Windows Mobile</description>
	<versionurl>http://www.astraware.com/apptodate/bejeweled2.xml</versionurl>
	<caburl>http://www.astraware.com/download/bejeweled2-ppc-v1-20.cab</caburl>
</files>
<files>
	<platform>touchSigned</platform>
	<version>1.30</version>
	<description>Astraware Bejeweled 2 for Windows Mobile</description>
	<versionurl>http://www.astraware.com/apptodate/bejeweled2.xml</versionurl>
	<caburl>http://www.astraware.com/download/bejeweled2-ppc-v1-35-wm5.cab</caburl>
</files>
<files>
	<platform>noTouch</platform>
	<version>1.30</version>
	<description>Astraware Bejeweled 2 for Windows Mobile</description>
	<versionurl>http://www.astraware.com/apptodate/bejeweled2.xml</versionurl>
	<caburl>http://www.astraware.com/download/bejeweled2-wmsp-v1-30.cab</caburl>
</files>
</application>

(don't tag my tagname suggestions as ideal, I've just bodged the format to look a bit like what's desired). AppToDate would look through the options in the XML file for one with the right platform, and compare versionnumbers at that point.

What do you think?
Kieren

[PaulOBrien]

Yeah, that would work if you added the platform logic detection in (which is simple enough), the current solution for your example would be 3 different XML files in the 3 different CAB files, treating them as if they were different applications effectively...

There's no reason I couldn't build this logic in, as an optional thing to use...

P

[Kieren]

Paul (MVP), on Apr 8 2008, 14:08, said:

Yeah, that would work if you added the platform logic detection in (which is simple enough), the current solution for your example would be 3 different XML files in the 3 different CAB files, treating them as if they were different applications effectively...

There's no reason I couldn't build this logic in, as an optional thing to use...

P

For tidiness on our server, and to avoid visits from Mr. Cockup, I'd personally prefer something which was more oriented towards "one XML file per product, covering all platforms", so I'd like that sort of logic built in, but others may have different preferences

[PaulOBrien]

OK, so here's what I am proposing - you can set specific versions and files based on the OS version (4 for WM2003, 5 for WM5 / WM6 etc.) and the Platform Type (POCKETPC or SMARTPHONE). So, your config XML might look like this:

<application>
	<name>CamerAware</name>
	<version>3.08.03.30</version>
	<description>CamerAware Safety Camera alerting from MoDaCo</description>
	<versionurl>http://www.cameraware.net/apptodate/cameraware.xml</versionurl>
	<caburl os="5" platform="pocketpc" default="true">http://www.cameraware.net/apptodate/cameraware.ppc.signed.cab</caburl>
	<caburl os="5" platform="smartphone">http://www.cameraware.net/apptodate/cameraware.sp.signed.cab</caburl>
	<caburl os="4" platform="smartphone">http://www.cameraware.net/apptodate/cameraware.sp.cab</caburl>
</application>

How does that look?

Note that we have a 'default' attribute - this profile will be used when none of the profile specifics match, and is therefore mandatory.

I wonder if we could add screen resolution as another attribute, and make each of the attributes optional, as long as each of the nodes matches. e.g. You could just have platform, or just OS, as long as that was the case across the board. This then makes things like 'resolution' optional too?

P

[Kieren]

This is great, very much matching my needs as well as providing lots of flexibility to all!

I wonder if it would make sense to use the same "names" for the "os" and "platform" parameters as the Windows Mobile .INF file does? That way we keep a sort of synchronicity with them, and an unsure developer can just match them to his CAB file creation paramaters?

That would make:
"platform" > "PlatformString"
Values:
* "PocketPC"
* "Smartphone"

"os" > "PlatformMin" (I'm assuming this would still be "minimum OS version", rather than "specific OS version")
* 2.0 = Pocket PC/Smartphone 2002
* 3.0 = WM2003
* 3.1 = WM2003SE
* 4 = WM5
* 5.2 = WM6

(taken from http://msdn2.microso...y/aa924422.aspx )

Is that too strange/abstract an approach?


I *really* like the idea of having a parameter in there to support resolution specific CABs too - we don't do that ourselves but I've seen that in some developer's software. Do we want to allow the parameter to support multiple values, a range of supported resolutions? Or if a developer wants the same file to support multiple specific resolutions, they just put the line in several times?

For instance, lets say AppAwesome.Square.CAB supports 320x320 and 240x240 only, while AppAwesome.General.CAB supports everything else:

	<caburl default="true">http://www,awesomeness.net/AppAwesome.General.CAB</caburl>
	<caburl resolution="240x240">http://www,awesomeness.net/AppAwesome.Square.CAB</caburl>
	<caburl resolution="320x320">http://www,awesomeness.net/AppAwesome.Square.CAB</caburl>

Or should we instead aim for:

	<caburl default="true">http://www,awesomeness.net/AppAwesome.General.CAB</caburl>
	<caburl resolution="240x240,320x320">http://www,awesomeness.net/AppAwesome.Square.CAB</caburl>

The latter feels like it's more prone to inviting our good friend Mr. Cockup to visit, even thought the former requires more explicit listing for a developer (which is not necessarily a bad thing)

Kieren

This post has been edited by Kieren: 10 April 2008 - 04:18 PM

[PaulOBrien]

platformstring is fine, i'll look into platformmin - i've not used that before, but I can't see it being a problem!

With regards to resolutions, I definitely like the second approach best! The XML is gonna get pretty complex if you're trying to get os versions, device types AND resolutions in there!

So, revised:

<application>
	<name>CamerAware</name>
	<version>3.08.03.30</version>
	<description>CamerAware Safety Camera alerting from MoDaCo</description>
	<versionurl>http://www.cameraware.net/apptodate/cameraware.xml</versionurl>
	<!-- WM6 POCKET PC VGA -->
	<caburl platformmin="5.2" platformstring="pocketpc" resolution="640x480">http://www.cameraware.net/apptodate/cameraware.ppc.vga.signed.cab</caburl>
	<!-- WM6 POCKET PC QVGA -->
	<caburl platformmin="5.2" platformstring="pocketpc" resolution="320x240" default="true">http://www.cameraware.net/apptodate/cameraware.ppc.qvga.signed.cab</caburl>
	<!-- WM5 POCKET PC VGA -->
	<caburl platformmin="4" platformstring="pocketpc" resolution="640x480">http://www.cameraware.net/apptodate/cameraware.ppc.vga.signed.cab</caburl>
	<!-- WM5 POCKET PC QVGA -->
	<caburl platformmin="4" platformstring="pocketpc" resolution="320x240">http://www.cameraware.net/apptodate/cameraware.ppc.qvga.signed.cab</caburl>
	<!-- WM6 SMARTPHONE ALL RESOLUTIONS -->
	<caburl platformmin="5.2" platformstring="smartphone" resolution="*">http://www.cameraware.net/apptodate/cameraware.sp.signed.cab</caburl>
	<!-- WM5 SMARTPHONE ALL RESOLUTIONS -->
	<caburl platformmin="4" platformstring="smartphone" resolution ="*">http://www.cameraware.net/apptodate/cameraware.sp.signed.cab</caburl>
	<!-- PPC 2003 SE ALL RESOLUTIONS -->
	<caburl platformmin="3.1" platformstring="pocketpc" resolution="*">http://www.cameraware.net/apptodate/cameraware.ppc.unsigned.cab</caburl>
</application>

Hmmm, is resolution a step too far? You can see I have included a wildcard in the resolutions here. I guess you want to be able to specific resolutions, but have a fall back too?

P

[PaulOBrien]

I guess you could theoretically allow wildcarding of the other attributes too... feels like it's getting a little over complex

/me thinks about this a bit.

P

[Shadowfixeruk]

<Hands Up for a feature request>
Great App Paul...!

So having worked out where i went wrong when i first installed AppToDate; i noticed earlier today that there is a new build (release?) of CameraAware (another great app BTW ). Cool i thought - i can get AppToDate to download my update!

So i downloaded, started the install, then my machine hung..... no worries - soft reset; back to ATD, re scan & reupdate...

Oh.. i have to download it again.. bummer (no 3G at work )...

So feature request - can you implement a cache? so if the update has been downloaded, but not installed for any reason, you can use the local copy rather than having to download again (probably best to have a "do you want to use the local copy 1st) to stop infinate loops ).....

Cheers

SF

[PaulOBrien]

Good idea, there would need to be some sort of integrity check tho?

P

[Shadowfixeruk]

Paul (MVP), on Apr 10 2008, 23:35, said:

Good idea, there would need to be some sort of integrity check tho?

P

Guess so - however that may be difficult to implement (i dunno) if you are autoupdating loads of applications...
which is why i suggested the "do you want to use the cached version?" question.... that way if you try once, and it doesn't work - use the cache - if that doesn't work - download again....

Cheers
SF

[PaulOBrien]

Could work

P

[PaulOBrien]

So my current (unreleased) AppToDate build knows it's platform, platformstring and resolution, just need to work out the best way to implement that in the XML!

P

[simonster]

Paul,

I was thinking, I'd like to include a little graphic on the About page of HelloTwitFace that says "works with MoDaCo AppToDate" or something...the MoDaCo dude would look cool on a badge! It could form part of an affiliate type program....

...which leads me to...

AppToDate obviously feeds back the stats to you, so why not have it feed back info about the appx.xml files on devices, you could gather this info, take the path to the online XML and build it into an automated software directory webpage. Where you could download the XML file for every app that has AppToDate support. Then when I as an ATD user want an app I just check your directory and download it with ATD. Potentially a zero management catalogue of all apps with support, you could add a set of tags like yes to allow people to opt in / out.

Also, how about the ability to include Beta deployments? i.e. and type tags?

What do you think?

Si

[chucky.egg]

Quote

an automated software directory webpage. Where you could download the XML file for every app that has AppToDate support.

What he said. Very cool.

[Sponsored Links]