« February 2008 | Main | April 2008 »
March 26, 2008
Tips on getting a code signing certificate
I got my own certificate for signing AIR applications a couple of weeks ago, so I thought I'd share my experience in order to help others more easily navigate the process. My intention is not to provide an exhaustive tutorial on code signing or the process of obtaining a certificate (if that's what you're looking for, see Todd Prekaski's article entitled Digitally Signing Adobe AIR Applications). Rather, I just want to list a few things you should know about before starting the process in order to ensure that it goes smoothly.
I decided to get my certificate from Thawte, but you can also use VeriSign (and soon other Certificate Authorities who Adobe is working with). Both Thawte and VeriSign issue code-signing certificates to organizations as opposed to individuals, so the tips below assume that you already have a corporate entity established. We are currently working with CAs who can issue personal certificates, so if you don't have a business, you will soon be able to get a certificate issued in your own name.
If you decide to get your certificate through Thawte, here are some important things to know:
- Use Firefox. Firefox has a certificate manager that allows you to easily export your certificate as a P12 file which is what you need in order to sign your applications. Yes, it's sort of a strange requirement, but it makes the process much easier.
- Use an email address other than Gmail, Hotmail, or Yahoo. Thawte will not issue a certificate to anyone using an address from a free email service. I tried to talk them into it (I love Gmail), but they wouldn't budge. I ended up having to use my Watch Report email address which they eventually accepted, however they would have rather I used an email address associated with the company's domain.
- Set up a corporate web page. My main business is Watch Report, but my company is called Cantrell Media Company. Since Watch Report is well established, I never bothered setting up a separate corporate web site. Thawte wanted one, so I threw together christiancantrell.com in about five minutes. It's not pretty, but it met the requirement.
- Get a business phone number, and list it publicly. I work out of my home, so I have a business line (I almost always use my mobile phone, but it's nice to have a landline to fall back on). However, when I got the second line, I didn't bother to create a corporate account with Verizon. Rather, I have both my home and business lines listed under my personal name. Thawte doesn't like this. They either want to see a phone bill with your business number and business name on it (which I couldn't produce), or they want to see your business and your business number listed in a public directory. I listed Cantrell Media Company on yellowpages.com which took a few days, but is completely free. Thawte was happy with that. (Here's the listing.)
Those are all the specific issues that caused me problems. If you own a business, and take all four points above into account when applying for your code-signing certificate, you should be able to obtain one within a couple of days with no problem at all.
Posted by cantrell at 10:48 AM. Link | Comments (4) | References
March 13, 2008
Apprise: an RSS aggregator written for AIR
I did a screencast of the RSS aggregator called Apprise that I wrote for AIR. Click here to watch it. I didn't put any effort into designing the app, so it looks pretty plain, but it's very functional.
All the source code for apprise is available here on Google Code. You can install Apprise by clicking on the badge below.
Note: A new version of Apprise is available here.Posted by cantrell at 07:06 AM. Link | Comments (8) | References
March 11, 2008
Detecting network connections in AIR
One of the biggest benefits of AIR is that applications can be written to easily function whether online or off. Features like file access and a local SQL database give developers the functionality they need to write applications that can pull data from remote data sources while connected, but can also rely on cached data while disconnected. Of course, writing an application that functions seamlessly both online and offline requires that you be able to reliably detect whether you have a connection or not. This article will tell you everything you need to know to reliably determine not only if your application is connected or not, but also whether it can reach the services it requires.
Let me start by saying that this isn't as simple and straightforward as it might sound. In fact, in today's world of VPNs and 3G wireless networks and virtual network interfaces, it's actually pretty complicated. We didn't realize how complicated it was until early on in AIR 1.0 development when the engineer who was responsible for the online/offline functionality in the runtime gave me a build to test. I started writing an application that needed to know whether it was connected or not, and the first time I yanked my network cable out, we were surprised to find that it didn't work as expected. The cable was disconnected, my AirPort card was turned off, but for some reason, my computer (and the AIR runtime) thought it was still connected. After some investigation, we realized that the problem was a couple of virtual network interfaces that Parallels set up in order to be able to manage networking between OS X and Windows.
What ensued was an almost philosophical discussion about what it meant to be online and offline. Theoretically, my application might have been trying to talk to a service on my Windows virtual machine which would have meant that my computer actually was connected even though I pulled my cord out. Or I might have had an internet connection, but the server my application needed to talk to might only be accessible while connected to a VPN. Or I might be on a public network that blocks certain services, packets, or ports that my application relies on in order to access data. Or you might be sitting in an underground concrete bunker with no connection to the outside world whatsoever, but you're developing an application the retrieves data from a server running on your local computer which means, from the application's point of view, it's online.
We eventually arrived at the conclusion that there really is no such thing as online or offline, or at least no simple and practical definition that worked for AIR developers, and that meant there was no way we were going to get away with a simple online/offline API (the first version of this API allowed for the simple registration of online and offline events on the static NativeApplication instance). In fact, we realized that it doesn't even matter if you're online or not which meant we were trying to answer the wrong question. All that matters is whether you can successfully access a particular service. And to figure that out, we were going to have to deliver a couple different APIs, and probably some best practices around using them.
The two APIs we decided to deliver with the runtime are the networkChangeEvent, and the ServiceMonitor class. You register for networkChangeEvents on the NativeApplication static instance. Each time a networkChangeEvent is thrown, you know that network connectivity has somehow changed, but you don't know how it's changed. For instance, the user might have connected, disconnected, logged into a VPN, joined a wireless network, etc. That's where the ServiceMonitor class comes in. Since we determined that there really is no absolute concept of online or offline, you can use the ServiceMonitor class to tell you something which is much more interesting: whether or not you can actually reach a specific service.
The ServiceMonitor class has two subclasses: SocketMonitor and URLMonitor. The SocketMonitor is for monitoring services that you connect to directly with a TCP socket like a mail or an XMPP server. The URLMonitor class is for monitoring HTTP services like REST based services. Both can be configured to listen for networkChangeEvents for you, or they can can be activated manually by calling the checkService method. Both also have various ways to configure them to work with your specific service. The service event thrown by the ServiceMonitor has a code property which indicates whether or not communication with the service was successful.
This is a pretty complete solution, but there's still one more scenario that we haven't accounted for. Let's say the end user plugs in a network cable which causes the networkChangeEvent to fire which, in turn, causes the ServiceMonitor to check the state of the service. And let's say the service responds favorably which causes the ServiceMonitor to throw its status event with a code property of "service.available". Your application responds by showing a big green light indicating to the end user that all is well, and that it's safe to submit data to or pull live data from your remote service.
The problem is that the service might go down between the time you last checked it and the time your application needs to interact with it. Or your ISP might have suddenly gone out of business. Or an underwater transatlantic cable could have been cut. Any number of things could prevent your application from successfully talking to its services. The ServiceMonitor can't help you now, so it's up to you to catch the IOErrorEvents and handle them gracefully. Since I typically use the Cairngorm Flex framework, I have a single boolean property in my ModelLocator called online which any part of my code can access. I set the online property inside of my ServiceMonitor event handlers and also within my IOErrorEvent handlers, as well (and I also set it to true every time I successfully interact with a service). That way, whether the end user has no connectivity or the service the application is trying to access is down, the application behaves consistently and appropriately.
Of course, having a robust solution to reliably determining whether you're online or not is only half the challenge since your application also has to know how to behave in both circumstances. Writing a complete online/offline application is beyond the scope of this article, but I will say that hinging application logic on the ModelLocator's online property is the key. If you want a detailed real-world example, I recommend taking a look at Lineup, my Exchange calendaring application. It works both online and off, and demonstrates all the principles described in this article.
Posted by cantrell at 10:12 AM. Link | Comments (1) | References