Oh, I also fixed the FAQ on Safari, so if you Mac users have been dying to read the FAQ all these years, now you can. Of course, you probably figured out the answer to your question by now.
]]>We'll get Feeds back to 100% in the next week or so. Please be patient with us!
]]>Mike Chambers and I wrote MXNA five years ago, thinking we would aggregate a few dozen popular blogs. 100 at the most. We initially put it on our own server which we expensed every month. When we outgrew that, we moved it to a single Macromedia server which Mike and I managed entirely ourselves. That worked out well for a couple of years until we outgrew it, as well. By that time, we were Adobe — a much larger company with more infrastructure — so moving it over to the cluster was a fairly involved task.
But we didn't just spread MXNA across a few more servers. As we began approaching 2,000 feeds, it became clear that the same code that managed 100 feeds wasn't doing such a good job managing 1,800. So I finally set aside a day, installed CF8, imported the production database, and with some pointers from Ben Forta (I'd never even used CF8 before — I've been focusing on AIR for the last two years), started optimizing.
I spent most of my time rewriting queries, and working on reducing the number of queries per request. The most dramatic change I made was optimizing the search query which went from about 30 seconds to one or two. Be sure to give it a try.
Again, sorry not just for the recent downtime, but for all the intermittent downtime over the last year or so. Hopefully we're past all that, and MXNA (AXNA?) will become a valuable community resource again.
]]>Newsbrew still stores feed and post data, but rather than retrieving and parsing the feeds myself (a surprisingly complex and error-prone process), Newsbrew now uses Google's REST feed API. All data, regardless of the underlying syndication format, is returned in a nice normalized JSON format.
With just a few hours of work, I was able to make Newsbrew much more robust, and because I no longer have code for parsing nine different formats of RSS and Atom, Newsbrew is much less error prone, and the code base is simpler.
I also added Ajaxian to the blogroll at the request of Dion Almaer. If you know of any other sites I should add, let me know.
]]>After Google launched the Google App Engine, I decided to take a little break from Flex and AIR and rewrite Newsbrew in Python to get a good feel for the GAE experience. You can see the current beta version here.
Overall, I was very pleased GAE. It took me about five days to write this version of Newsbrew, but that included learning Python, Django, and everything about GAE. The application is fairly comprehensive, consisting of a user interface, aggregation service, and a secure administrator section. Unfortunately, I didn't get to all the features and bug fixes that I wanted, but the app still seems to work reasonably well.
It's still going to be a little while before we're writing real-world production apps on GAE as it still has several rough patches, bugs, and missing functionality. But it's very clear where Google is going with this, and there's no doubt that GAE is a very powerful concept and platform. I'm certainly going to keep my eye on GAE, and use it as much as I can.
]]>I created a screencast of Maptacular 2.0 which you can watch here. If you want to install the app, just click on the badge below. If you want to see the source, it's all available on Google Code.
Maptacular is a good example of the following:
It's one of the most useful applications I've written so far, and probably the most popular within Adobe. It lets you view your Exchange calendar, and it notifies you of upcoming meetings. It also works offline, so you can view your calendar and get meeting details while you're between internet connections.
Lineup uses all the following open source ActionScript 3 libraries:
The complete source code for Lineup itself is also available on Google Code, or you can simply click on the badge below to install it.
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:
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.
]]>All the source code for apprise is available here on Google Code. You can install Apprise by clicking on the badge below.
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.
AIR isn't just another Adobe product. It isn't just a new tool or utility. It's an entirely new way to develop, deploy, install, and use desktop applications. Entirely new. I really can't stress this point enough. In the world of software, new products are launched all the time (if you don't believe me, just follow TechCrunch for a few days — it's staggering), each with a marketing team that wants you to believe that their technology is nothing less than revolutionary. So when something completely different does come along, it's sometimes hard to distinguish. How successful AIR will be and how quickly the technology is adopted is an entirely different topic, but there is absolutely no doubt that it's new and disruptive. I could easily write an entire white paper on the importance of AIR, but for the sake of brevity, I'll focus on three main points:
I've been in the software business for 10 years, and I've worked on all kinds of projects. I've been fortunate that I've never had to work on a project that I didn't like or believe in. But I believe AIR is the most important project I've ever had the good fortunate to be involved with. I can't wait to see what the world does with it.
]]>So a couple of weeks ago when I heard that the Linux version of AIR was ready for testing, I dropped everything I was working on and set up Ubuntu, Flex Builder on Linux, and installed AIR. I keep all of my AIR application code on Google Code, so I installed SVN, checked out the latest versions of all my projects, and started running my AIR applications completely unchanged on Linux.
I use a MacBook Pro for development now, and I have Windows XP and Ubuntu virtual machines set up. I now have complete development environments including Flex Builder, AIR, and SVN on all three virtual machines, and all of my apps run across all three different operating systems (with the exception of some apps which use features we haven't implemented yet on Linux — it's still in pre-beta).
It's amazing enough that I'm writing desktop applications using web technologies like Flex, ActionScript, JavaScript, and HTML, but to be able to deploy them with no changes across Mac, Linux, and Windows is seriously revolutionary. The idea that I can actually go back to using Linux day to day, and still be able to do AIR and Flex development is very liberating. And now wherever there are gaps in Linux applications, I can just build them myself in AIR (like Lineup, an Exchange calendaring client that will enable me to view my meeting schedule on Mac and Linux as easily as on Windows).
As I said, the Linux version of AIR still needs more work, and is currently in pre-beta. If you're a Linux user, and you're interested in getting your hands on early builds and helping us do some testing, check out this post by James Ward to find out how to get involved.
]]>First of all, it's possible to have transparent HTML in AIR. I don't just mean changing the alpha of the HTML Flex component. That's one way to do it, but that's not terribly useful. I'm talking about entirely knocking out the background of an HTMLLoader (formerly know as the HTMLControl) so that you can do very cool things like custom HTML chrome. I like it because I often use the HTMLLoader to render large amounts of text in AIR, like "help" or "about" pages, so making the background transparent can let me do some cool effects and presentations.
There are three things you need to know about making HTML transparent in AIR:
paintsDefaultBackground property of the HTMLLoader to false. This specifies whether the background of the HTML document is opaque or not. If you're using the Flex HTML component, you can do this using the paintsDefaultBackground attribute on the HTML MXML tag.background-color to anything will prevent this from working.backgroundAlpha property is set to 0 (this is the one I always forget). Also, don't mess with the opaqueBackground property.Ok, now that I have saved cumulative years of searching and trial and error, I expect that time to be reinvested into building even more cool AIR apps!
]]>This typically isn't an issue because you usually don't need to see your application icons during development. However, there are times when you do. For instance, if your application uses a dynamic dock icon, it's nice to be able to see the "before" icon before seeing the "after" version. I've also found that it's nice to be able to try an icon out for a while during the development process to see how you like it over time which means it should appear every time you debug or launch your app.
Fortunately, I've found an easy way to make this work. Here's what you do:
[Embed(source="assets/application.png")] public var appIconClass:Class;var appIcon:Bitmap = new appIconClass();InteractiveIcon(NativeApplication.nativeApplication.icon).bitmaps = [appIcon];This code is a little oversimplified because it doesn't take platform differences into account. A more complete implementation might do something like this:
NativeApplication.supportsDockIcon and NativeApplication.supportsSystemTrayIcon APIs.Since I usually use the Cairngorm framework, I like to create an UpdateIconsCommand which takes care of creating and setting dynamic icons for me. I also like using the as3notificationlib project to help encapsulate some of the platform differences in setting icons.
For a real world example of setting dynamic icons, see my Exchange calendaring application called Lineup (currently being updated to work with Exchange 2007). It sets icons at runtime and even dynamically generates custom icons, all in a way that works well across platforms.
]]>