Auto-update of native application bundles
zonski at gmail.com
Mon Jul 23 07:46:35 PDT 2012
> Specifically what is the C++ code in the AU framework used for?
The Java part of the AU does all the dialogs and visual display that you
see. It also does the version checking and the downloading and unzipping of
the new update.
The final step however is to copy the new files over the top of the old
ones. This copies your JARs and also the JRE (if there is a new one). Since
your app is running the JARs and the JRE are locked by the running Java
process, so we can't do the overwrite in the Java code. This is where the
C++ code comes in: the last thing the Java does before it kills itself is
to launch a small C++ process that does this final copy of the files.
Additionally on Windows, if you are writing to 'Program Files' you need to
get permission from an ugly Windows thing called the User Access Control
(UAC). This is what pops up the dialog that says "Do you want to allow this
program to make changes?". You can't trigger this through Java code, so the
C++ code is also responsible for this.
Finally, when everything is copied over, the C++ code is then responsible
for re-launching the newly updated application.
The actual code is very simple (it's a single class with only a handful of
lines of real code in it). This is what would need to be ported to linux
and to OSx to make this solution cross platform. C++/ObjectiveC volunteers
wanted (my C++ is lame).
Also, are the compiled time deltas contained into jars that then get merged
> with the currently installed jars? So if I have a jar with 200 files and
> only 50 of them have changed does the framework download the 50 file delta
> jar and some how merge the two jars into a new one?
I think Igor will be best to comment on this one. Igor, how do you see
deltas working in the compile-time version of the solution, do we define
specific JARs to be included or would we use some kind of binary diff and
patch process (I think you mentioned this early on)?
> Can you elaborate on what you mean by the 'main title screen'?
> If you consider a video game the title screen is that screen that appears
> after the game loads where the user has to click on start to begin playing.
> Instead of a popup my original thought was to have the "update available"
> link built right into the title screen. That way the developer can
> visualize this how ever they want... big flashing letters in the middle of
> the screen, or non-discrete small font msg at the bottom corner. So it
> would be part of applications main code that the developer would have to
> tie into the framework (if frameWork.isUpdateAvailable(),
Ok, the framework I'm working on will allow this to be built this way.
> > I'd also be interested to know about Terms & Conditions pages - do
> people need this, should it be shown before the upgrade (seems logical),
> and does there need to be some record of the T&C acceptance legally, or is
> it generally enough that they can;t get past that page without clicking
> This would be good as part of the installation process. Both the initial
> installation and future updates. The user would have to click on a radio
> button saying they read it before the installation wizard continues. I
> imagine this would have to be built into the Inno Setup script (I do not
> know if it has that capability)? Is Inno Setup used for the AU updates?
I believe there is a request to have this added to the native installer
with Igor's name on it.
> Basically, instead of adding the root of the scene directly to the
> Scene, I create a StackPane to wrapper it. When the "popup" is shown it is
> added to the top layer of this stackpane and so covers everything
> underneath. I use a semi-transparent pane to contain the popup and it is
> this semi-transparent pane that greys out the underlying scene and blocks
> mouse input, etc. All pretty basic stuff.
> Do you create a separate Stage for this? I guess where I am stumped is
> that the way I picture JFX apps working is that you have this Stage that
> has a scene that has a root node and everything goes in root. But
> everything that goes in root is within the borders of main window. How has
> your popup left the main window? I imagine you would have to create a new
> window/stage to break free of the borders of the main one? I'm sure I'm
> missing some key piece of information here.
The dialog is fully contained within the scene. If you shrank the
containing window it would clip the dialog. It is styled to look like it is
floating but it is no different to a button or label within the Scene (or
at least the code is no different, if it isn't getting clipped then I would
be very impressed :) ).
More information about the openjfx-dev