Paul,

I think something happened with the forum database - It looks like 15+ posts from yesterday seem to be missing

UPDATE: I just discovered you created a new suggestion section and there they are

Have another idea when we start to "run" ...

1) Is for AppToDate to support a command-line parameter such as:

AppToDate.exe "\storage card\program files\omnisoft\vnotes\vnotes_V1_AppToDate.xml"

And when AppToDate starts, if such a command line is provided, then AppToDate will only check for (and only list) any updates for that particular app.

2) Create a regkey such as HKLM\Software\Modaco\AppToDate\InstallDir="\Storage Card\Program Files\Modaco\AppToDate"

This way, I could add a "Check for Update" menu selection in my app, and if my user selects this option, my app would simply read the above registry value to get the location of apptodate, then run it with the path to my apps' XML file.

You could even take it a step further and have AppToDate support a "Silent" parameter that will cause AppToDate to run with no UI and simply return a result value to my app. This way my app could silently check (on a schedule)and ask AppToDate if there is a new version. If no, then my app doesn't tell the user anything. But if AppToDate says there is, then I could display a "A new version of this program is available - do you wish to download it? and run AppToDate just for my app as mentioned if the user says Yes.

LOL - Thats just the typical me - I'm always coming up with ideas - some even stick to the wall

Another idea could be to add an optional "WEBSERVICEURL" value to the XML file on the device.

And if a value is specified, then AppToDate would first try to call this service (instead of simply downloading the xml file from "versionurl") and supply the device's XML file as the one and only parameter to the webservice.

The returned data from the webservice would simply be an XML file, formatted to the standard format that AppToDate is expecting.

This would allow the webservice to do various/advanced logic operations, like doing the compare version logic, or automatically determine the proper version by reading various misc custom values that were written/added to the device's XML file by the developer's app (after it was installed) - these extra/additional values would be ignored by AppToDate, but they would be passed to the web service by AppToDate so the webservice could use them for various reasons.

Using this method, the developer's app could add a bunch of custom values to the devices' xml file, such as "Device=PocketPC", so the webservice would know to return a download link for the Pocket PC version of the app. This would free-up AppToDate from having to do such complex logic (which may prove very difficult for AppToDate to implement a one-size-fits-all solution to such issues).

This way, if a developer has the resources to provide a webservice to AppToDate, then they can enjoy the advanced benifits this approach offers. And for all the other developers, AppToDate would simply use the existing versionurl method.

My idea was to simply have the MiscPost text/link appear inside the "latest version" entry/box for that product - something like this:

-------------------------------------------------
***** John Cody's Vnotes Pro
***** Version 2.0.13 (you have 2.0.1)
***** [Click here for More info]
[x] Try Our New Product: SmartTIP!
-------------------------------------------------
***** ABC Spell Checker
***** (Your version is up to date)
*****
[x] Click here to Submit a Suggestion
-------------------------------------------------


The "[X]" would be to show/hide the MiscPost from that developer
The "*****" is the area for the icon.

My idea was to just allow one "MISCPOST" entry per installed product from that developer.

Why not just add an option/checkbox alongside each "MiscPost" that the user can choose to hide the misc posts from a particular developer if that developer abuses this feature?

-John

Some values I think would be helpful to add to the XML file:

1) Similiar to what I previously suggested, have a "FREEFROM" value in the server XML file that is the lowest version the currently availible version is a free update to. Then have a "BUYURL" that points to a mobile-friendly payment page if there is a cost to obtain the latest version (i.e. if the user's version is lower then above "minimum free update" version.) This could be a URL to a FairDeal product page

2) A "MOREINFOURL" value to the server xml file that points to a mobile-friendly webpage that the developer maintains for that app. For example, it could be a "What's New" webpage that will list the change history of the app which could help the user determine if they want to install the update or not. And this webpage could easily contain download links for the various CAB revisions, so if a user has version 1.1, but doesn't want to pay for the v2.0, they could still download and install the latest v1.9 bug fix by clicking on it's respective link. This user-selectable version update feature would be kinda difficult to implement in AppToDate.

