October 26th, 2013

Actually, to be more precise, the meetup will be in Kendall Square Cambridge, on November 30th – pizza & socializing at 6:30, presentation at 7:00.

“Learn how to build large, complex, and native-like mobile apps using HTML, JavaScript, and CSS. In this session you’ll learn modern strategies and architectural patterns to build real-life Hybrid Applications that work and perform like native apps.”

September 18th, 2013

And, in particular, what educational mobile apps are made with Adobe AIR?

At Brightworks one of our specialties is creating educational apps using AIR. AIR takes Flash content and transforms it into mobile apps for Android and iOS. If you’re evaluating cross-platform mobile development platforms, AIR is one of the options that you should consider.

In general, comparing cross-platform technologies is challenging at best. One way to approach this challenge is to look at apps that have been created using each of the technologies that you are considering.

In this blog post we’ll try to maintain a list of URLs for pages that list mobile apps created with AIR. As we’re particularly interested in educational apps we’ll also point out those resources that will help you identify educational apps created with AIR.

But before you look at the lists below, we suggest that you do some research on the Android app section of Google’s Play Store. It’s fairly easy to search the Play Store for AIR apps. Here’s how:

The Play Store allows you to search for apps by their “application ID”.

The app ID for Android apps made with AIR will usually (always?) start with “air.”

The next part of an app ID will usually consist of a “reverse domain name”, e.g. apps made by Brightworks would have an ID starting with “air.com.brightworks.”

Given that this is the case, you can search the Play Store for “air.com.”, “air.org.” and “air.edu.” The “org” and “edu” options will probably yield a higher percentage of educational apps than those you’ll find with “air.com.”

Once you’ve identified apps that you’re interested in exploring you can head over to the Apple app store and see if they’re also listed there. If so, there’s an excellent chance that these apps were written once using AIR, then published to both platforms. You may want to explore specific apps on both platforms and see how similar the two versions are, what their differences are, etc.

We’re guessing that some (many?) of the links below used this very technique to find the apps that they list. In fact, we learned about this technique on the swfhead.com page.

July 29th, 2013

The appeal of cross-platform mobile app development is obvious: It’s much less expensive to write an app once than to write it multiple times. Thus, theoretically, your ROI will be much better if you use a cross-platform development framework such as Adobe AIR, Xamarin, Appcelerator, Sencha Touch, etc. than it will be if you do native development.

But the math isn’t really that simple. Each of these platforms has tradeoffs compared to native development. Before you jump into cross-platform development it’s essential that you thoroughly understand these tradeoffs.

Unfortunately, this is impossible. 🙂

Here’s the problem. In order to understand the tradeoffs for a particular platform you really need to having extensive experience working with the platform. Reading up on the pros and cons for a platform may give you some sense of what its strengths and weaknesses are, but only through practical application, i.e. actually creating a non-trivial application, do you start to get a real sense of the lay of the land. And creating a non-trivial application requires multiple developer-months or developer-years.

So you might think that all you need do is to find an experienced developer who has worked extensively with the platform that you are researching and pick their brain. Unfortunately, this isn’t sufficient. For example, I’m a ‘very experienced’ Adobe AIR developer. I’ve been working exclusively with ActionScript, Flex and AIR for the last seven years, and have about a year of full-time experience working with AIR for mobile. Despite this, I can assure you that there are multiple important types of functionality which AIR for mobile ostensibly offers which I have zero experience in. What are the chances that your app will include such functionality? They’re pretty high.

There’s another problem. You need objective feedback and developers are human, and biased. Personally, I love ActionScript and AIR. I’m quite sure that it’s a superior technology. And yet, vaguely, in the corners of my consciousness, I’m aware that there are other developers who feel precisely the same way about other technologies that I’m not a big fan of. Simply put, you don’t want to rely too strongly on a single developer’s opinion when comparing frameworks.

So, what to do?

One solution might be to find one or more high level managers who have experience managing multiple projects that used various frameworks. Of course, such people are as rare as hens’ teeth. If you have access to such a person, consider yourself very fortunate, and listen closely to their great wisdom. But also be aware that even such exalted experts may not agree with one another… 🙂 which suggests that even they are not always correct.

Another approach is to first do your due diligence – learning as much as you can through online research and picking expert brains – then make a tentative decision. Then, once you’ve done that, invest some developer time in creating a proof-of-concept.

This proof of concept needs to implement a subset of the most important and the most potentially challenging aspects of your app. For example, if a ‘native-like’ UI is important to you, implement examples of the parts of your UI that are most likely to fail to meet this standard. If you want your app to do video streaming, implement a simple example of such functionality.

The proof-of-concept should also implement any ‘uncommon’ features that your app will include. What’s an uncommon feature? It’s any feature that’s difficult or impossible to find implemented in other apps created using your tentative technology choice.

Obviously, such an approach requires that you first thoroughly plan your app so that you know every feature that it will require which is, of course, impossible. Realistically, requirements will always evolve. But if you take this approach and implement it to the best of your ability you will, at least, have minimized your risk. (Elimination of risk in software development isn’t a realistic goal, but that’s another blog post.)

