Auto-update of native application bundles

[Jonathan Giles]

After much talking I'm very pleased to see code is being written. This 
is of the utmost importance in my opinion.

I often tell the story of how impressed I am with other UI toolkits. I 
occassionally see that they need an update, and show a nice looking and 
succinct update interface that does everything painlessly and 
automatically. What blows me away further is that applications that are 
written in this UI toolkit are able to access exactly the same updating 
mechanism for their own application updates. The fact that an 
application developer can painlessly update their application is 
incredibly wonderful, coming from my background of having to write 
custom update preloaders for clients in the past. The complexity in 
these things is rather high - you have to have some form of script to 
contain the update instructions, and be a preloader for the application 
(so you need some way of starting up the application that works on most 
operating systems).

Key words from the above paragraph: 'nice looking', 'succinct update 
interface', 'painlessly', and 'automatically'. I really hope we can pull 
something along these lines of - it would be great!

In short, I am pleased that this is something we are now taking 
seriously, and something that I think end-developers will be pleased 
about to. This should be a simple, painless process that we provide, and 
I look forward to testing it out! Feel free to drag me into any form of 
feedback cycle and or end-user testing.

-- Jonathan

On 16/06/2012 8:31 a.m., Richard Bair wrote:
> Hi,
>
> On my blog[1] I posted an article linking to Igor's blog about application deployment. I went on to describe scenarios where native app bundles do not require auto-update (primarily, when dealing with IT department's distributing MSI files or when using an app store), and conversely those that do require auto-update (just about everything else). I mentioned that I've been talking with Dan Zwolenski (aka Zonski) about Sparkle and auto-update requirements and he's been building a prototype.
>
> There are basically two ways we can take this. The first is that we can try to find some native auto-update system on each of the desktop operating systems, and then build a think Java API that sits on top of these. This approach would allow us to leverage existing code and get some robust auto-update in place much quicker. On mac for instance we would just use Sparkle and it would be rock solid from day one.
>
> I have concerns about this approach. First, the mechanism by which you communicate with the application that it is time to update is likely going to be different for different native auto-update frameworks. Sparkle for example uses "app casting" -- an RSS feed with a URL to the new version. Google's auto-update frameworks probably use some other mechanism. I think it is unacceptable to ask developers to use multiple different deployment mechanisms for telling the app that it is time to update. So that would then suggest we have to have some custom code + Java API + native auto-update frameworks -- now things are getting complicated. Plus, different frameworks have different feature sets, so we either have to use the intersection of APIs supported by all, or we have to modify frameworks with features that are missing.
>
> I don't think it should really be that complicated. I think that essentially doing an auto-update mechanism in nearly all Java (with a minor bit of native code) would reduce the numbers of bugs we have to deal with over all, and would also ensure the same API across all of the desktop operating systems (or embedded systems that don't force the use of an app store). Sparkle is very versatile and yet essentially maintained by one guy, so I think it should be feasible that we could support a similar feature set in Java.
>
> I've asked Dan if he wanted to spearhead this work and he's been enthusiastic about doing so. With that introduction, Dan, the rest is your's :-).
>
> I'm hoping we can put the auto-update mechanism into the lombard repositories (what we're calling 3.0) as soon as they open. In the meantime I know he has a prototype for Windows.
>
> Cheers
> Richard
>
> [1] http://fxexperience.com/2012/06/application-deployment-with-javafx/