3) And add a "MISCPOST" and "MISCPOSTURL" values to the server XML file so the developer can display a misc entry in the AppToDate listing to announce something additionally to the current version entry - maybe something like "NEW PRODUCT XYZ" (which the text would be the value of the MISCPOST value), and when the user selects this entry, they will be directed to the MISCPOSTURL mobile-friendly webpage.

I like that idea - no setup.dll needed, very easy to set a registry value in the registry with a single line in the cab.inf, and AppToDate just needs to Enum that key to find all the xml files.

Yes - that will work even for us VB'ers - cool

As an update to my previous post: My suggestion would require the CAB file (of the app being installed) to read that registry value in order to find out where to install the XML file. I know how to setup a CAB file to "set" a value in a registry key, but I don't know off the top of my head how to read a value and have the CAB file install a file into a directory specified by this value.

I think this is easily accomplished using a custom "setup.dll" that the CAB file can run when the app is being installed, but I believe creating a custom setup.dll requires C#/C++, which would preclude me and other VB.NET developers from doing so.

Ideally, a solution that uses a registry key to specify the XML path, and that doesn't preclude VB programmers would be ideal

Hey Paul,

Congrats on this first release!

A small suggestion...

Since internal memory is limited, when AppToDate becomes a huge success, the "\Application Data\AppToDate" directory will be filling with a bunch of XML and icon files. Also, this directory might not exist on future windows mobile devices.

So, my suggestion is instead of having third party apps be hard-wired to store their XML file in that directory, why not have AppToDate specify the proper directory in a registry key (i.e. "HKLM\Software\Modaco\AppToDate" with a value like "XMLFilepath" that would contain the directory of where an newly installing app should place it's XML file.

This way, if something should change in the future (or the user wishes to install AppToDate and all the XML files on their storage card), the app being installed will simply read this value during install and auto-adjust to such changes.

The previous version I tested 6 months ago constantly used 5% of CPU resources and was clearly visible via the lower frame rates when playing TCMP videos vs. when DontForget was unistalled (videos pauses every 2 seconds when dontforget is running)

Does this new version constantly use CPU resources like the older version did?

Great find Paul!

Merry Christmas an a happy year to you too Paul!

Apparently, Navison does offer an API!

http://www.navizon.com/sdk_howitworks.asp

and an SDK for windows mobile:

http://www.navizon.com/fordevelopers.asp

I totally agree! Many cool applications don't need the pinpoint accuracy of GPS to be doable.

Mystery solved...

http://www.googleprivacyconcerns.com/

http://bits.blogs.nytimes.com/2007/11/28/g...s-a-good-guess/

I just posted a request to google - lets see if they respond:

http://groups.google.com/group/Google-Maps...ab547222074827e

This is exactly what your developer contest was all about!

I wonder how they obtained all the info of where each cell tower ID is located?

Works on my t-Mobile Dash WM6, using ATT network - accurate within 1/2 mile.

Hey Paul,

Great job - my friend was wondering if the GPS in the BJII could be used with any app - now I can tell him "Yes"

It actually is because I have found that with my WM6 dash if the "Program Memory" gets less then around 15MB, it will go into an endless loop of reboots - and the only way to fix it is to do a hard reset, which I don't think anyone enjoys

And even when you go through the trouble of moving the GM program folder to the storage card and create a new shortcut, GM still creates and maintains it's 1-2MB cache in main memory.

This version still doesn't fix the annoying problem of installing the app in main memory EVEN when you specified "Storage Card"

Alerts! has a "Restart when dismissed" feature, as well as an Auto-Snooze feature, so you could setup an alarm to repeat every x minutes either manually (by dismissing it to restart the x minute count-down), or automatically using the auto-snooze intervals.

Using the auto-snooze, it can sort of work like the "invisible mode" you describe to automatically snooze at regular repeat intervals. But, the program will appear for 1 minute for each trigger.

It's VERY customizable - so why not install the demo and see if you can configure it to do what you want?