Posts tagged "AIR"

Code, Package, and Debug Flex mobile apps with Flash Builder “Burrito”

Two weeks ago, Adobe released a preview version of Flash Builder. Codenamed Flash Builder “Burrito,” it’s available on Adobe Labs as a 60-day trial. This version contains many features and enhancements that let you easily deploy applications to Android phones and tablets. You can use the included version of the Flex SDK to create Flex apps for phones like the Droid 2, Droid X, HTC Evo, etc., or code in pure ActionScript 3, and have total control over the Flash app that you choose to deploy. Using Flash Builder “Burrito,” you can code, package APKs, install your applications over USB, and perform on-device debugging using WiFi.

To get users started with Flash Builder “Burrito,” I wrote a 25-page document that was handed out at the Adobe MAX Device Lab. I’m making it available here as a PDF. It serves as a tutorial and reference to walk you through the creation, deployment, and debugging of Flex mobile applications, and has resources for more advanced topics. This workflow guide includes:

  • Creating a new Mobile Project
  • Importing an Existing Mobile Project
  • Adding Code
  • Building
  • Running and Debugging on the Desktop and on a Device
  • Your First Flex “Hero” App: “Hello, World!”
  • Packaging for Release
  • Installing the Android SDK
  • Appendix:
  • Conditional Compilation
  • Managing SDKs
  • Additional Resources


This document can get you started creating multiscreen Flex and AS3 applications, and will show you how to use Flash Builder “Burrito” to deploy and debug your apps on Android devices.

Download it here: Flash Builder and Flex Workflows for Multiscreen App Development [PDF]
Adobe Flash Builder “Burrito” is available as a 60-day free trial here.

Spell checking in AIR, Flash, and Flex!

If you’ve created an AIR, Flash, or Flex app and dealt with text and user input, you’ve probably looked around for a spell checking solution. There have been some great third-party spell checkers for some time now, with the widest-adopted perhaps being Grant Skinner’s Spelling Plus Library.

Today, however, you can use a spell checking engine called “Squiggly,” released by Adobe and available for free on Adobe Labs! It’s important to note that Squiggly is a preliminary release and is officially unsupported. If you need support or a commercial solution, I recommend checking out Grant Skinner’s SPL.

Squiggly works with AIR, Flex, or pure AS3 apps.
You can see a live demo here.

Using it in your project is quite easy, and requires two things:

  • A compiled dictionary (usa.zwl is included)
  • The AdobeSpelling.swc library

The dictionary: You have two choices. You can either use the English dictionary that ships with Squiggly, or use the DictionaryGenerator.air utility to compile your own from a word list. Note that the spell checking heuristics used to determine alternate words is currently based on English phonological rules…meaning that if you pick a non-English dictionary, the suggestions won’t work. Multi-lingual support is planned for future releases. In either case, take the dictionary.zwl and put it in your application path. For example, in a folder called “assets.”
The library: Place AdobeSpelling.swc in your project’s libs folder, or be sure to append its location to the library path.

You can now call the Squiggly APIs from your application.
If you want to create a spell-checking enabled Halo TextArea or RichText, use the included SpellUI.enableSpelling function, like so:









If you’re not using Flex or you’re designing your own components, you can call the underlying engine by creating a SpellingDictionary and SpellChecker object. To check a given word, for example:



private var _newdict:SpellingDictionary = new SpellingDictionary();
private var sp:SpellChecker= new SpellChecker("en");

private function init():void
{
_newdict.addEventListener(Event.COMPLETE, handleLoadComplete);
var myURL:URLRequest = new URLRequest("assets/usa.zwl");
_newdict.load(myURL);
}
private function handleLoadComplete(evt:Event):void
{
sp.addDictionary(_newdict);
}

private function checkWord(var someWord:String):void
{
var correct:Boolean = sp.checkWord(someWord);
if( correct )
{
trace("Correctly spelled");
// ...
}
else
{
trace("Incorrectly spelled");
// ...
}
}

Note that loading the usa.zwl dictionary is an asynchronous event, and is accomplished by using a URLRequest and waiting for Event.COMPLETE to be dispatched.

Squiggly is highly optimized and very fast, and future versions will only improve upon this beta. Please try it out and post your comments or problems in the forums, which I and other Adobe employees will be monitoring.