It’s essential that you test your proof-of-concept on many devices. Do you want your app to run on iPhone? iPad? Which generations? iPhone 3? iPhone 5? On Android, the challenge is greater. 🙂 Unless you have a huge budget, you aren’t going to be able to test on all or even most available Android devices. I suggest that you put some thought into this, decide which devices to focus on, and be aware that there’s a good chance that your app will have problems on a few of the many Android devices that you didn’t test.

This is the approach that I suggest. It doesn’t offer any easy or definitive answers – instead, I believe that it’s simply a realistic approach to moving forward while minimizing risk. Do you have other thoughts? I’d love to hear them.

Here are some links that may be helpful in doing your initial research. They don’t provide much depth (for the reasons explained above) but they’ll give you a starting point:

May 3rd, 2011

The imminent release of Flex 4.5 is especially exciting for Flex developers who are interested in developing for mobile. Starting now, we can create applications that will run on Android, iDevices, and Blackberry, with other platforms to follow. Given the fact that about half of all humans currently have a cell phone (3.5 billion, compared to 1.2 billion PCs), and given the fact that Flex is going to offer “write once, then tweak to run on all/most cell brands”, I’m fairly confident that there will be intense demand for Flex mobile skills in the years to come. While at present only a fraction of these 3.7 billion users actually own a Flex-app-capable smart phone, this will be changing rapidly. Today’s top-end phone is 2014’s low-end model.

Join the Boston Flex User Group in Waltham next Tuesday evening to see Christophe Coenraets – one of Adobe’s most dynamic evangelists – discuss Flex, the mobile revolution, and much, much more. 🙂

June 13th, 2010

Last December Mrinal Wadhwa did a great presentation on Custom Components in Flex 4 at the Adobe DevSummits in Chennai and Hyderabad. We were so impressed with the slide deck that he posted that we asked him to present at our Boston Flex Application Incubator group meeting this Tuesday. He’ll be presenting via Acrobat Connect so you can join us from anywhere. Meeting starts at 6:15 PM Eastern Daylight Time.

April 13th, 2010

Brass Monkey is an SDK for creating cross platform experiences. At its core it is a networking library for interconnecting mobile devices and computers over a local WIFI. Brass Monkey allows a mobile device, for example a cell phone, to be used as controller. Input occurs through the device’s accelerometer etc. and is used to control a web based experience (Flash/Flex, Unity3D). Chris will show how to use the SDK, and demonstrate many of the possibilities this new technology opens up to developers.

Chris Allen: Chris is president and CEO of Infrared5. He is also co-project manager and a Java developer for the open source Red5 project, and has been a software architect and developer for major enterprises including Cambridge Technology Partners, Mass General Hospital and Scholastic.

January 11th, 2010

“Daniel Rinehart will discuss his experiences and insights into developing for the 2.0 release of the Adobe AIR player. Daniel is known for his programming and architectural skill and his talk will be dense with worthwhile nuggets.”

I can personally vouch both for Daniel’s expertise and for his ability to clearly communicate technical information. If you’re interested in Adobe’s AIR technology, this meeting is definitely worth attending. For details, see the URL above.

December 1st, 2009

This is probably obvious to many of you, but I just discovered that placing the string ‘*.as, *.mxml’ in the ‘File name patterns’ field of Eclipse’s search dialog results in blazingly-fast code searches.

November 18th, 2009

Lately I’ve been trying to get some sense of when AIR 2.0 might be finding its way onto mobile devices, and when the Flex Mobile Framework (aka Slider) might be available to developers. I’ve talked/emailed with a couple of people from Adobe but I’m not sure who would want to be quoted on what – so I’m not going to quote anyone. Just consider these to be my more-or-less informed best guesses.

This first point I’m fairly sure of: While mobile devices with Flash 10.1 installed should be getting into the public’s hands by July 1, 2010, this won’t include AIR 2.0. So you’ll be able to run Flash applications in your device’s browser, but you won’t be able to install and run any AIR applications. (And, of course, even your browser based content will need to be designed so that it uses a lot less memory and CPU cycles than we’ve become accustomed to having at our disposal when creating Flash content for the desktop. For example, applications created with the current Flex framework won’t run satisfactorily, if at all.)

It’s my impression that AIR 2.0 will be available for development devices some time in “late 2010”. I’ll go out on a limb here and predict that this will happen by October 1st. But be warned – I’m an optimist!

Then – guessing wildly here – it will start to appear on devices in the public’s hands – by January 1, 2011?

And – more guessing – a beta version of Slider will be available to developers around November 1, 2010. With a commercial release by April 1, 2011?

It will be fun to check back in a year or so and see how well these predictions/guesses have fared.

I should also mention that we have another option available to us much sooner – Adobe is publicly saying that the CS5 Flash “export to iPhone” option will be available in a beta by the end of 2009. I won’t predict how well this is going to work, but for simple applications it’s probably worth considering.

If you know something that contradicts what I’m saying here, or even confirms it, I’d love to hear it – please add a comment!