|
Socoder -> On Topic -> Design woes |
|
| Fri, 02 Jan 2015, 14:55 | |
Afr0
|
By now I've implemented the auto updater for Project Dollhouse twice. The second time I got it almost right, except I over thunk things when it came to updating the patcher itself. Here's my revised design. Does it look ok? Update process 1. Updater checks its filename. If it ends with "NEW.extension", the executable is renamed, as well as shortcut on desktop. Updater grabs a manifest using HTTP. 2. If the updater’s version doesn’t match the one in the manifest: 3. Updater checks its list of files against the list of the files in the manifest to figure out which ones changed, and which ones were added. 4. Updater downloads the changed and added files. All files are saved as "filename NEW.extension". Then the updater changes the shortcut on the desktop to point to the new executable. Updater tells user to restart application before closing down. 5. Assuming updater's version matches the one in the manifest: 6. Updater grabs client's manifest using HTTP. 7. Updater checks client's list of files against the list of the files in the manifest to figure out which ones changed, and which ones were added. 8. Updater starts client and closes. -=-=- Afr0 Games Project Dollhouse on Github - Please fork! 
|
| Fri, 02 Jan 2015, 15:01 | |
|
Afr0
|
Oh yeah, don't ask me why I'd need to update the updater, please. That's not the point of this. The point is - I want to be able to, without using a second executable that can replace the downloaded updater with the new one (which is what I've been doing up until now, and it keeps crashing). -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Fri, 02 Jan 2015, 15:16 | |
rockford
|
I'd first check that the user wishes to check for updates and ensure user is online - some people are still using non-broadband internet and access can be slow or costly. Has the user got HD space for the new patch/update or have they got time to update right now? Don't ever make the check mandatory or stop the user using the software until updated. I also think all updates for any software should list what the (possible) changes/fixes are (and how big the update is) BEFORE the user accepts them - what if they've spent months working on something only for it to become borked as a result of an update that they didn't want, accept or expect? Let's face it, we've all been there! It's really not hard to let a user know first what they are agreeing to, but do softco's ever let the end-user know this info? Rarely or not at all. Will updates be cumulative? ie include anything and everything from all other patches that have come before? If the user is on v1.1 and a new update comes out that fixes issues or adds to patch 1.2 and the user hasn't actually got 1.2 will that cause problems for them immediately or in the future? What if the user has no short-cut on the desktop (and chooses not to have one)? Make it optional. I don't like all my programs having shortcuts on the desktop. It's my desktop, let me decide what I want there. What if the client has moved the files from where they are expected to be? Does your program check the current path and adjust accordingly? Does your program include a recovery option if the update borks the app? Other than that, seems pretty much OK to me 
|
| Sat, 03 Jan 2015, 03:38 | |
|
Afr0
|
This is an MMO. Updates are mandatory. You're right about update information, I should include that. Maybe I could make it pull the latest commit logs from Github? As for the desktop, you actually have a point. Installer doesn't actually give the option of creating a start menu shortcut yet, but it probably should! Thanks! -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sat, 03 Jan 2015, 03:43 | |
|
Afr0
|
As for cumulative updates, Thank the Maker I don't have to worry about them. I tried that the first time around, and it was a pain in the neck. Second time around, I realized that since all updates are mandatory, I don't have to worry about em. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
|
|
| |||
|
| ||||