Auto-update of native application bundles

[Daniel Zwolenski]

For those that are interested, I have put together an alternate version of
the Auto Updating proposal.

The installer can be found at:

   - http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate.msi

To make things nicer, this time I have used the "JavaFX Ensemble" app as
the base application. I've added a 'version bar' to the bottom of this and
you can click the check for updates link on this. The newer version that
gets downloaded has a red bar, just to highlight the difference in version.

This implementation differs from the last in two main ways:

   1. It works with the existing native installers that Igor has created
   2. It assumes compile-time deltas will be used instead of runtime
   deltas


*User Experience*

As before, the user experience shown is not the one we want as the final
version. I have improved on the last experience, but I would really like to
do now is get a conversation going on what people see as the ideal
experience.

I believe the framework should provide a 'default' experience that
developers can very easily hook into their application (e.g. there should
be something like a CheckForUpdatesAction you can hook into your menus or
button). This should be the 80%

What information would you like to see about a current release and
available upgrade? Visually



Deltas

Currently only a 'full' upgrade is used, there are no 'deltas' - with one
variation on this theme: if the JRE version has not changed then the JRE
does not need to be included in the upgrade. So your first install (the
'exe') will include all the JARs and the JRE (36MB) but the subsequent
upgrade is a zip containing just the new JARs (8MB for Ensemble).

Igor's thinking (please correct me if I misquote you Igor!) is that this
approach will be the recommended norm and that deltas will be much less
frequently used.


Other Implementation notes

Technical notes:

Since Igor's native installer does not yet



On Wed, Jun 20, 2012 at 11:59 AM, Daniel Zwolenski <zonski at googlemail.com>wrote:

> I've uploaded a new MSI to: http://zenjava.com/demo/update/testapp.msi
>
> This is version 3 and it is blue. If you install and check for updates,
> you will see that version 4 is available for download. If you upgrade you
> will see that it's red. Note the upgrade is now quite quick as they both
> use the same Java version.
>
> This is now all in JavaFX instead of Swing. It is a nicer UI and user
> experience but it is still very raw and would need a lot of work. It should
> give you more of an idea though, and, of course, if anyone wants to look at
> making it nicer please let me know.
>
> *Note: If you have the older version you can auto update to this newer
> version but because the whole point is to demonstrate the new auto-update
> code, you would be better served by uninstalling, downloading the new one,
> installing and then upgrading. *
>
> I'm hoping (perhaps optimistically) for feedback on the two proposed
> approaches from the community regarding "deltas assembled at compile time"
> vs "deltas determined at runtime" (where a 'delta' is the same thing as a
> 'patch'). The floor is open, but if there isn't any feedback in the next
> few days I will focus on just one approach - in the absence of any other
> input it will likely be Igor's "deltas assembled at compile time" approach.
> Speak now or forever hold your peace (or at least apologise later when you
> make me change to another way).
>
> Just to re-cap, here are the main pros/cons of each solution:
>
>    - with *compile-time deltas* we can assemble all the changes into one,
>    easy to deploy file (per delta/OS).
>    - with *runtime deltas* the app has to be uploaded to the server
>    unzipped (i.e. as it would appear on your local system) so the apps can
>    work out diffs on the fly
>
>    - with *compile-time deltas* you have to create and maintain all
>    deltas you want to be available (e.g. v1-to-v2, v2-to-v3 and v1-to-v3). If
>    you don't provide a delta, the system reverts to 'full' update (i.e.
>    downloads everything). Currently this could mean a 50MB download (instead
>    of say a 4MB delta), but Igor has indicated this might be reduced
>    considerably. Deltas also require some extra steps at compile time to
>    define/detect what has changed.
>    - with *runtime deltas* you only maintain/upload the latest code - the
>    apps all work out the delta's on the fly and only download what they need
>    (e.g. the 4MB of jars that have changed). You do not need to create or
>    maintain any deltas. You do need to maintain an 'app-profile' but this
>    could be mostly generated (easily from Maven, I imagine ant could automate
>    it if you used versioned jars).
>
>    - the single file of the *compile-time deltas* make life
>    easier/quicker for signing.
>    - with *runtime deltas* the tool has to sign every jar individually
>    (although tooling would hide this - and signing requirements are not yet
>    fully explored)
>
> There are likely other smaller benefits as well (Igor, did I miss any big
> ones?) but these major ones are what I would be weighing up.
>
> There is another possible usage of *runtime deltas* that I've not brought
> up before because I still can't decide if it is a positive or a negative.
> With this approach the JARs don't have to come from the same URL source, so
> for example you could download the third party JARs (like hibernate,
> spring, etc) directly from centralised servers - and the Maven repos
> provide exactly this already. This would be useful for corporate, intranet
> style apps where they could maintain their own Maven repo, but for public
> apps it might be a little risky? It also opens up lots of questions
> regarding JAR signing, but I personally feel signing is not as necessary in
> all cases as might be the current thinking (but that's probably another
> debate).
>
> Any and all feedback on all the above will be useful for determining a
> solution.
>