How do I add a License Agreement to an AIR application installer? - actionscript-3

I developed an AIR Application, and now i want to add one of those License Text Frames to the install process.
Is this possible?

what i've done is wrap the .air installer inside a native installer. for example, on Mac OS X, you could use the application DMG Canvas (free, $15 donationware), which includes an EULA feature, to create a .dmg for the .air installer. i'm sure a similar approach could be taken for Windows as well.
of course, though, this method isn't ideal for simple AIR cross-platformability, but in my case, and perhaps in yours, i had to package AIR native installers anyway since i was using native processes in my application so adding this extra EULA step wasn't so much of a stretch.

From everything I am seeing, this isn't possible.
http://www.adobe.com/devnet/air/articles/air_badge_install.html
It doesn't look like there is a mechanism to show and have the user accept an end user license agreement at installation. I will dig around some more and update this answer if I find something.
What you could do instead is show the license agreement on the first run of the application and do not allow them to continue if they do not accept. You would also need to store the acceptance so you don't show it again, etc.

Related

Have any way to use MySQL as a installable process in PC?

I'm looking for a way to after install my electron app install also this "local database" but I don't want to use xampp... Have another way ?
MySQL isn't a great choice for this use case -- it's meant to be used in a server environment, not as part of a desktop application. Additionally, distributing it with an application will require you to either distribute your application's source code under the GPL, or pay licensing fees.
A better choice would be SQLite. It's designed for embedding -- in fact, you're probably using an application which embeds it right now! -- and its code is in the public domain, so there are no special licensing requirements. You can use it in an Electron app by installing the sqlite3 Node module.

Is it possible to create a portable UWP app (=no installation needed)

The UWP infrastructure seems to have everything what's needed for a portable model.
Clear separation between os and application
Clear separation between different applications
Less dependencies
Support portable class libraries
As far I know portable scenario's are not supported right now. Is it something that we can expect in the future or is it intrinsic impossible due the architecture of UWP/WinRT
How hard would it be to create some kind of host executable that can run any local UWP app. At the moment I'm looking for portability between different Windows 10 PC's. Not so much cross device or cross OS.
I'm aware you can side load UWP apps, but that's not what I'm looking for.
Is it something that we can expect in the future or is it intrinsic impossible due the architecture of UWP/WinRT
I don't see any major technical limitations that would prevent this scenario. UWP apps can register to some global mechanisms (which is something portable apps shouldn't do), like push notifications or background tasks, but the whole application model has been designed so that users can limit access to those features on a per-application basis. So every developer publishing an app is supposed to have considered beforehand that those code-paths may fail.
But "technically possible" doesn't mean that Microsoft will do it. In fact, I seriously doubt they ever will. The reason is simple: they're pushing the store with all their might, even seeking to put Win32 apps on it. Clearly, they're moving towards putting more apps on the store, not the other way around.
As to know whether it'd be possible to make a third-party standalone runner, I think so. When running unit tests for an UWP app, Visual Studio is launching a sort of "shell" hosting the app (it has become very apparent recently because after an update of Windows 10, the API that allowed to hide the splashscreen wasn't working anymore). I don't know what API is used to create this shell, but I'd definitely dig that way if I wanted to make a portable UWP host.
Although I haven't done this myself (will update answer if and when), reading this article makes it look like there is an easy way to create an installer that calls that command.
In short, an appx package can be installed locally using the command:
C:\Program Files (x86)\Windows Kits\10\bin\x86\WinAppDeployCmd.exe
Which can probably be wrapped in a UI or CMD installer.
Here's nice example of it (not mine).

Building exe and app applications from swf

I am looking for a tool that can help me converting my swf to exe and app. I know that there are several options available. My application will be frequently updated so update feature is essentions for me. Does anybody know a converter that might help me?
Any suggestions are welcome!
p.s. As another option, I can make app and exe out of a loader app that will load main application module every time it is updated.
IMPORTANT (added 22.08.2011)
Guys, thank you very much for your replies, but if you read carefully my question you will probably see that my main concern is about build in update feature inside projector eg. Mac app will be able to check for new version of my app automatically...
create an AIR application with native installers and use air.update and air.update.events for to push updates.
You can use flajector or f-in-box developer's library.
You may already be aware of this, but there is an existing publishing tool you can use inside of Flash Professional.
The publisher is in different menus on different versions of flash (CS4 to CS5) and on different operating systems (Windows vs Mac) so I'll just give you the "hot key"
While inside of flash, press Shift+Alt+F12 and that will bring up some publish options. For an exe file you will want to select Win Projector or the option with .exe. Mac Projector or .app will do the same for mac. Hit publish once your preference is select and viola, that's it!
you really want to use flajector. Cool programm.

Is there an API or tool that can automate software updating?

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

Self installing application or separate installer?

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.