Will look at it ASAP

It's a madhouse here though!

I agree with the webservice thing, that could be really handy. But don't make it a full blown standards etc thing, just a simple POST to an url with the XML data, which returns another XML. (To keep it simple on the server side, not all platforms and such provide such easy ways to implement full webservices as .NET)

& and such should work as well, btw (I for one always forget exactly what the CDATA syntax was, but I never forget & ;))

Did  you  add  user-agent  too?

Ok, first, this is what happened in more detail:

1. Download CAB to PC
2. Copy CAB to device
3. Install CAB
4. Run AppToDate (again, please move the shortcut to the Programs submenu)
5. Without clicking anything, i.e., this runs automatically if I start AppToDate:
"Checking for 1 Update"
6. "An update is available for AppToDate that must be installed before you can continue!"
7. Click "OK"
8. Automatic download and install of new AppToDate version. GOTO 4.

Device is unbranded original HTC TyTN II, regional settings set to Netherlands/Dutch, but device language is English.

Sounds good to me!

EDIT: BTW, where do I place the icon and what do I call it? Same as XML but .ico ?
EDIT #2: NVM, found it

Another request, does AppToDate use a specific User-Agent string? Didn't think of this before but we have direct link protection on our files that needs to be circumvented by AppToDate.

AppToDate itself

I'm getting an infinite install loop. Installed the CAB, ran the program, it downloads and installs a new version. Start that, and it downloads and installs a new version. Etc

EDIT: Also, please put the link in Start Menu\Programs, not Start Menu itself !

Yes I do agree the files are tiny, but I know users and somebody will complain about that extra directory he doesn't use sooner or later ;)

As for the uninstallation, I have noticed the following:
- You install your CAB
- CAB creates file in non-existant directory (so directory is created)
- You put another file in that directory
- Uninstall CAB
- CAB uninstall cannot remove directory it created
- Unsuccesful uninstall or "uncomplete" uninstall

This has happened to me a couple of times and I was scratching my head as to what the problem was. I do not know if this is WM version specific or if I might just have messed up those CABs (forgot to set a flag somewhere?), it's at least something that should be tested.



This certainly looks easy, but you end up with a number of XML files on the server side to keep it working for 'old version' or 'special version' users. IMHO it's always nicer to have stuff like this in a single file. Less chance of developer error ;) But of course this is a personal preference.



This is exactly why I posted this example:


The version the user wants to update to is not always the same version as they have installed, as the version they want to update to may be dependant on other things on the device, that may change over time. VGA / QVGA is a bad example.

To explain the above example further:

Imagine an application or hack that enhances QuickMenu even further. We call it "QuickMenu enhancer".

Now imagine you update QuickMenu from version 1.3 to version 2.0.

You were running "QuickMenu enhancer 1.0 for QuickMenu 1.x". This is however not the version type you want to update to. The version you want to update to is "QuickMenu enhancer 2.0 for QuickMenu 2.x".

Oh well

Paul,

First off, let me say, great initiative, this could be big if done correctly. Similar efforts in other areas (as in, not for WM/PPC) have been started many times and most of them have ultimately failed (though of course there are some success stories). I truely hope AppToDate will be different.

Now, on to the good stuff.

File location
If I understand correctly, files have to put in that folder whether AppToDate is installed or not. People who do not use AppToDate will probably frown upon this (I know I would). Not to mention it could cause trouble with uninstallation of CABs.

I would personally suggest, indeed, a registry key:
[HKLM\Software\AppToDate\MyApp] REG_SZ [path to xml file]

This is the easiest solution I can see to the problem, aside from AppToDate actually scanning folders to find AppToDate.xml

Ofcourse, any solution forcing a setup DLL usage would be a definite no, as these often prevent installation to complete when no valid (and know to the device) code signing certificate is used on both DLL and CAB on application locked phones.

Version and notification
You mention version and notification options in the XML for use with for example non-free upgrades. To make this work right IMHO you need to have version specifiers in the XML so it knows from which version to which version is free and non-free.

Also possibly a way to select which version you want to install? For example, software may have different version for VGA and QVGA.

---

Here is an example XML showing the above features, with comments.

Installed XML:



Server XML:



Note that ofcourse the XML you actually install only needs the data for that version, not the other ones. AppToDate should therefor use intelligent XML comparison.

I know somebody is going to read the above and think "well, why not make automatic selection on cab[note] ?". That is because ofcourse QVGA/VGA can be detectable, but "QuickMenu enhancer" could have something silly like "QuickMenu 1.3 compatible" versus "QuickMenu 2.0 compatible". You cannot assume because a user has a certain type installed, they will always want this type.

I'm sure you get the idea. It's up to you to see what to do with it

oh, and on a final note: the xml should have an AppToDate XML revision in it, for future compatibility.

It may work for you but changing just those settings is not enough for a lot of devices, and configs needs to be changed to use WiFi differently. This is totally not to bash schaps tool btw, I love that too, it's just a lot different in the functionality it provides. And yeah ofcourse you can do all those things manually, but that's not very handy now is it. But hey to each their own - it's nothing to me if you prefer to use schaps for it. NB WMWifiRouter has been working on my device for almost three months.

Yeah too bad that doesn't work

It's still a 'beta' product... May need some tinkering to get to work. Try running WMWifiRouter again and using "Crash Cleanup" option to fix internet sharing again. Don't know where this uninstall issue comes from though, more people have seen it. Just uninstall the program through your control panel, remove the item from the programs list, then remove the files manually if you have that problem.



Somebody has gotten it to work on Vox, but it's still a bit tricky. Working on it.



You can connect as many devices as you wish.



1 - This seems to depend on phone. My phone disconnects the sharing when a call comes in. Others say the caller gets voicemail.
2 - As fast as your data plan allows.



.NET CF is not used or required.



Which one would that be?

XDA is back up - that was a very short 3 hour maintenance So you can continue reading there. As for WPA, on some phones this option is also available for Ad-Hoc networks, but that obviously does not work.

If you get the big green icon your phone is ready for business. I have noticed myself that the signal strength is not that good sometimes, and Windows often fails to detect it. You can try restarting WMWifiRouter. Also make sure to search for it on your PC, refresh the list a couple of times, move the device around, etc.

Also, note the network name: it says Connect to <network>. This <network> _should_ be WMWifiRouter, else you need to configure your phone to only connect to Ad-Hoc in your WiFi setup.

- Do you have an Ad-Hoc network configured? (installer with network settings does this for you)
- Make sure you are not using WPA
- ICS should be \Windows\IntShrui.exe , doubt dutty moved that. Besides, if there was no ICS in that location, you wouldn't get this far

Just call them, I'm sure they'll clear things up. And yes, there WILL be a recording of that phone call (for various reasons - but you can be damn sure recordings of all calls are kept at least a couple of weeks). The question is if they will admit it!

You put the EXE on the phone, not on the PC.

If you read the thread @ xda a few tweaks come from there. In reality, a few tweaks come from that, a few come from people fiddling @ xda, others come from google

AFAIK what you say is correct, it is a speed rating and should not be relevant. All SDHC capable readers and writers and cards should work together perfectly, independant of the class. Which means that if there is a problem there, HTC probably pulled a fast one somewhere. Besides, what sense would it make if the card REQUIRED 4mb/s to be read or written? Aside from copy operations, I doubt most applications will reach that speed (GPRS download anyone?).

Either way, I've had the suspect 6gb SanDisk in my TyTN II for almost two weeks of relatively heavy use (can't ... stop ... fiddling - and coding, that too) without any problems whatsoever. I've filled it up and I've emptied it, both several times (now sticking to a nice 50-50% setup). All is still well.