Squiggly is available here: http://labs.adobe.com/technologies/squiggly/.

Unreadable Encrypted Local Store and the general internal error

One of the issues you may encounter when updating an AIR project in Flash Builder is what appears to be corruption of your Encrypted Local Store. This might manifest itself as a vague “general internal error” when your application attempts to read from or save to the ELS:

Error: general internal error
at flash.data::EncryptedLocalStore$/processErrorCode()
at flash.data::EncryptedLocalStore$/getItem()

When you run a new project and attempt to access the ELS, Flash will search the ELS directory with a case insensitive search, creating a new ELS if it doesn’t find an appropriate app ID. This is important to note, as the data you encrypt and save is keyed to a case sensitive copy of your application ID! Thus, if you migrate a Flex project with an application ID that varies only in case, Flash will find the ELS directory but fail to decrypt it, as your application ID is different than the key used to encrypt the ELS.

Flash will also fail to decrypt the ELS if your username (or perhaps user information) has changed, or if something serious happens to your keychain.

ELS files are stored in:
OS X: ~/Library/Application Support/Adobe/ELS/[app ID]
Linux: ~/.appdata/Adobe/AIR/ELS

In XP I’ve read that the files are either in C:\Documents and Settings\[username]\Application Data\Adobe\AIR\ELS or C:\Documents and Settings\[username]>\Application Data\[app ID]\ELS. On Vista I’ve read that it’s in C:\Users\[username]\AppData\Roaming\Adobe\AIR\ELS.

Your solutions are:
1. If you want your new application ID to be the same as your old one, make sure it doesn’t vary in case
2. If you want a new application ID, changing the case is not sufficient, as Flash performs a case-insensitive search while looking for the ELS
3. Remove the ELS data and allow Flash to create a new store. E.g., delete ~/Library/Application Support/Adobe/ELS/[app id]. You will lose any encrypted information

ShareFire, Flex, Flash Builder, and more

I’m excited to be working on Flex 4 (Gumbo), the next version of Adobe AIR, an app called ShareFire, and some other awesome projects that are a natural consequence of being hired by Adobe as an Applications Developer! I’ll be using this blog to post some insights (hopefully) into these projects, and into other technical issues as well.

I studied computer science and astronomy, but there’s the possibility that my posts may wander into things like little British sports cars, guitars, electronics, IDM…but I’ll try to keep this post, at least, on track. Check back here for some posts on:

  • An open-source RSS reader I wrote with fellow developer Christian Cantrell, called ShareFire (Google Code page). It’s written in AIR, meaning it’s cross platform (which, as a fan of Linux, I particularly like about the runtime), has a slick UI, and does some clever tricks RIA developers might like to know about. If you daydream about the complexities of asynchronous communications with SQLLite and HTTP-based data providers, or find yourself in want of information on how to beef up a scrawny component like the (frankly sadistic) mx:Tree, you may like my upcoming posts on ShareFire.
  • Flex 4. A lot of my new job involves using Flex 4 when I develop applications, so I’ll be able to tell you about the new states syntax, how the skinning architecture will work, and how to soup up an existing application–even if you still need some Flex 3 components. As an aside, I’ve seen some other blogs and I should warn you that I like to argue…debating the namespace change will be fun for at least one of us.
  • Flash Builder. Already I can tell you that it’s faster and has time-saving shortcuts that make me physically uncomfortable whenever I use Flex Builder 3. The auto generation of event handlers alone earns the cost of having to remove the FB3 sticker from my laptop and put on the shiny FB4 one. I’ve also done some PHP development with Zend Studio and the Zend framework, so I hope to chat with you about the new data-centric features that allow FB4 to work closely with PHP and Zend; they make connecting to remote procedures much faster, for a start, and Flash Builder does some clever things with design view.
  • Real-life issues with Flex and AIR. For example, we can make Rich Internet Applications, but why isn’t there a TextArea that has spell checking? I wrote a spell checker that generates a bloom filter, which allows the code to check ~13,000 words a second; I thought the theory behind an ActionScript bloom filter would be a good post, and I’ll talk about a free and open-source spell checking component in the near future.

I post on Twitter as antiChipotle, and I’ll be posting on this blog in the coming weeks.