Auto-update of native application bundles

Mon Jul 23 06:55:06 PDT 2012

Dan,

>  What do people think about this, what do we need to make things "safe" and if we do add security and jar signing should this be mandatory or optional?

I think I need to understand the process better to really give this a proper response.  Specifically what is the C++ code in the AU framework used for?  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?

>  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(), displayUpdateLink()).

>  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 'accept'? 

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?

>  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.

thanks
jose

________________________________
 From: Daniel Zwolenski <zonski at gmail.com>
To: Jose Martinez <jmartine_1026 at yahoo.com> 
Cc: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net> 
Sent: Sunday, July 22, 2012 5:09 AM
Subject: Re: Auto-update of native application bundles

Thanks Jose for you feedback - much appreciated. 

One topic I forgot to mention in the previous email - currently there is no signing and validation of the download. It assumes the URL you reference for AU is trustworthy and if you download something from that you are getting what you asked for and therefore it's ok to run that code. I tend to feel this is ok but I am generally on the relaxed end in this area. My logic is there's no guarantee the original install was not a hack/nasty, so why complicate the later downloads by trying to guarantee they are from the same source. 

What do people think about this, what do we need to make things "safe" and if we do add security and jar signing should this be mandatory or optional? I, for one, would prefer not to complicate my build for an app that is only going to be installed/used on an intranet and VPN and therefore is probably safe enough without signing.  

Right from the main title screen they would see that an upgrade is available and given the option to upgrade now.  This mimics some of my favorite apps.

Can you elaborate on what you mean by the 'main title screen'? I'm guessing you are saying that a popup should be shown on startup if an upgrade is available but please let me know if I misunderstood.  

Release notes.  I am used to how IOS does it, a user can see the list of changes before they upgrade an app.  

Good to know. I left out release notes as I was not sure exactly how people would want to use them. Adding it to the pre-install step makes sense. 

this should cover all releases between current and latest 

A simple solution would be just to link to a webpage and the developer is responsible for maintaining this page. This would allow you to completely style and manage this page as you want (e.g. something like http://www.jetbrains.com/idea/whatsnew/index.html).

Trying to record and derive individual release details and merge them would complicate the build process quite a lot I imagine and in some cases may not make sense. I'd be interested to hear more on how people would use this feature and what would work best for them. 

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 'accept'? 

Extra credit: option to upgrade to an intermediary version.... i do not know how popular this would be, I know for some apps in the past I had to hunt down version in between currently-installed and latest.

Good use case to know about but I'm thinking this would not be part of the default work-flow. It adds complexity to a lot of levels that I'm not sure would be totally worth it. We definitely should make the underlying framework customisable enough however that this could be implemented by the developer. Happy to hear more thoughts on this one, and if the base framework allows for it (which it will) then it could always be added in a later version. 

>   2. what ways would you likely want to customise this experience for more  specialised scenarios?
>
>
>When a user purchases a license for my app they will be allowed to download future updates up to a certain point  So if they have a very old license then they can't upgrade to latest.  Do not know if this is something you want to build into the framework, but it at least must be implementable.  If the user chooses to buy a new license to upgrade, would be cool if they just enter the new license and then they get to upgrade.  So I guess I'm saying license based upgrade would be cool or at least not blocked by the framework.

This is a good point. I definitely think the base framework should/will allow for this to be implemented on top of what comes by default. Thinking about it there is really an enhanced process that is common for most paid-for applications as opposed to your standard freebie or back-office application. Not sure this should be part of the core library, but perhaps - Igor and Richard might have some ideas on this as we get further along. A way for developers to easily licence/charge for their apps may well encourage more developers (as seen by the iOS app store).  

Perhaps though, this payment based AU system would be a nice open source project that extends the base functionality. It could then make use of third party licence, ssl, hashing and payment-gateway libraries to implement some powerful stuff on this. For example, I don't see any technical reason why someone keen couldn't build their own 'pay now' screen as part of the upgrade wizard and hook this into a payment provider (such as PayPal). That would be pretty sweet. 

On a separate topic... how did you implement your details popup?  I notice how it displayed outside of your main window and how it would remain within my desktop's borders.

I just borrowed the old lightbox concept from web land (see http://gettopup.com/)

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.  

I've used these a lot instead of dialogs, they have the advantage that they can be animated in/out and can be any shape, etc. They have the disadvantage that they can't really be application modal if you have multiple top-level windows (i.e. scenes) and I don't know how well they would block keyboard input such as shortcut keys. 

I've thought about open sourcing the code for this (it's very simple) but never gotten round to it. If you are interested let me know. 