-
Launching your application on login
NativeApplication.nativeApplication.startAtLogin = true;
That’s all it takes to have your application launch whenever your user logs in to his account on his computer. However, if this is something that you set automatically without telling the user about it, you may find your application to be uninstalled faster than it was installed. There really is no reason why you should set this automatically. You can also set this on runtime. So why not ask the user if he wants to launch your application on login when he first launches the app? And why not provide a small preferences panel that allows the user to easily change this setting?
-
Always in front
NativeWindow.alwaysInFront = true;
Again, very easy to do and in some cases it totally makes sense to have an application stay on top but it should be the user’s decision and not yours.
-
Automatically setting the filetype
NativeApplication.nativeApplication.setAsDefaultApplication("mp3");Imagine you’re building an application that can play MP3 files. Are you sure you want to automatically open your application whenever the user clicks on an MP3 file? This is also one of those things you may want to check first and we provide all the methods to do so.
When you first launch your application, you can first check if your application is already set as the default for this filetype.NativeApplication.nativeApplication.isSetAsDefaultApplication("mp3");If it’s not, check which application is the default for the filetype you want to use.
NativeApplication.nativeApplication.getDefaultApplication("mp3");This returns the path to the application registered as the default app for this filetype. You can then ask the user something like: “Hey I see you play MP3-files with QuickTime but I can also play these files. Can I set myself as the default application?”.
Since you already added a prefs panel for setting the launch on login and always in front preferences, you can also add this one. To remove your application as the default for a specific filetype, just call:
NativeApplication.nativeApplication.removeAsDefaultApplication("mp3"); -
Full screen applications
I think there are only a couple of valid use cases for full screen applications (not the fullscreen displaystate but just taking over the entire screen with the exception of the menu bar). The obvious ones are video and kiosk applications. If your application fits in this category or you think taking over the entire screen is totally acceptable for your app, please do make sure that you add close and minimize buttons. If quitting your application is the only way to quickly check an email, the user may never return to your app.
-
Custom chrome
This is actually related to #4. If you are making an application that has custom chrome, you should always add the standard close, minimize and maximize buttons. Everyone is used to having these in an application window so make sure you don’t forget to add them. These are the methods to call whenever one of these buttons gets clicked.
NativeWindow.close(); NativeWindow.minimize(); NativeWindow.maximize();
You should also be aware that because of the way custom chrome is rendered on a user’s machine, an application with custom chrome can take a performance hit.
-
Self signed applications
What is “Joe The Plumber” going to do when he sees 2 red icons in the installation screen of the app he’s trying to install? As a rule, no AIR application should be publicly launched without being signed with a code signing certificate. We are aware of the fact that individuals can’t get these certificates anywhere right now and this is something that we are working on. Individuals can get a code signing certificate from Chosen Security. However, for companies, it’s really easy to get a cert.
I hope these “rules” will help you build better applications. I’m sure some of you can think of other rules developers should think about, so feel free to add them to the comments if you know of any.
Nice post and you’re sooo right. But shouldn’t it be called “worst practises”?
Well… No… I want to show what the best practices would be (like adding a preferences panel or asking the user first if this is something he wants to do). I’m not saying you shouldn’t use them, you should just think about them
Hi again, good post! I had no idea about nº3!
As for custom chrome, any chance on getting rid of the grey frame in windows?
http://www.enproceso.es/tutoriales/air/grey_frame/grey_frame_2.swf
I guess setting the window size as big as the current screen wouldn’t be a ‘performance acceptable’ solution, because drag & drop becomes really croppy on big screens.
thanks!
I hope there will be an other way to sign your application. Buying a cert for a free application for a period of 3 years sounds pretty stupid and “not done” for developers…
How about the second “error”, red label? Seems like nobody should ever go beyond this warning…
I’m sure 1-4 will become less prone to abuse just as soon as someone comes up with an ‘Application Settings’ framework, much like the auto-updater framework. Now, if only I (or anyone else) could get around to making one of those…
#1 – autostart? Hmmm you mean like Adobe Media Player? I agree – very annoying.
For number 5 (Custom Chrome) too many beginners also forget the StartMove()
private function init():void
{
// Add an event listener to feed to the startMove function
mainPanel.addEventListener(MouseEvent.MOUSE_DOWN, startMove )
}
…
private function startMove(event:MouseEvent):void
{
stage.nativeWindow.startMove();
}
Without this, the custom chrome apps cannot be dragged around the screen. Add this as #7 most annoying feature.
I am just glad nobody build an AS3 class for blinking text.
;-)
Well… The Adobe Media Player has a preferences panel where you can easily change this behavior. I also think, it’s not the default setting…
Good point on the StartMove thing!
All the points you stated are true. What is interesting is that Adobe itself doesn’t push for this, for example by adding examples and docs in their SDK. Maybe this will come later?
One thing I think custom chrome settings miss is the ability to add a system default shadow. I know this would be hard to add, but it is hard to get something that works on all platforms, or create one for every OS out there.
The grey boarder problem on window shows up as a box on OSX when you use expose and mouse over the window. Issue with the runtime not knowing the window boundaries so it refers to it as a square.
I totally agree with @Duane about point #1 and the Adobe Media Player.
To reinforce the point, I have REPEATEDLY uninstalled AMP for this reason exactly (and because of all the irrelevant “pop culture” garbage it tries to shove down my throat). Every time I install a CS4 product, AMP gets installed, and every time it does, I uninstall it.
Actually these are not AIR features that annoy users, these are common features that annoy users.
@fb – You are absolutely right… but this blog is about Flash, Flex and AIR ;-)
thanks serge for such a beautiful post.
hi Very basic but good points to be remembered.
Paying $500 to get rid of the two red installation signs isn’t really an option for starting developers, freelancers etc like myself… Can you really expect developers to buy such an expensive certificate when they have created a free-to-use AIR application ?
@Jeroen; It’s just $199 for a year with Chosen Security and in that year, you can sign as many apps as needed.
I expect my application to stay alive a bit longer than 1 year.
But still: I can’t release a free AIR application without paying $200-$500 or have the users get big-red crosses during installation. Luckily my target audience are Flash/Flex developers so I’m hoping they will understand what the crosses are about.
And thanks for the 6 tips: I’m currently creating the ’stay on top’ OPTION :)
Hi,
what about this?
var type:String = NotificationType.CRITICAL;
stage.nativeWindow.notifyUser(type);
I think it’s important too.
Cheers
Christian