Related
I've HTML application build with AngularJS/jQuery/Bootstrap with AJAX REST API.
Is it possible to create executable/installer for Windows operating system?
Without any 3rd-party software, it should look like native application, but HTML.
For example, Slack messenger has web/mac/windows versions and they look same.
Any ideas?
// UPD
I probably need a wrapper (webview), but I need all features for EcmaScript5/CSS3.
Electron is the easiest way:
1. Install electron
2. Create and edit main.js:
const electron = require('electron');
const { app, BrowserWindow } = electron;
let mainWindow;
app.on('ready', () => {
mainWindow = new BrowserWindow({
width: 1000,
height: 700
});
mainWindow.setTitle('title of the desktop app');
mainWindow.loadURL('http://www.yourwebpage.com');
mainWindow.on('closed', () => {
mainWindow = null;
});
});
3. Execute desktop app:
electron main.js
And to build the app, use a builder such as electron-builder.
Hope that helps you!
(Full disclosure, I'm the founder of ToDesktop, I'll try to be objective and unbiased here.)
As usual in Computer Science, the answer is "it depends"!
The first question that you should ask yourself is: Who is the desktop app being used by? Just you? Or, are you distributing the app to customers? Because these two segments have very different needs.
Just you
There are a lot of options here (in no particular order):
Nativefier — The obvious option. Lots of configuration options, lots of contributors, open source and regularly updated. This should probably be the default option if you want to whip up an app just for yourself.
WebDGap — This is a lovely project but it is a little old and "as of April 13th, 2018 WebDGap is no longer an active project.". It should also be noted that this is built on an old version of node-webkit and not Electron.
Web2Desk — Great option if you don't want to mess around with the command-line. It uses Nativefier under-the-hood. It is free with a splash screen or $19 with the splash screen removed.
Do-it-yourself with Electron — The basics were covered quite well in this earlier answer. I like this option because it gives you complete flexibility to take the project wherever you like and you'll learn a bit of Electron too.
Fluid App — This is Mac only but otherwise it's a lovely solution and super easy. It's free for the standard version, there is also a $5 version which includes features like fullscreen.
Flotato — Mac only again but this is a really interesting approach. Simply clone the app and give it a name like docs.google.com, it will then turn into Google Docs. At the time of writing this, it's in pre-release (not released yet) but I'll be watching this closely, it's very cool.
ToDesktop — ToDesktop will work but it's probably a bit overkill if you're creating a personal app. Also, it's probably a bit too expensive for this use-case. ToDesktop is targeted at creating a desktop app for distribution to customers (more about that below).
Distributing to customers
There are a few extra considerations which become more important when creating a desktop app for distribution to your customers:
Installer — Mac users expect a "drag to applications" DMG file. Windows users expect an installer and they also expect to be able to uninstall it from the control panel.
Code Signing — If your app isn't code signed then by default Windows Authenticode and Apple Gatekeeper will prevent your desktop app from being opened.
Auto-update — There is still a web browser running "underneath" your desktop app, it's important to keep this updated for two reasons. 1. Security issues + vulnerabilities should be patched over time. 2. You don't want to be stuck supporting an old web browser in 5 years time because your desktop app's browser hasn't been updated
The tools mentioned above don't offer these features, so they're not really suitable for the use-case of distributing your app to customers. These are the features that we wanted to add when building ToDesktop, so I think it fits this use-case quite nicely. We're adding features all the time, last week we added support for App Protocols and Deeplinks.
I myself was looking for an all around solution for awhile. I tried everything from TideSDK, AppJS, Appcelerator Titanium, native code in VB.NET, XCode, Python, C++, Electron, node-webkit, etc: Basically you name it I've tried it.
Note Electron is nice, but it only runs on 64bit processors. So node-webkit is good if you want to run your app on 32bit processors.
So I decided to build my own open source solution called WebDGap.
Currently WebDGap runs on Windows, Linux, Mac OS X, Google Chrome and as a web application!
Watch the How To Video to learn, well how to use the app obviously.
Here's a screenshot.
Being that you're a Mac user already you can merge your exported app into 1 .app mac file. This can be done with Automator (and a little shell scripting).
There's also a coding playground I made for mobile users that has this feature built in called kodeWeave.
Here's a Tic-Tac-Toe game I'm going to export as a Mac App:
Now the web app is running as a native Mac application!
The most easiest and quickest way i know is to use nodejs/npm’s nativefier library which underlying electronjs . It will just take 5 min to create executable for windows. Even a person who do not have programming experience can create desktop application from web application. Below mentioned post has described the steps to convert web application to desktop application. Must read !
Convert any web application to desktop application in 2 min using npm’s nativefier
There are a ton of frameworks out there that can wrap your web app into a native application that can access things like the file storage API for an operating system. This is the specific guide for Windows.
BEWARE THOUGH - you will need to spend time doing solid testing and QA work for your native app so it doesn't feel like a website inside a native wrapper, as well as integrates well with all versions of the OS you want to be compatible with. Tweetdeck for Mac is an example of what not to do - basically a web browser in a native wrapper).
Use Web2Desk: If you are looking for Free and Simple solution.
wherein all you need to do is enter the URL of the web app (or website) and Desktop app for Mac, Windows, and Linux is generated in no time.
With a bit of wrapper code you could package it as a Chrome App. They do not need to run in a browser window but have all the capabilities of a web app, standalone.
https://developer.chrome.com/apps/about_apps
Best Way to Convert Web to Exe is using nativefier:
nativefier --name "Inventory Management System" "http://localhost/php_stock_zip/php_stock_zip/php_stock/" -i ./icon.png -p windows
Steps:
Press Win+x
Press C
Type
nativefier
Installation Requirements
* macOS 10.9+ / Windows / Linux
* Node.js >=6 (4.x may work but is no longer tested, please upgrade)
See optional dependencies for more
Step 5: npm install nativefier -g
Finally type nativefier "Web Link"
Disclaimer: I am relatively unfamiliar with the flash build processes, so some/all of this may be misinformed nonsense. Please feel free to suggest alternative approaches.
We're currently developing a flex web app and our build situation is far from ideal. At present we're (as in individual developers) just building using FlashBuilder and deploying manually. The programmers are currently screaming bloody murder for two reasons, though:
The lack of CI is like going back to the stone age
We don't much care for FlashBuilder
(Note: We're only using FlashBuilder because it was the easiest way to set up a flex project in conjunction with Away3d and get it building / rendering correctly -- it's a stopgap solution).
As a predominately .NET development shop, we're used to doing continuous integration as well as continuous deployment. Ideally, we'd like to get something comparable to this for our flash projects without tying ourselves to a particular IDE.
Requirements:
The build process must be:
.. runnable via the commandline
.. runnable on both developer and CI build machines (and certainly not requiring an IDE!)
.. preferably as IDE-independent as possible (pragmatism will kick in though; if this causes a lot of friction we'll just pick one).
.. able to run on Windows (we develop using Windows)
We don't mind a touch of duplication or a few manual steps (e.g. tarting up the build scripts if we add a new project via an IDE, or generating one configuration from another if tools exist), but the less duplication / maintenance required the better.
I've read quite a few articles / blog posts and watched some short screencasts, but most of them are very thin on the ground on how the build system sits alongside IDEs. Most articles/screencasts have the same formula: How to create a "Hello World" build using a single file & text editors (no IDE).
I've not seen the topic of multiple libraries/projects etc. being broached, either.
After reading around the issue for a while, I'm considering investigating the following options:
Project Sprouts
Flexmojos
Maven Flex Plugin
buildr as3
Does anyone have any experience of the above solutions (or others I'm unaware of) and, if so, what do you make of them? Any help / pointers appreciated.
I recently started building with Gradle and the GradleFx plugin and I immediately fell in love with its power and ease of use.
Gradle is ANT + Maven + Ivy evolved and is primarily used from the command-line. You can:
write scripts in Groovy (a powerful Ruby-like language that runs in the Java Virtual Machine)
access all existing Maven and Ivy repositories as well as your own repos
use existing ANT tasks
integrate with CI (in Jenkins you just tick a checkbox to activate Gradle support)
although it has originally grown from the Java/Groovy community, it is in fact language agnostic. You add language-specific plugins for added functionality. GradleFx is such a plugin that provides you with additional ActionScript/Flex building tasks.
do easy multi-project builds. e.g. you can compile, unit test, package and deploy both your .NET service layer and your Flex client application with just one command.
use convention over configuration: if you stick to the conventions, your build scripts will be extremely terse
generate all kinds of reports: unit testing, checkstyles, codenarc, ...
generate Eclipse, IDEA or other IDE projects
all the things I haven't discovered yet
And best of all: it's very easy to learn. I had no knowledge of Maven before I started with Gradle and could get a multi-project build with some customizations working quite quickly.
Edit (comparison to Buildr AS3 and Maven)
I can compare this only to one of the projects you mentioned: Buildr AS3. It seems to start from a philosophy that is similar to Gradle's. But I've tried to use it about half a year ago and couldn't even get a simple 'Hello World' app to work. I e-mailed the developer for help: no response.
Compared to GradleFx: I had a small forum discussion with the developer (on a rather philosophical topic, since I didn't really need any help because it just worked right away). He answered within minutes.
As for Maven: (for what it's worth) I've only glanced at some configurations and they seem overly complicated when I compare them to a Gradle script.
There is one thing Maven does that you can't do with GradleFx (yet). It can pull the right Flex SDK from a Maven repo and build against that. With GradleFx you have to have your SDK's available locally.
I'm quite familiar with using maven as the main build tool and the flexmojos plugin from Sonatype. My experience has been a bit of a roller coaster with flexmojos. Maven is completely solid, it works all the time without issue, the only issue is the flexmojos plugin which has fluctuated a lot between versions. If you choose to go this route make sure to grab the source for flexmojos so you can see what your configuration options are actually doing to the command line parameters etc. For Flex 3.x flexmojos 3.x up to around 3.9 is good and works fine with regard to the goal for generating the .project eclipse files, believe there's also a mojo (a maven plugin) for generating intelliJ IDEA project files as well as others. If you're using Flex 4 you can compile with the latest flexmojos 4.0RC2 but it appears to me that the goal for generating flex/flashbuilder project properties is now gone (I'm not sure if this is because it's been replaced by another plugin altogether or what the deal is). However building with maven and flexmojos does fulfill all of your goals above (we also use it for building our service layer, so in a single mvn clean install we get a jar packed in a war packed in an ear with everything configured and a swf, that part is really nice). Also you can do continuous integration using bamboo (or simply write your own script that is triggered from a cron job or in windows as a batch file executed with a scheduled task if you don't have a *nix server around). Let me know if you'd like any more details or if I missed something major.
Shaun
I have been using Hudson, now Jenkins, with Ant for Flex automated builds and FlexUnit testing. Jenkins has some really useful plugins for integration with eclipse (and hence, FDT or FlashBuilder), Jira, SVN, Git etc., and it's free. Also, you can integrate the Ant build into Maven scripts, so I've found this to be a good and flexible solution for all purposes I've come across so far.
The Flex SDK comes with Ant tasks, and writing even elaborate Ant build scripts is quite easy - in fact, I'd been using Ant locally before, and I could reuse my existing scripts with only a few added extra compiler options for FlexUnit tasks.
However, it took a while to set up the system correctly for unit testing, because I'm running a headless server on Linux, and that implicates a rather complicated environment for ActionScript tests, because they run only in Flash Player. This, of course, is true for all CI scenarios using FlexUnit, regardless of which server you use.
Here's what I've learned:
FlexUnit needs a standalone debugger version of Flash Player installed, but Adobe only distributes binaries for the standard version on Linux. Therefore, compiling from source was necessary, and since my server system is stripped down to the bare necessities, it took some effort to install all the correct dependencies and get them to work.
The Flash Player needs hardware to run correctly: It uses graphics, therefore it needs a graphics card, and sounds, therefore it needs a sound card. On my headless server, this meant I had to install a VNC host to get it to run at all, and I had to eliminate any tests using sounds (those will now only run on local machines). If anyone ever comes across a working sound card emulation for openSuSE that I could use with the VNC client - you'll be my hero forever!
If you've set asynchronous timeouts in your unit tests, and/or you need to use setTimeout() to send delayed procedure calls, make sure the intervals aren't too short - I've had problems with tests that ran fine on any local machine, but broke the build on the CI server, because the Flash Player is considerably slower on the VNC client than on an actual graphics card.
I've also found this last issue to be a healthy lesson: Criteria for unit tests should not be based on assumptions about the system's performance, or at least be tolerant enough to succeed even on a slow machine.
Is there any API or tool that can automate software updating? It should take care of checking for updates from a URL for a provided list of files and downloading and replacing the ones that need updating. It would also be nice if it contained an authentication module so that only authorized parties could access the updates. It should be language-agnostic - takes a list of files without extra knowledge except their versions and replaces them with newly downloaded copies if on the site there are newer versions.
I'm specifically interested in something for the Windows platform, that would run on Win Xp to Win 7.
This makes me think about apt-get ...
take a look here, as well: Is there an auto-update framework for C++/Win32/MFC (like Sparkle)?
I did see some articles a while back about embedding subversion into your application to manage version control.
Edit:
http://svnbook.red-bean.com/en/1.5/svn.developer.html
Subversion has a modular design: it's implemented as a collection of libraries written in C. Each library has a well-defined purpose and application programming interface (API), and that interface is available not only for Subversion itself to use, but for any software that wishes to embed or otherwise programmatically control Subversion. Additionally, Subversion's API is available not only to other C programs, but also to programs written in higher-level languages such as Python, Perl, Java, and Ruby."
Just saw UpdateNode launching a pretty cool update and messaging system. It seems to be cross platform and free for Open Source.
UPDATE, did some further analysis on that, posted at: https://stackoverflow.com/a/22528011/3257300
For windows, I'd use Google Update, also known as omaha.
Since you didn't tag this question as windows, I'd also mention a UpdateEngine for Mac.
And (best of all) apt, which is available for free on all Debian-based Linux and BSD distributions, like Ubuntu
There is open source project WIPT inspired by APT of Debian Linux.
Head over to Launchpad and use a PPA: it is a Debian/Ubuntu repository management platform. Of course this is not really platform independent but it is language wise :-)
You should take a look at ClickThrough, I don't know much about it but it sounds similar to what you're looking for. As for authorization, I would imagine this to be handled by your webserver based on the URL.
InstallShield has an offering. Never used it but researched it a few years back but we decided on a roll your own solution.
InstallShield Update Manager
InstallShield Update Service
You didn't state what platform you needed this for. The easiest way I can think of doing this is with subversion using rsync.
The concept is to write a post-commit hook for subversion. This script would update a "working folder" on the repository machine and then use rsync to update the differences to another machine.
Data protection and authentication would be set up using rsync over ssh.
If this is for windows, you could try doing the same with cygwin installs on the two machines.
Good luck.
If you use .NET, I'm a happy customer of AppLife Update
CRONw is a scheduled execution service for Windows. (Sorry, I can't link it, I'm apparently limited to 1 as a new user. It's hosted on Sourceforge.)
Powershell is a Windows scripting language (Microsoft-official) that allows you to do most system administration operations you could conceivably want to do. It is very easy to pick up even if you haven't worked with it before.
I would say your best bet is to write a simple update script in Powershell and, optionally, set it up as a crontask so you don't have to manually execute it.
IIRC, Powershell is an optional install on XP, and CRONw requires you be running a 32-bit system. You didn't say, so I'd guess you're doing 32-bit, but the alternative bears mentioning.
And in all this, I'm assuming that the URLs you're describing are designed for this purpose - if they're not and you don't own them, it will rapidly become more suffering than you're willing to bear. (Making a computer navigate a human-readable website usually does.)
Many programs include an auto-updater, where the program occasionally looks online for updates, and then downloads and applies any updates that are found. Program bugs are fixed, supporting files are modified, and things are (usually) made better.
Unfortunately no matter how hard I look, I can't find information on this process anywhere. It seems like the auto-updaters that have been implemented have either been proprietary or not considered important.
It seems fairly easy to implement the system that looks for updates on a network and downloads them if they are available. That part of the auto-updater will change significantly from implementation to implementation. The question is what are the different approaches of applying patches. Just downloading files and replacing old ones with new ones, running a migration script that was downloaded, monkey patching parts of the system, etc.? Concepts are preferred, but examples in Java, C, Python, Ruby, Lisp, etc. would be appreciated.
I think that "language agnostic" is going to be a limiting factor here. Applications come in so many shapes and sizes that there is no one-size-fits-all answer. I have implemented several auto-updaters in several languages, and no two were similar.
The most general philosophy is that the application checks with some home location (web address, web query, corporate network location, etc.) to either ask if it's version is current, or ask what the most current version is. If the answer calls for an update, that process will be different for each situation.
A popular alternative is to invite the home location to run a script when the application is initiated. The script can check the version, download updates if necessary, and ask for usage feedback, for example.
We can probably help better if you narrow the parameters.
UPDATE: The approach to "patching" also depends on the nature of the application, and there's a very wide diversity here. If you have a single executable file, for instance, then it's probably most practical to replace the executable. If your application has many files, you should look for ways to minimize the number of files replaced. If your application is highly customized or parameterized, you should strive to minimize the re-tailoring effort. If your application employs interpreted code (such as an Excel VBA application or MS Access MDB application), then you may be able to replace parts of the code. In a Java application you may only need to replace a JAR file, or even a subset of the JAR contents. You'll also need to have a way to recognize the current client version, and update it appropriately. I could go on and on, but I hope you see my point about diversity. This is one of those many times when the best answer usually starts with "Well, it depends ...!" That's why so many answers include "Please narrow the parameters."
Be sure to also consider the security implications of sucking down information about the update, as well as the update binaries themselves.
Do you trust the source of the download? You maybe phoning home to got your update, but what if there is a man in the middle who redirects to a malicious server. An HTTPS or similar secure connection will help, but double checking the bits that you eventually download by using a digital signature check is recommended.
First you need a file on your application home web site with the latest version.
The best way I think to have special SQL table for this task and populate it automatically after publishing new version / nightly build completion.
Your application creates new thread which requests built-in http link with version and compares in with current. In .NET use can use code like this:
Version GetLatestVersion() {
HttpWebRequestrequest = (HttpWebRequest)WebRequest.Create(new Uri(new Uri(http://example.net), "version.txt));
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
if (request.HaveResponse)
{
StreamReader stream = new StreamReader(response.GetResponseStream(), Encoding.Default);
return new Version(stream.ReadLine());
}
else
{
return null;
}
}
Version latest = GetLatestVersion();
Version current = new Version(Application.ProductVersion);
if (current < latest)
{
// you need an update
}
else
{
// you are up-to-date
}
In this example, version.php in only one plain string like 1.0.1.0.
Another tip I can give - how to download an update.
I like very much next idea: in the resources of your application there is a string of CLR-code which you compile on-the-fly (using CodeDom) to a temporary folder, main application calls it and goes to close. Updater reads arguments, settings or registry and downloads new modules. And calls main application which deletes all temporary files. Done!
(But everything here is about .NET)
The simplest solutions (used by many programs) is running the uninstaller for the previous version and the running the installer for the new one (optionally skipping questions which the user has already answered, like the EULA). The only catch is that the new version must be able to read the configuration options from the old version.
Also, on Windows you can't delete an executable file which is in use, so you probably will want to drop a small executable in Temp folder, which runs the whole process and then delete it at the end from the instance of the new version which got launched (or just register it to be deleted at the next reboot).
Because auto updating is a common scenario, most languages have at least one package available to support this. (Below I list some of the available packages)
One of the really nice idea's is the ClickOnce distribution for .NET, it's an installer which sandboxes your application and installs in the user context, so no administrator rights required. You can configure the ClickOnce in your publish to check for updates each application start.
Java has Java Web Start which offers the same kind of functionality for java applets.
Delphi has numerous articles about auto-updating, Torry has a list of WebUpdate components, for instance GoUpdater seems to have a very wide range of functionality.
They all use a website/network share to check for a new version and than retrieve either a patch or a complete install file and run it. So you should try to find a nice package for your application, to save you the hassle of developing and maintaining your own solution.
The simplest approach would be to have your program query a server (website) to see if there is an update. If there is an update you could display a message to the user that prompts them to download a newer version and provides a link.
An alternative and more complex solution would be to create a small windows service (or unix daemon) that checks periodically to see if there are updates, this service can download the update and launch the installer.
The general architecture is that you have a central server that you control that knows the latest version and where to get it. Then the programs query the server. I am not going to include sample code because it is highly defendant on the server and the format you choose. It is not terrible difficult though.
This is not so much a complete answer, but rather one example of auto-updating mechanism I implemented recently. The situation is a little different from the tradition Firefox-type of user application, since it was an internal tool used at work.
Basically, it's a little script that manages a queue of Subversion branches to be built and packaged in an installer. It reads a little file, where the names of the branches are written, takes the first one, re-writes it at the end of the file, and launches the build process, which involves calling a bunch of scripts. The configuration for each branch to build is written in a .INI file, stored in a Subversion repository along with the tool itself.
Because this tool runs on several computers, I wanted a way to update it automatically on all machines as soon as I made a change either to the tool itself, or to the configuration scripts.
The way I implemented it was simple: when I launch the tool, it becomes an "outer shell". This outer shell does 2 very simple things:
svn update on itself and on the configuration files
launch itself again, this time as the "inner shell", the one that actually handles one configuration (and then exits again).
This very simple update-myself-in-a-loop system has served us very well for a few months now. It's very elegant, because it is self-contained: the auto-updater is the program itself. Because "outer shell" (the auto-updater part) is so simple, it doesn't matter that it does not benefit from the updates as the "inner shell" (which gets executed from the updated source file every time).
One thing that hasn't really been mentioned is that you should seriously consider that the user running your program might not actually have sufficient privileges to upgrade it. This should be pretty common at least for business users, probably less so for home users.
I'm always working with a (self-imposed) limited account for security reasons and it always pisses me off that most auto-updaters simply assume that I'm running as admin and then after downloading just fail and offer no other way of performing the update other than actually closing the program and running it again in an administrative context. Most do not even cache the downloaded update and have to do it all over again.
It'd be much better if the auto-updater would simply prompt for admin credentials when needed and get on with it.
I'm going to assume answer for Windows.
This way seems to work well.
In the installer do:
1. Create a manual-start service that runs as LocalSystem that when started does the update then stops.
2. Change the service permissions so all users can start the service (if all users should be able to update w/o admin rights).
3. Change the main program to check for updates when started using a simple mechanism. If it detects an update, prompt if the user wants to apply it.
4. If user accepts the update, start the service.
If the architecture allows for it, create a way to monitor the update as it is running.
In a Java-Webstart setting you start a JNLP file which then triggers the download of the Jar files needed to run the application. Everytime webstart checks if there are newer versions of the Jars and would download them replacing the locally cached ones. With a tool named jardiff you will create only diffs towards the newer jars and distribute these via the server (e.g. only get an update).
Pros:
always up to date
Cons:
you need an application server (tomcat, JBoss) in order to distribute the files
you need an internet connection in order to get the application
Reading Carl Seleborgs answer gave me some ideas how a generic code-repository could be useful.
svn comes with a tool called svnsync, which sort of behaves like an svn export but keeps track of the actual revision your export is at.
Someone could utilize this system in order to only fetch the changed files from the users actual revision.
In actuality, you will have a repository with the binaries compiled, and running svnsync will only fetch the binaries that has been modified. It might also be able to merge local changes to text-based configuration files with new configuration-options.
The function of installing a patch to a program is basically one of the basic functions of an installer. Installer software is documented in numerous places but usually on a per-installer basis: There the Microsoft Installer (with Install Shield Extensions), Ruby gems, Java .jar files, the various Linux package manager systems (RPM, Apt-get)and others.
These are all complex systems which solve the problem of patching program in general but for slightly different systems. To decide what is best for you, consider which of these system your application most resembles. Rolling your own is fine but looking at these systems is a place to start.
You can write an internal module of your application to do updates. You can write an external mini application to do updates.
Also look at .NET on-the-fly compilation technology, it makes possible to create such mini application on-the-fly on demand. For example, http://fly.sf.net/
You can use my solution (part of the Target Eye project).
http://www.codeproject.com/Articles/310530/Target-Eye-Revealed-part-Target-Eyes-Unique-Auto
If your software is open sourced, and target Linux or developers. It is interesting to install your software as a git repo. And having it pull the stable branch occasionally or everytime when it is launched.
This is particular easy when your application is managed via npm, sbt, mavan, stack, elm-package or alike.
After hours of searching some working solution for this problem I've finally implemented auto update mechanism for python script that works on Linux and Windows.
In short - the script before running actual work checks for update on S3 and if it's available downloads it, unzips, creates or updates the symlink (or junction on Windows) and re-runs the script with already the new version with original arguments.
The full source code and the explanation can be found here.
If you are searching for an cross-platform software update solution, take a look at www.updatenode.com
Some highlights:
free for Open Source projects
cross-platform & Open Source update client tool
localized already for the most important languages
easy to integrate and easy to handle
cloud based management platform to define and manage updates
provides additionally support for displaying messages (inform about new events, products, etc.)
web interface is open (you can create your own client using the service)
many usage statistics, as used operating systems, geo location, version usage, etc.
Android API for mobile App updates
Just try it.
BTW, I am part of the dev team for the open source client. :)
To get an application installed on a new computer there seems to be two major approaches in current use:
Separate installer: Create a separate installer package
that creates all directories, files,
registry entries required by your
application (ie an MSI, InstallSheild etc) and then finally copies your application to the target computer.
Self installer: Include all required
installation steps in a component
that is part of your application. Then use this component to check and create required settings each time the main application executable is run. ie Just run the application to install.
I've used a few applications that corrupt their settings over time, and most had a separate installer. Therefore the only fix was to to re-install, sometimes with settings and even data being lost (very frustrating).
Also during software projects I've worked on, the separate installer approach often dictated spreading application specific knowledge across both the installer package and the actual application. Then, when code/functionality changes were made, both the installer and app needed to be updated. It always felt a bit too brittle and prone to human error.
So I'm currently leaning toward the self installer approach because of a simpler more robust installation/setup, ie just run the app. This self installing approach I feel would also lend itself a more robust application.
Integration with in application settings (options) would also be much more clean, in many cases the same component could perform both installation and settings management.
On the negative, however, performing these extra checks/steps each time the app starts might negatively impact startup times, and OS integration might be a bit more work then using a standard installer.
So which approach to people recommend and why?
(I'm most interested in installation of desktop rich client applications at present.)
There are pros and cons to both approaches:
Having an installer is the proper way to install necessary system components, like drivers, libraries, COM components and so on. Since many of these activities need elevated permissions the install may be performed by the administrator, while the application can be used by all users.
There may actually be requirements for a scriptable installation procedure in corporate environments.
Not having an installer opens the way to portable applications. If the program has everything in a directory, then this can simply be copied to a USB stick and be run on any system. This may of course not make sense for your particular kind of app, but that is for you to decide.
I'm not sure that the issue about corrupted settings is really important here. If settings are corrupted (why?) - how is the application to know what to do about it? OTOH the installer can of course also be written to not blindly overwrite any old settings. It all depends...
Edit: You write in your comment:
Even portable apps require certain configuration/settings, Isn't it better to have the main app check that settings are valid/exist on each startup, and only prompt the user when needed.
and again, it really depends on your needs. There are different types of configuration settings or preferences, and you have to decide individually:
Per-user configuration settings will be missing if the application is run for the first time by the current user. It can be helpful to show a message that it is missing, and how to create it. For example in FlameRobin (a database administration program for Firebird) we have a message that is shown when no registered servers and databases are found on program startup, and how to register them.
Per-user settings for UI behaviour will also be missing, but there are default values for them. The user will get the default behaviour of the application, and can later change things in the option dialog. Since it is best to minimize the number of such settings, and since the defaults should be what most users expect or what works best in the general case, there is also no need to bother the user at program startup.
Some configuration may be not per-user, but per-program. This is generally stored in a location where standard users have no write access, so checking for this and prompt the user to enter it is not really helpful. What could be done is to start an external program, asking the standard user for the account with sufficient privileges and its password.
Going with a separate installer is the "better" way from my point of view. Making an application self-installing does not only add additional workload to the application itself, it also "works around" any installer system of the underlying operating system (like MSI on windows).
And if the application corrupt its settings over time it's broken and need to be fixed. How should corrupt settings be handled by the self-installer? Just overwrite it with the defaults? Users will get annoyed by that too, so having them to run a separate installer and choosing a "repair" option makes this at least more transparent.
I would recommend a separate installer that can do the following:
Install a new installation
Repair an existing installation
Remove an existing installation
The reason I recommend these options is because that is what I have come to expect for installers in Windows environments.
The reasons I recommend separating installation and application logic into two different applications area:
There may be conflicts between dependencies used used by the installer and application.
I want to be sure my team don't inadvertently use classes in the dependencies from the installer framework when developing the application.
Thanks for your feedback. I'm starting to think something along these lines would be a good compromise approach:
Choose the self installer approach by creating an installer component (class library) that is referenced by the main application.
This component is a core part of the application and is responsible for ensuring all configuration/settings exist and are valid.
The main app. executable, on each run, asks this component to check existance/validity of settings, and only prompt the user when required. This could be easily done in a user friendly manner by grouping all setting issues and presenting them in a single GUI (avoids a sequence of annoying dialogues).
For OS integration, the installer component (in the case of Windows) ensures an entry is added to the "Add Remove Programs" list for the application, as well as any other OS required conventions.
Within the application the standard options/settings screen is also provided by the installer component. This avoids duplicating settings management code.
I've asked this question because I've met many non-technical users who ask why they cannot simply copy an application from one computer to another, they can do this with their data (eg photos, documents etc). It's an extremely valid question, in particular for GUI oriented desktop applications.
Separate installers are certainly "the way it's been done" on Windows for many years. For drivers/system components, obviously they are often a necessity. But for desktop GUI style applications I don't believe they are the best in terms of simplicity and realiability for the user/customer.