Share your update scenarios, and a request for samples

[Itamar Syn-Hershko]

There has been some discussion on github which made me realize some concepts of NAU are not fully documented anywhere, so the intended usage might not be understood by some. Therefore I decided to go ahead and create several sample to demonstrate different update scenarios. Writing about it would only make sense after I'll have some samples in hand.

The discussion can be viewed here: https://github.com/phillipp/NAppUpdate/commit/0bdbc1d#commitcomment-1385384

In order to get the most out of this process - can you share the scenarios you are using NAU in, and how you made the actual update look to the user? maybe even what were you missing and would like to see in?

Of course, if anyone would want to contribute a full working sample, that will be even greater...

Thanks,

[drewkeller]

Just to provide a summary of the github discussion Itamar linked...

I would like to display the file metadata for some of the files in a
file update task. I had added attributes to FileUpdateTask for file
version, last modified timestamp, and size. Since the 3rd party
developer creates the update window, he can display this information
(if at all) in whatever way he wishes. Perhaps only display some of
this data for some files... say for instance, the main application
file to provide a message like Your version xxxx / Update version xxxx
(released mm/dd/yyyy), which is an extremely common scenario. Or for
say plugin module files. The file sizes can be summed up to provide
the total size of the update (also very common).

As long as the data is available, it can be used however the 3rd party
developer wishes. However, without this data, he is pretty much locked
into only showing the NUMBER of tasks (why show that to the end user;
seems pretty meaningless to me). I suppose the metadata could be added
to the description fields somehow and then parsed back out... but nah,
i'm gonna keep my own branch of NAU before I do that. It only adds
about two lines of code to the NAU code per additional attribute.

(Plus, once we have the file sizes, it would be possible to add the
download progress back in. Also very common.)

It would of course, not make sense to apply these attributes to other
types of tasks, like the registry task. That's not at all what I'm
suggesting. Other tasks have their own special attributes, I'm just
adding special attributes to the file update task.

[Itamar Syn-Hershko]

You left all the important stuff out :)

Since NAU is about tasks, in general, there's no point in adding custom attributes like these to each and every task. Instead, what I suggested was to provide an generic interface tasks can use to update on progress. Update details will be provided by the description field - the user isn't really interested in which files are being updated and what is their version, only in what this update means to him.

I'm interested in hearing more user stories to see if I missed anything, but I'm pretty sure this will cover your scenario, Drew.

[Itamar Syn-Hershko]

Just to let you know that I pushed a major update

Tasks can now report progress, also detailed one. FileUpdateTask was updated to do that - it will also report actual bytes that have been downloaded if it uses the SimpleWebSource

I also added a new sample app to show how to implement progress notifications

Also fixed a thread safety bug. Basically, if you call CheckForUpdates or PrepareUpdates in an async fashion and want to update UI controls from the callback, you will need to call Invoke on them, NAU cannot do that for you.

I'm pretty sure this covers all the possible scenarios, but do let me know if I missed anything.

Cheers