Auto-update of native application bundles
zonski at gmail.com
Sat Jul 21 17:10:44 PDT 2012
*Apologies for the previous, half-written email - I have a new keyboard and
bumped some magic button. Here is the full version:*
For those that are interested, I have put together an alternate version of
the Auto Updating proposal.
The installer can be found at:
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 (ugly) bar, just to highlight the difference in
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
Source code for everything can be found at:
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
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 plug in to their application (e.g. there should
be something like a CheckForUpdatesAction you can hook into your menus or
button). This should cover the 80% use case. The framework should then
allow the developer to hook into it and fully customise the experience
however they like.
So my two main questions are:
1. what would you consider the perfect auto-updating user experience?
2. what ways would you likely want to customise this experience for more
Things to consider:
- How should the user be notified of new updates and then start the
check for updates process (e.g. on start up, from a menu, from a status
bar, from a status bar tooltip bubble)?
- Would you like to see the auto-update be done in a dialog or some
other mechanism (such as a panel you then embed somewhere)?
- What information would you like to see about a current release and
available upgrade? Visually do you have any thoughts on how this should be
- What pages/steps should the auto-update wizard take the user through,
what should be on each step, and how should this look visually (screen
mockups would be awesome, but general comments are good too)?
And of course anything else you want to comment on would be welcome.
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 download (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 - your app
may be more or less).
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. If your app is small or released infrequently then this is
probably acceptable. I'd be very interested to hear people's opinion on
this one - once we head down one road (and we are already heading down it)
then it will get very hard to change direction.
*Implementation notes *
To add AU to the Ensemble app, I cheated and just used Ensemble as a third
party jar, instantiated the UI and added it to my own Scene, with the Auto
Updating status bar added to the bottom. Ideally this should be better
integrated in the long run.
You can see the code for this here:
The actual AU framework code can be found here:
This time I have used ANT as the build tool instead of Maven, since most
people seem to be using this, although I have used normal/plain ANT
scripts, not the weird Netbeans specific ones that Netbeans seems to create.
- This is still a windows only implementation (but technically should be
easy to port to the others since Igor's done the hard work with his
packagers - if any Mac or Linux developers want to volunteer I would be
more than happy to talk you through what's needed - probably not a lot of
work involved just some simple Objective C or C++ coding).
- In general, the implementation could be used in your own app if you
really wanted to (though I would highly recommend fixing up the User
Experience) - with one major limitation: I currently hard-code the name of
the 'exe' for the Ensemble launcher in the C++ code. This needs to be
dynamic and I have been talking to Igor about ways that I could work out
what this 'exe' is called from within my C++ code.
- Since Igor's native installer does not yet install to 'program files',
I've not bothered dealing nicely with Windows' UAC in this one. There is
no code for it in this repository but it could be easily added.
- As before the code is intended as a rapid, throw-away POC only, the
final version will likely look considerably different at a code level
(e.g. better structured, more robust, more complete). Don't get too hung up
on the structure of the code at this stage, just focus on the general
high-level approach of the solution.
> 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
>> Any and all feedback on all the above will be useful for determining a
More information about the openjfx-dev