Feature requests / Bug fixes etc.

Send us News! | Rules

Please Log In or Register - it's FREE!

You Are Here » MoDaCo » MoDaCo » AppToDate

4 Pages

1 2 3 > »

Feature requests / Bug fixes etc.

Options

Paul (MVP)

Apr 3 2008, 17:21

Post #1

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

--------------------

Paul O'Brien - Microsoft MVP, Mobile Devices, MoDaCo.network Founder. Read my Blog or get your own on MoDaCo!

Free 2.25GB online backup from Mozy... Click here for details!

MACHEIST IS BACK! Click Here to check out the uber-bundle of apps for you Mac! Check out MUPromo bundle too :D

Paul (MVP)

Apr 3 2008, 17:32

Post #2

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

Apr 3 2008, 19:13

Post #3

Did I say that out loud?
Group Icon

Group: News Team
Posts: 4,473
Joined: 20th August 2003
From: Kent, England
Member No.: 13,469

Device(s): Kaiser, Touch

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)

Paul (MVP)

Apr 3 2008, 19:19

Post #4

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

Apr 8 2008, 12:40

Post #5

Newbie

Group: Posters
Posts: 8
Joined: 5th February 2004
Member No.: 31,284

QUOTE(chucky.egg @ Apr 3 2008, 19:13)

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

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:
<caburl>http://www.cameraware.net/apptodate/cameraware.cab</caburl>

Could we have something more like:
<caburl>http://www.cameraware.net/apptodate/cameraware.cab</caburl>
<cabSignedurl>http://www.cameraware.net/apptodate/cameraware.signed.cab</cabSignedurl>
<cabNoTouchurl>http://www.cameraware.net/apptodate/cameraware.wmsp.cab</cabNoTouchurl>

From the AppToDate side, a Windows Mobile Smartphone or WM6 Standard device would detect the platform and present the <cabNoTouchurl> file for preference, falling back to <caburl> if not present in the XML. A WM5 or later Pocket PC/WM6 Classic/Professional device would preferentially choose <cabSignedurl>, and again fall back to <caburl> 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: Apr 8 2008, 12:40

Paul (MVP)

Apr 8 2008, 12:56

Post #6

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

Apr 8 2008, 13:59

Post #7

Newbie

Group: Posters
Posts: 8
Joined: 5th February 2004
Member No.: 31,284

QUOTE(Paul (MVP) @ Apr 8 2008, 12:56)

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:

CODE

<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

CODE

<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:

CODE

<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

Paul (MVP)

Apr 8 2008, 14:08

Post #8

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

Apr 8 2008, 14:23

Post #9

Newbie

Group: Posters
Posts: 8
Joined: 5th February 2004
Member No.: 31,284

QUOTE(Paul (MVP) @ Apr 8 2008, 14:08)

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

Paul (MVP)

Apr 10 2008, 15:47

Post #10

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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:

CODE

<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

Apr 10 2008, 16:18

Post #11

Newbie

Group: Posters
Posts: 8
Joined: 5th February 2004
Member No.: 31,284

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.microsoft.com/en-us/library/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:

CODE

    <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:

CODE

<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: Apr 10 2008, 16:18

Paul (MVP)

Apr 10 2008, 16:53

Post #12

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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:

CODE

<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 platformmin="5.2" platformstring="pocketpc" resolution="640x480">http://www.cameraware.net/apptodate/cameraware.ppc.vga.signed.cab</caburl>
    
    <caburl platformmin="5.2" platformstring="pocketpc" resolution="320x240" default="true">http://www.cameraware.net/apptodate/cameraware.ppc.qvga.signed.cab</caburl>
    
    <caburl platformmin="4" platformstring="pocketpc" resolution="640x480">http://www.cameraware.net/apptodate/cameraware.ppc.vga.signed.cab</caburl>
    
    <caburl platformmin="4" platformstring="pocketpc" resolution="320x240">http://www.cameraware.net/apptodate/cameraware.ppc.qvga.signed.cab</caburl>
    
    <caburl platformmin="5.2" platformstring="smartphone" resolution="*">http://www.cameraware.net/apptodate/cameraware.sp.signed.cab</caburl>
    
    <caburl platformmin="4" platformstring="smartphone" resolution ="*">http://www.cameraware.net/apptodate/cameraware.sp.signed.cab</caburl>
    
    <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

--------------------

Paul (MVP)

Apr 10 2008, 16:55

Post #13

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

Apr 10 2008, 18:41

Post #14

Regular

Group: MoDaCo Ad Free
Posts: 105
Joined: 5th November 2007
From: Warwick, UK
Member No.: 318,879

Device(s): Kaiser

<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

--------------------

Got a MobilePhone and a GPS? Make Money Click Here!

Paul (MVP)

Apr 10 2008, 22:35

Post #15

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

P

--------------------

Shadowfixeruk

Apr 11 2008, 07:55

Post #16

Regular

Group: MoDaCo Ad Free
Posts: 105
Joined: 5th November 2007
From: Warwick, UK
Member No.: 318,879

Device(s): Kaiser

QUOTE(Paul (MVP) @ Apr 10 2008, 23:35)

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

--------------------

Got a MobilePhone and a GPS? Make Money Click Here!

Paul (MVP)

Apr 11 2008, 08:01

Post #17

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

Could work

--------------------

Paul (MVP)

Apr 14 2008, 10:30

Post #18

The Main Man
Group Icon

Group: Admin Team
Posts: 18,831
Joined: 6th November 2002
From: Norwich, UK
Member No.: 1

Device(s): MDA Vario III

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

--------------------