ShareFire 1.8 released!

| No Comments

After some delays due to the excitement and aftermath of MAX 2009, I'm happy to announce that a new version of ShareFire is ready. ShareFire is a feature-rich feed reader written in Adobe AIR, and it allows you to easily share stories across Twitter, AIM, email, and social networking sites. I created it with my boss Christian Cantrell when I was interning at Adobe, and I've had some time to add features to it and maintain the code. Some of the new features are:


  • Import from Google Reader
  • English spell checking of Tweets and AIM messages, using the free Adobe Labs project Squiggly
  • UI improvements to the Tweet window and the post display (which now displays the author's name, if available)
  • Twitter URL shortening
  • Performance optimizations and reduced memory footprint
  • Keyboard usability improvements
  • Bug fixes

ShareFire is free and open source. You can access the code at http://www.code.google.com/p/apprise, including the list of changes made to this version: starting at revision 509.

Accessibility in AIR 2

| No Comments

Last night the AIR 2 Beta became publicly available on Labs! There are already some great tutorials, articles, and other information on the new features. To learn more about AIR 2, I recommend my colleague's post from last night: AIR 2 Public Beta Resources.

The feature I'll focus on, however, is accessibility support, which allows you to create applications that visually impaired users can use. Screen readers such as JAWS and NVDA can connect to your application and read off visual content. Using this feature in conjunction with existing Flex components is straightforward; I've written an article that shows you how to use AIR 2 and Flex to create accessible applications, and beginning to intermediate Flex users may also enjoy the tips on the Cairngorm framework, data binding, and using the Encrypted Local Store.

If you wish to use AIR 2 but need your own custom components, I recommend watching this presentation from Adobe MAX 2009, which goes into depth on AIR 2 and ActionScript accessibility.

Finally, I've created an open source application that you can use as a starting point for your own programs: QuothTheTwitter demos how to build an accessible Twitter client in AIR 2. It's quite simple at the moment, but incorporates many of the best practices I mention in my ADC article.

Adobe MAX and accessibility in AIR 2.0

| No Comments

I've been quite busy these last two weeks: first with the impressive and massive Adobe MAX, and then a week of personal traveling around the country.
outside.jpg

I co-presented on Accessibility in AIR and Flex with Michael A. Jordan at MAX, and briefly showed off a simple Twitter client written in Adobe AIR. AIR 2.0 will include accessibility support on par with the Flash Player, meaning you can create your own Accessibility Implementations in AS3 and/or leverage 28 of the existing Flex components which have accessibility support built-in. Even if you're not targeting visually disabled users, a lot of the design practices used in creating an accessible application will enhance your program's usability and polish. I recommend checking out our MAX presentation on Adobe TV: http://tv.adobe.com/watch/max-2009-develop/building-accessible-flex-and-adobe-air-applications/

Michael and I have provided some resources to help you with accessibility in Flash, Flex, and AIR. Michael's provided the slides for the presentation here: http://www.majordan.net/max2009/, as well as some very helpful source code for creating your own accessibility implementations.

Yesterday I open-sourced my AIR 2.0 demo app and put it on Google Code. You can access it here: http://code.google.com/p/quoththetwitter/. You'll have to wait for the public beta of AIR if you're not on the prerelease list (http://prerelease.adobe.com) to try Quoth The Twitter with a screen reader, but you can still use the application to learn about using CSS to provide a high contrast mode, using data binding to allow the user to change the application-level font size in real time, and to experiment with creating an application that can be used solely with the keyboard. It can also be an excellent starting point for creating a full-featured, accessible Twitter client written in Adobe AIR.

Spell checking in AIR, Flash, and Flex!

| No Comments

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:


	<fx:Script>
		<![CDATA[
			import com.adobe.linguistics.spelling.SpellUI;
			import mx.events.FlexEvent;

			protected function windowedapplication1_initializeHandler(event:FlexEvent):void
			{
				SpellUI.enableSpelling(textArea,"assets/usa.zwl");	
			}
		]]\>
	</fx:Script>
	<s:Group width="100%" height="100%">
		<mx:TextArea id="textArea" width="100%" height="100%"/>
	</s:Group>

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/.

You can vote on what gets fixed in Flex, Flash, and Flash Builder

| No Comments

I've been working on a demo application to show off a new feature in AIR, and this sort of work has me interacting with the Adobe bug databases quite often. One of the things you may not realize is that the public has read and write access to the Flash Player, Flex SDK and Flash Builder bug databases; more than that, every submitted bug is read by Adobe employees at bug review meetings, and bugs that have more votes are recognized as being important to the community.

Here are some pending issues in the bug database that I care about. If you also want these bugs fixed, you should vote on them (or submit some of your own):

Flash Player:
"Allow fullscreen mode to stay active on one monitor while the user is working on another"
I've seen users of MLB.TV find the current behavior especially annoying: Flash Player will close full screen mode if you interact with another monitor.
https://bugs.adobe.com/jira/browse/FP-1723

Flex SDK:
"Clicking and holding on a DropDownList doesn't select an item"
This affects all the drop down lists you see in Flex applications. When you click and hold a drop down list and let go of the mouse button when you're over an item, the item isn't selected and the menu doesn't close. This is different than the behavior of native drop down lists in OS X, Windows XP, and Linux.
https://bugs.adobe.com/jira/browse/SDK-22208

Flash Builder:
"Cannot view any key bindings in General/Keys in Preferences with the Emacs scheme"
Despite using vi for text editing, I'm addicted to the Emacs key bindings Ctrl + a, Ctrl + e, etc. Flash Builder (quite coolly) has Emacs keyboard shortcuts built in, but this bug prevents the preferences window from showing all the shortcuts.
https://bugs.adobe.com/jira/browse/FB-21871

You have to register to vote or comment on a bug, but the process is standard and quick. Here's the sign-up page: https://bugs.adobe.com/jira/secure/Signup!default.jspa

You can create your own bugs, and Adobe employees will read every one. You can do that here: https://bugs.adobe.com/jira/secure/CreateIssue!default.jspa
and you can search for existing bugs here: https://bugs.adobe.com/jira/secure/IssueNavigator.jspa.