Hot job in Silicon Valley: Flash developer
The best way to measure the impact and relevance of a technology is probably to look at job openings. According to the Wall Street Journal the demand for Flash developers in Silicon Valley has suddenly surged:
With the advent of online social gaming start-ups such as Zynga Game Network Inc. and others—many of which make online games that involve Flash technology—demand for Flash engineers has suddenly surged.
Mochi Media (one of the largest online gaming networks) says it is hard to find good Flash engineers.
To get around the lack of Flash engineers, Mr. Hsu says Mochi Media tries to hire engineers who know programming languages such as Java and then train them to use Flash. “It’s a six-month time investment, but most can pick up Flash very quickly,” he says.
Be sure to read the rest of the article on the WSJ site. Oh… and ehr… Flash on!
On sub-standard apps
Steve Jobs (via TechCrunch): Intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
That’s the first thing I read this morning… I agree with Greg Slepak (CEO of TaoEffect) who wrote:
Crappy developers will make crappy apps regardless of how many layers there are.
That doesn’t mean that all developers using a specific layer will build crappy apps.
Chroma Circuit by Bowlerhat Games is a very good example. Chroma Circuit started out as a Flash based web game. It was one of the first apps that got packaged as an iPhone app using the Packager for iPhone. Apple didn’t seem to mind playing Chroma Circuit on their iDevices as they featured it as a staff pick on iTunes a while ago.
Fickleblox by BlueSkyNorth is another good example. This application started out as a Flash Lite game and is thereby available on a broad range of devices. It was also packaged using the Packager for iPhone and thus available in the app store.
Both applications (and there are dozens like this in the app store today) are fun to play, easy to use and perform well on the iDevice. You can hardly call that sub-standard! You can also hardly say that they hinder the progress of the platform. In fact… I think it is Apple who is now effectively hindering the progress of the iDevice platform. By allowing “intermediate layers” like Flash but also Unity, Titanium, MonoTouch, Corona, … the platform has become more open and appealing to non Obj-C/C/C++ developers. More developers (regardless of which technology they use) on the platform = more applications in the appstore. I wonder how many apps in the appstore today were built using one of these intermediate layers…
I’m with Adobe and all other intermediate layer providers, for that matter!
The Flash community’s thoughts on Flash Catalyst
At Flash On The Beach in Brighton this week my colleague Andrew Shorten talked to a number of Flash designers and developers, asking their thoughts on how Flash Catalyst might impact their workflow for producing rich Internet applications. Here’s the video from those conversations.
Best practices: 6 AIR features that may annoy your users
I get to see and play with a lot of really cool AIR applications (even when they’re still being developed). Every now and then I come across an app that totally ignores any best practices or usability rules. AIR provides developers with a lot of features that could potentially annoy users if not used wisely. I thought it was a good idea to write this article. I’m not saying you shouldn’t use these features, I just want you to think about them before you add them to your application.
-
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.
Feel free to follow me on: 
