My users must download a program from the interwebs to a microSD card, which can be any drive letter from A-Z.
Q: Is there a drop dead simple approach to downloading a file to a specified drive/directory without relying on the user to navigate for me?
I can populate the directory with a seed file if necessary to let my program know the right home.
Example:
FileName: This_is_it.txt (This let's me know this is the right folder).
FileName: Program.prc (this is the program that I need the user to download and place into this folder).
I don't know AIR yet, but I think AIR might be a solution, so that's why I'm putting the AIR tag on this question.
Using AIR requires your users to install its runtime, is it acceptable? Then they must install and run your program. The smoothest install process is so-called badge install, where AIR application runs installer right from the browser. You want "drop dead simple" approach for your users or for you to develop? AIR programming is simple, but not to this degree. And yes, if user gets your AIR app running, it can enumerate drives, check contents, download and write file into any location.
In HTML at least, the simple answer is no.
Related
I have standard instalations of some programs, and althou they are freeware and i can download them and install on any machine, things are not that easy always. When system crash and i dont have working machine or working internet connection or lan card or drivers for lan card i always struggle to find them and make them work if some dependency file is not on that version of windows.
What i need is to know is how can i make applications portable so i can run them from my usb or just copy them from my usb on pc and run, what dependency files application require, and what files and where specific application install?
It's a complicated story but let's try to summarize. Starts from the part "why?"
I'm an obsessive guy who seriously "hates" installers. I love to have a clean system without bloated in files reg entries and DLL's. Thats why I make nearly all (at least 97%) of programs that I use portable. I made more than 600 up to today and what I can say is;
You need:
1- A program to watch file system (what included after installation)
I use this. Simple and straight (sorry not freeware, but you can find tons of alternates)
http://www.samsunsegman.com/um/
2- A program to watch registry (what changed or included after installation)
I use this in HTML mode. Free fast and simple. And portable in nature.
http://sourceforge.net/projects/regshot/
Now scan the system with these 2, and than run the installer. After open the installed program and make your settings as you want. And than use this 2 program to find the added files and registry entries.
For files, delete them to trash can and take them back from trash in batch (easy to do like that) to the folder of application.
Registry, open the related branches in registry, delete any entries containing addressings like (plugins folder = c:\prog.... etc) After right click on main branch and select export. This is your reg settings...
3- Download this program http://ctuser.net/?reg2exe
This will convert your reg file to an exe file.
4- Download this application http://download.cnet.com/FilePacker/3000-2216_4-10414081.html
Note: Click on "Direct Download Link" if not you'll cnet will welcome you with their installer :)
And with this program (I use this because have no interference with any application) pack the program that you want to make portable. In wizard, first choose your reg-exe file after main programs file. Launcher will execute them with this order. And in setting choose "delete after terminate" will delete the extracted files on exit.
You can discover the further details. This helps you to portabilitize nearly 75% of simple applications.
5- For complicated programs or complicated needs you even can make home made loaders like
Before executing the app, put the user files under appdata folder (that I hate)
Put settings in registry (even with dynamically modified "path" addresses)
Choose which to execute (x86 or x64)
Execute in admin mode if needed
Execute the app... And when application is terminated...
Delete the settings from registry
Take the user files from appdata folder and put under programs folder (usb etc) back.
Delete left-over files under the system...
I just wrote these last ones to make you understand how far you can go. And for all these extra tricks, I use just and just bat files. And I convert them to exe also with this software. http://www.f2ko.de/programs.php?lang=en&pid=b2e (also free)
All the softwares that I use except "uninstall manager" are free. And with this technique, amazing but some of programs are running even faster.
Actually you can just use JauntePE or portable apps packer things but... Jaunte and similar sandbox making programs are so slow and not compatible with all. Even causing crashes. Portable apps approach is a bit bloated regarding to my strict spped and size standards. That's why I do it myself about for 10 years (yes even people was not talking about portability)
Note: I'm not a programmer, and you also don't need to be to do these.
I never released my portables, and you also shouldn't (read EULA's) for respect to authors.
But never forget to demand portable version from all authors. Force them to quit installers ;)
Best regards
inovasyon did a great job!
If you want to make some portable app that will work on every computer you move it to, then 99.9% of apps can be made portable.
If you also expect the app to not leave any files, folders or registry entries behind and not change or break things on the host PC's setup, then that limits things a bit further.
Apps requiring admin privileges to write to protected areas of the registry or file system will break when used on PCs with locked-down privileges.
Apps requiring services to be installed on the host PC will often leave them behind.
You must to know there are apps that are locked to specific PCs - Microsoft's recent versions of Office are a great example of this. They simply will not run when moved to another PC.
Also, you'll need some tools for making portable app: cameyo, thinapp, boxedapp, portableapps, spoon, app-v and other.
Portable applications will run from a flash drive, and from the computer.
Good Luck!
Here is a primer for setting up a portable app using the PortableApps.com tools. They have a page for developers that is quite helpful for some specifics, but the overall process is not well summarized. Here is the general outline for creating a portable application:
1. Investigate your application's footprints
Find all the files, registry locations and settings of the application you want to make portable (make use of point (1) and (2) in inovasyon's answer, and maybe take a look at Zsoft). It is usally a good idea to fire-up a virtual machine and track the application's changes without much clutter.
2. The PortableApp generator
Download, extract, and open the PortableApps.com Platform, and follow [The system tray icon] →[Apps] →[Get More Apps] →[By Category] to install the PortableApps.com Launcher, and NSIS (Unicode) needed to Portabilize your app. Alternatively, but with some added hassle, download both the PortableApps.com Launcher and NSIS Portable (Unicode version) as standalones.
You can now compile a project by running the PortableApps.com Launcher and pointing it to your project.
3. PortableApp layout and structure
Download the PortableApp.com Application Template (search for it here) to structure the data and files obtained in (1.) according to the specifications. Also, download some apps from portableapps.com for some practical examples of how they are structured, and to learn more about the struggles of portability (such as the substitution of drive letters in settings files to correspond to the movement of a portable drive).
As a "Hello World" example, try portability this simple program: helloworld.bat, with content:
#echo off
echo Hello World > log.txt
It writes all local environmental variables to the log file log.txt. You can play around a bit by trying to writing files to an %APPDATA% subdirectory and see if you can make your project redirect it to a portable directory.
4. Additional usage
If you need to do some additional coding that is not achievable with the default .ini capabilities (such as forcing only one instance of an app), add a NSIS script with file location App\AppInfo\Launcher\Custom.nsh to your project. Note that PortableApps.com's custom code guide incorrectly states the file location as Other\Source\Custom.nsh. It is also quite unhelpful regarding the layout of this script. Rather look at examples from other Apps and learn the NSIS syntax by Google-ing a bit.
This is my first release on Mac. While we will sell the app on App Store to users and small schools, but on larger schools they don't want to give the students money and ask each one to buy and install the app on App Store. (Have we misunderstood that?)
I'm guessing that it's possible on Mac as it is on Windows etc. to have a network admin system install apps and updates over the network. How does this work, and how do we create a deliverable once the app is finished and working in XCode? Just burn the Archive onto a bootable CD and give to the network admin is enough? Do I need to make compile settings to make the Archive stand-alone?
Bundle any custom frameworks and make sure the Installation Directory for them is a path relative to the executable in the bundle (see Framework Programming Guide)
Archive, Show in Finder, show package contents and navigate to the .app file
Copy it to a CD.
(I'm about to try this, but it should be correct. So if you're hovering on the down arrow, comment first instead. :))
I have tried in vain to install JDK on a flash drive. I have seen many threads on how to do this, but, I do not see one which addresses my issue. I have JDK on my PC already. No matter if I Run from the website or save to the desktop or flash drive itself, when I double click the Java icon to install, I do not have an opportunity to select any installation preferences. It just runs the configuration then tells me the files already exist. Even when I save to the flash and click the icon within my flash folder, it still tries to install on the PC.
Any ideas?
Thanks.
There's a hacky way to do this that I don't recommend, but apart from copying the files directly to flash drive, this is the only solution I can think of. The Java installer is likely detecting your registry key for the one you already have installed. I don't recommend doing this unless you know what you're doing, but deleting the folders in:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit
May have it skip the check and just install it. I recommend you write down what you modified in the registry and make sure that you can re-create it before doing this. If this works as I think it will, the Java installer should not detect the other version of Java on your computer, and you should be able to proceed with installation. I still recommend just copying the appropriate directories to your flash drive instead though, Chris B has the right idea.
Note: This is my first answer. I hope I was able to help you! If not, let me know in the comments so I can do my best to get you to the optimal solution you are looking for! :)
I know on windows there are a bunch of installer tools you can use to create an installer, but on Mac OS I've seen two ways to install apps:
A DMG file which you download, double-click, then run an application inside - the application typically has you drag an icon to another icon (representing the Applications folder) to install the app
Another type of file which launches an apparently standard installer, which sometimes brings up a warning like "This installer may run a program to determine if you can go ahead with the install"
What's the "standard" way of packaging an app for install on Mac OS? Is one of the above the Apple-recommended way?
Thanks.
Apple is very clearly making the "standard" to be downloading a program from the App Store. This has the benefit of making application installation transparent to the normal user. And, believe it or not, normal people have a lot of trouble with the concept of installing a program. Of course that benefit comes with some costs, but this isn't the place for that debate–there are plenty of other places for that.
Assuming you don't want to or can't go the App Store route, both PKG and DMG are common ways to distribute a program. Use a PKG if you need to install files aside from your application bundle (which should not be a common use case). In all other cases use a DMG that prompts the user to copy the application into the Applications folder. But a lot of your users will not understand that they need to do that (unless your target audience is solely knowledgeable computer users). They will run your application from the disk image. Ideally in this case, your program will detect that it is running from a disk image and offer to copy itself into the Applications folder.
Packages works well. If your deployment process must be kept simple, it is great.
The Quick build consists of dragging your .app onto Package and it is done.
For advanced packaging, you can also provide a certificate.
http://s.sudre.free.fr/Software/Packages/about.html
We're discussing two things:
first and most importantly, the standard method by which the bits of an executable get laid on the disk in a way that's accessible and properly registered by the system
second, the mechanism for preparing the .app, as recommended by Apple
An older marketing page on Apple's site says it's recommended to create packages (so the Installer application can move the bits in place) with the PackageMaker application.
Its usage is described here: mactech.com/articles/mactech/Vol.25/25.03/2503MacEnterprise-PackagingforSystemAdministrators/index.html.
But as others have mentioned, the elephant in the room is the MacAppStore(MAS for short). Until it's debut, what was standard for large companies was their own custom scripts rolled into an older-style 'bundle' package or using an executable like the VISE installer. Smaller developers usually tried to make their app installable via drag-drop, distributed in zip archives or disk images(for simplicity's sake).
The MAS is different: as of 10.7 it uses a package format (which debuted in 10.5) referred to as a flat package (really a xar archive, explanation here)
which is transferred over http to a hidden folder, installs directly to Applications(after which the temporary folder it is downloaded to is deleted). It drops its receipt and a bill or materials file into /private/var/db, and is therefore audit-able by the built-in command line pkgutil tool, described here: mactech.com/articles/mactech/Vol.25/25.12/2512MacEnterprise-PackagesReceiptsandSnow/index.html
A benefit of using the flat package format is you can pull things over the network more safely and efficiently, but it isn't as easy to work with as bundle packages if you are testing and modifying the package regularly, or iterating to ensure scripts that perform actions or checks work well. Even when flat, putting the pkg in a archive or disk image is recommended for flexibility. More distribution tools expect DMG's than zip's, so there's that as well.
Besides what Apple recommends and what is standard, common practice, there's this article: https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/ which discusses the why's and hows (although mainly for system administrators) of packaging for wider distribution. It is greatly recommended to get more of a feel of how and why things go wrong, and what to avoid.
Try Iceberg!
Another one package creator.
In OS X, many applications are just created as a Relocatable
application bundles that the user just need to copy to the
/Application folder (or any other location). In other cases, when you
need to perform some operations over the machine (such as adding users
or changing permissions) you can use a PKG installer (for example built using PackageMaker), which allows
executing some pre and post install scripts and support some basic
installation configuration, like selecting the installation drive.
Sometimes, as with complex server software, you need more flexibility, for example to show custom pages to
the end user requesting information required to install your
application, like the MySQL port and password or proxy information to
download requirements on the fly (or simply to make it look fancier
:)). For this cases there are other installer solutions like our BitRock
InstallBuilder (disclaimer, I'm one of the developers).
InstallBuilder also has the advantage of generating multiplatform
installers using the same project with very little customization per
platform.
I have a requirement to create a cross platform application that launches a web link to a feedback form when its uninstalled.
This is obviously normal sort of behaviour on windows..., but on a Mac is is proving to be more complicated as applications are not technically installed and uninstalled in a windows sense, aka you just copy the .app file into Applications and delete it when you're finished.
How can I achieve this website launching requirement? (Should I even be trying, is this process too alien to Mac users?)
I tired packing the application with an uninstall shell script that deletes the app and lunches the site, but obviously the script can't delete itself.
I don't think this is the best idea, since the process would be a bit unusual to OS X users. As you noted, most applications are installed simply by dragging a .app file to /Applications (or some other location). Some apps do have an installer, but even apps with an installer only occasionally have an uninstaller; and furthermore, as a Mac user, I'd be immediately suspicious of an app that installed itself and some sort of unknown shell script.
Mac OS applications should not need to be uninstalled in any way other than the user dragging them into the trash.
Also, I would rethink very carefully your plan to make a cross-platform applications. Cross-platform applications that treat Mac OS as an afterthought and try to push foreign paradigms onto Mac OS are really irritating. If you want a Mac client, keep your backend code, but rewrite the front-end from scratch. Don't use something like Qt, no matter how tempting the portability is.
So, long story short, you're right. The process is alien to Mac users (except for things like plugins). So my suggestion is just to go with the normal Mac OS behavior (drag to trash). Best of luck!
I would recommend against it. You could create an uninstaller but nothing is going to stop a user from just deleting it from the application folder or using something like AppZapper. Most people don't even look for an uninstaller application, they just trash the app, so even if you wrote one there would be no guarantee it'll be used.
I'd certainly avoid an uninstaller shell script, no way in the world I'd personally run it.
An uninstaller on a Mac makes no sense and would be awkward to implement, if you could even implement it at all in a way where people would use it.
Consider trying to get user feedback using alternate methods, such as:
Add a menu item that opens the feedback form
Require registration when the software is downloaded, then send an email to the user at some point in the future to ask for feedback
Ask for feedback occasionally on application quit (could be annoying, though)
I don't think that it's a good idea to ask for a feedback when the app is uninstalled. However, here is a good way to provide an uninstaller for a MACOS app in case it needs to do some clean up.