As per usual, i had started a personal project that focused on refining parts of an old application and ended up creating a new library. This time, that application was going to get a face lift as i tried to port some code over to AS3-only views with the goal of targeting Android devices. What seemed like a little side project turned into a fun, can’t-stop-thinking-about suite of custom ActionScript 3 components.

You can view the components here: http://www.custardbelly.com/android/froyo/as3flobile/. If you have a Flash-enabled device, please check them out and let me know how they run. I have only really tested on my Nexus 1.

A full list of the current components is available on the project’s wiki in github. The main intent of creating these controls was to start thinking about user gesture as recognition and navigation within a control. My first task was to forget about scrollbars. They have essentially become useless on touch-devices in the context of navigating through content of a defined area. Though as3flobile does provide scrollbars in a sense (they are called Sliders) they are meant for selecting a value within a range, not as a handrail to hold onto to traverse items in a list. As a visual clue, the scrollbar still makes sense. As a user-input model, it is slowly not.

In any event, scrolling was the first gesture tackled. So I mainly started out making a ScrollViewport and then went crazy making all these other controls i know i would need if i ever got back to the original task at hand I could talk more in depth on how i tackled scrolling and how i kept the API open for you to create your own scrolling contexts and plug them in in later posts if you’d like.

There is some tap recognition, such as when selecting a list item or a RadioButton, but most of the focus is on swipe gesture for scrolling. I would like to start diving into other gestures (ie. zoom) which would probably make me rethink the architecture of a custom component for a touch-device, not only in its gesture recognition but also how you interact to access information. For instance, does a drop down really make any sense any more? (though there is a DropDown in as3flobile) I don’t know if i am the only one, but it really feels antiquated to me. I wonder if there will come a time when we are old and we look at old pictures of the online forms we used to fill out with there funny old clunky controls… how much time was wasted.

You keep talking, but can you skin them?

Yes, you can skin them. There really isn’t a skinning architecture in as3flobile per se. Any control that is a subclass of AS3FlobileComponent (which all the controls in the library currently are) can accept an ISkin and can maintain a state related to or rather accessible by an ISkin. Furthermore, the assignment, targeting and update to the skins is handled within AS3FlobileComponent with protected hook-ins you can override if seen fit.

However, if you look at the default skins within as3flobile, in com.custardbelly.as3flobile.skins.*, you’ll see that the ISkin implementations actually reference their target controls directly to access the graphic displays needed for custom skinning. I figured there was no reason to add extra overhead by creating interfaces for a control strictly for skinning purposes. If you create a custom skin for a control, it is assumed you know what the control needs to look like; so access it directly. Though the target property of ISkin is ISkinnable (which AS3FlobileComponent implements), the target is most times cast to the specific control that is being skinned. If people are really interested in these components and curious as to how to skin them, i can definitely fire up some more posts on that.

In any event, i hope you check out the as3flobile project in github and/or get down to business as Gary always seems to do. If you do check out the as3flobile project, suggestions, comments and questions are always appreciated. I am sure there are some bugs and some aspects of the controls that i just didn’t think of that may be needed.

When the new year came and i had finally got in my last chapter for Flex 4 Cookbook, it was time to return to my list of things to learn. I started looking into Capuccino and Closure and bought a book on Python. Somewhere along the way i just clicked on some tweet about 5 emerging trends that i must know about. Usually i find these lists are a grain-of-salt bandwagon of buzzery – maybe some truth but can’t cut through the true meaning of why this person is writing about them. But one did stick – NoSQL. I looked into the different implementations and right away i took a fancy to CouchDB. I don’t know why. It seemed quite simple. Working with a database using REST calls. Sounds good. And i could write my own map-reduce views in Javascript. Sign me up.

What also was a big draw to me was the concept of document revisions in CouchDB. I had worked on a couple projects that required online/offline synchronization and it was quite a pain to keep track of last modified entries and cleanup of deleted entries in a SQL database. The revisioning system for documents (entries) is built into CouchDB and what is more is that you are not locked into a rigid data structure and ensure your table relations are scalable. That’s not to say that building relational databases isn’t a fine art. It is. And there are many smarter people than me that get paid more money that have that craft. I don’t. The concept of revisions is familiar to me and i am greatly intrigued by the concept of NoSQL.

Anyway, i started digging into CouchDB and figured the one way for me to see the whole picture was to hook up a client side end to make these requests. See if what i was reading about was something i could use as a different approach to online/offline synchronization in my applications. What came out was a whole library for working with databases and documents of a CouchDB instance – a library which is now available on github at http://github.com/bustardcelly/as3couchdb.

Took me long enough to get talking about the as3couchdb library mentioned in the title, didn’t it? Well, you can read more long-winded explanations about the make-up of the library from the wiki on github, and browse some examples that use the library (currently all Flex examples, but AS3 examples are coming soon).

If you are still around, i can give a brief synopsis of the project:

When i set out on creating the as3couchdb library, i knew i wanted to follow a similar approach to Data Access Objects. I wanted to make all my requests through the object i was working with and have an intermediate layer that communicate with the service and updated the object accordingly. To achieve this, i went about creating a base model class that contains a model entity. The model entity is really only involved in parsing custom metadata and resolving the information to properties held on the base model. Extending the base model are the two core models of CouchDB that you interact with: the Database and the Document.

So the Database and Document models can be though of as the Business Objects and expose methods that related to CRUD operations. Even though CouchDB has a REST API, i chose using simple CRUD method signitures on the models as they seem easier to read and understand. From these methods, the models interact with a service mediator (similar to Data Access Object), which knows how to communicate with the service proxy and has action handlers that know how to modify the model once a successful result is received. To put it in code terms:

I wanted to have the ease of creating and storing a document as such

var contact:ContactDocument = new ContactDocument();
contact.firstName = "Todd";
contact.lastName = "Anderson";
contact.addEventListener(CouchActionType.CREATE, handleContactCreate);
contact.create();

And the ease to simply read in for modification as such:

var contact:ContactDocument = new ContactDocument();
contact.addEventListener(CoachActionType.READ, handleContactRead);
contact.read( $uid );

In order to make this all work and auto-wire the models with a service mediator, custom annotations were needed. This is where the model entity mentioned earlier comes into play. When extending the core models (as ContactDocument does in the previous examples) you add custom metadata that relates to the CouchDB instance you intend to work with and the fully qualified classnames of the target service mediator and request object.

Now the request object is a different story and was brought into the picture due to the lack of HTTP method types available for the web version of Flash Player. As such, there are a couple different request object types available in as3couchdb: straight-up devil-may-care requests using URLRequest (mainly for AIR or you will get RTEs), one that uses External Interface, and one that uses as3httpclientlib. The as3httpclientlib allows you to make PUT and DELETE requests using a Socket and is the best way to interact with a RESTful service when limited to the Flash web player (imho).

So that is a brief rundown of the model and business layer implementation i strove for when creating as3couchdb. As i mentioned way back in upward-page-scroll land, the original drive to make as3couchdb was to see if i could ease up the pain of developing an application that uses online/offline synchronization. That is in the works and maybe this blog will become a little more active as I dive into that task.

If you made it this far, thank you for reading all this. Wow. You are a trooper. Tell your boss i said it is okay and you can bill that time.

Link-link time!
CouchDB – http://couchdb.apache.org/
CouchDB: The Definitive Guide – http://books.couchdb.org/relax/
CouchDB: Wiki – http://wiki.apache.org/couchdb/FrontPage
Planet CouchDB – http://planet.couchdb.org/
MongoDB, CouchDB and MySQL Compare Grid – http://www.mongodb.org/display/DOCS/MongoDB,+CouchDB,+MySQL+Compare+Grid
as3httpclientlib – http://github.com/gabriel/as3httpclient

More information about the custom metadata, and the inner workings of as3couchdb can be found on the wiki for the project in github.

Wanted to blog about it as well, as i feel there is some great information from his post about the decision for cutting chapters and where to download code and the best way to submit errata. He also mentions the heartbreaking decision to cut chapters and recipes from the book to preserve page count… but don’t put the book back on the shelf, they are available to download!

We hope people are enjoying the book at what any level developer you are. Cheers to Josh and happy coding!

read Josh’s post

I am a workspace fanatic when it comes to development. I like things tidy, and when i start a new client project or go into some new exploration that involves multiple projects, i create a new workspace. The great thing about workspaces for me, aside from keeping things neat in my head, is that each new project you create in that workspace inherits from any default settings. So when the big news hit and i wanted to check out the latest SDK, i created a new workspace and followed most of the excellent directions already available on the adobe open source site. I only strayed a little in how i went about setting my workspace up so that every new project i created in it was *almost* set for development targeted at FP10 without having to run through the process each time.

The following is the process i took to only mess with the files from the nightly build and set defaults for a single workspace in order to play around with the current features available in Astro:

1. Download Flash Player 10 codenamed Astro.
2. Download the nightly build and unzip to some directory. (for me that is /Applications/flex_sdk_3.0.1.1728
3. Open FlexBuilder or Eclipse (if you have the plugin) and create a new workspace. (ie. ~/Documents/workspace/astro).
4. Create a new project.
5. Navigate to Project>Properties
6. Select the Flex Compiler option
7. Under Flex SDK version, click Configure Flex SDKs…
8. In the Preferences (Filtered) window, select Add
9. Navigate to the installation of your nightly build. (ie. /Applications/flex_sdk_3.0.1.1728)
10. Add a new name for the SDK… you should see something like so:

””””””””””””””””””””””””””””””””””””””””””””””””””””””’

11. Click OK, Then tick the checkbox next to the newly added sdk in the Installed Flex SDKs window.
12. Click Apply, then OK.
13. Then back in the Project Properties folder, under Use a specific SDK, if the newly added SDK isn’t selected, select it.
14. Under the Required Flash Player Version, change the value to 10.0.0
15. In the Project Properties window on the left side, select Flex Build Path> Library Path.
16. Expand the SDK you just set as default, and select the playerglobal.swc and Remove it.
17. Click Add SWC, and navigate to the player 10 swc from your nightly build SDK installation (ie. /Applications/flex_sdk_3.0.1.1728/frameworks/libs/player/10/playerglobal.swc)
18. Click Apply, then OK.
19. Open up the flex-config.xml file from the Astro SDK installation and update the settings as described in the first part of the Command-line Compiler instructions from here.

Thats it! Only 19 steps… that seems like a lot. In any case, in ensures that any project you now build under that workspace will default to using the targeted SDK. You will still have to manually change the Required Flash Version (from step 14) before you compile a new project, but other than that when you want to tinker with the nightly build – and not mess with your stable Flex 3 SDK release that other projects in other workspaces are targeting – just hop over to that workspace.

Good reading:
Ryan Stewart – Flash Player 10 codename “Astro” goes beta
Tinic Uro – Adobe Is Making Noise series
Keith Peters – Astro Dynamic Sound!
Josh Tynjala – Gratuitous Text Effects

I don’t want to go into IoC and dependency injection and how your applications can truly benefit by using the Prana framework, as this post may get pretty long and these references are much better reading than my rambling:

Christophe’s blog: http://www.herrodius.com/blog/
Martin Fowler’s Inversion of Control Containers and the Dependency injection pattern
the hollywood principle

What i did want to bring up is that i had a small problem with the workflow and how i develop. Which is my problem, of course but nonetheless…

One important thing to remember is that the context file is an external file that is loaded by the application at runtime. This means you will need to have all the possible classes your application may use already compiled into the SWF in order for the objects to be instantiated and your application to work. If you are typing to interfaces, this could prove to be a bit of a problem. You could create a reference for each class that may be needed in another class that is known to be compiled into the SWF – as Christophe explains in this post – but that always seemed dirty to me.

As is mentioned in the comments to that post, you can also go about adding each class using the -includes compiler option. Adding all possible classes using the -includes option makes for an excellent case on when to use additional compiler configurations, and presents the option to really just change the application context file and the additional configuration file as the project sees fit, without having to open up the source and tack on or remove dummy references to classes.

As an example, take for instance this application context file:

< ?xml version="1.0" encoding="utf-8"?>
<objects>
	<property file="app.properties" />
	<!-- Handles direct invocation on client -->
	<object id="callbackHandler" class="com.example.responder.CallbackResponderImpl" />
	<!-- Handles connection to Red5 application -->
	<object id="connectionDelegate" class="com.example.business.ConnectionDelegateImpl">
		<property name="rtmpURI" value="${app.rtmpURI}" />
		<property name="client">
			<ref>callbackHandler</ref>
		</property>
	</object>
</objects>

.. for each possible implementation of ConnectionDelegate and CallbackResponder that i may decide to swap in and out as the project seems fit, i would either need to hold a reference to each implementation in some class sure or be compiled into the SWF, or i could store them in an additional config file that can be added using the -load-config option with an additional value:

The prana.config file:

<flex -config>
	<includes append="true">
		<symbol>com.example.reponder.CallbackResponderImpl</symbol>
		<symbol>com.example.business.ConnectionDelegateImpl</symbol>
	</includes>
</flex>

… drop that in my source folder and add the compiler option:

-load-config+=prana.config

From there, i could change the context as i see fit, update the prana.config file to reflect my preferences and just recompile the application without having to go into the source and muck about. It’s a little more clean for me and allows me to happily go about using the Prana framework.

The best part is that Prana is truthfully AS3 compliant! Meaning you can use it in your Flex AND AS3 projects, which cannot be said for some frameworks that claim to be AS3 and actually use class from the mx package… (looking at you as3lib). A huge pet-peeve of mine.
*Last i checked, the source under version control doesn’t seem to reflect the current changes Christophe has made, but they are included in the downloads.

Marc Leuchner and Matt Wright (of NoBien fame) and I have been burning the midnight oil to deliver an exciting book on Adobe AIR – AIR Create-Reuse-Modify from Wiley Wrox press. Each chapter walks through building applications as you learn about the AIR API. We had a lot of fun architecting and writing about each application that highlights specific facets of the platform and hope it is as much fun to read. Adobe AIR and the API is part of the Flex 3 SDK, which might be coming out soon…

Well, i didn’t stop at discussing one part of the Flex 3 SDK and also was asked by Josh Noble to be a co-author for the Flex 3 Cookbook from the O’Reilly press. We’ve gathered the submissions from the Adobe online cookbook and Josh has been steering the cookbook ship to greatness. If you are unfamiliar with the O’Reilly cookbook format, the book is designed to present hundreds of ‘recipes’ aimed at solving programming problems. I have had the extreme pleasure to write about parts of the Flex API that i love and believe to be essential to RIAs developed using the Flash Platform.

If writing didn’t keep me busy enough, I worked with some amazing people while building applications that stretched the possibilities of what online and desktop applications built in Flex can do. Along the way i learned more about the business, some agile practices (which i hope to write about some) and how to have fun and love what i do. It is an amazing thing.

I also have had the opportunity to join the Infrared5 team and could not be happier. Infrared5 is a consulting company started by Chris Allen, Rebecca Allen and Dominick Accattato focused on architecting applications using the Flash Platform and Red5 Server technologies. Keith summed it up pretty well in this post. I am honored to be in company with some of the brightest minds in the field that keep me laughing throughout the day. Once I stop breaking things around the office, i can settle in and learn something

All in all, 2007 was a great year and i am making out 2008 to be even better. Here’s to posting more!

I don’t pretend to know enough about the architecture (so someone speak up if i am off track), but adding components to NativeWindows – without Daniel’s or the proceeding example- fails due to the reference to your main ApolloApplication’s stage when displaying components within the Flex framework. You can add all the displays existent in the AS3 library (Sprite, TextField, etc.) to the stage of your NativeWindow instance, but any in the Flex framework need a little push. Adding MXML components to your NativeWindows will still have to follow the formula Daniel laid out using the addChild/removeChild methods, yet there is a workaround to this for ActionScript components by adding an ADDED_TO_STAGE event listener within its constructor.

I have a tendency to try and word things right and it comes out all mush, so i’ll just show some code. You can alternatively look at source view.

The CustomLabel (CustomLabel.as) component that will be added to our NativeWindow:

        import flash.events.Event;
	import flash.text.TextField;
 
	import mx.containers.Canvas;
 
	public class CustomLabel extends Canvas
	{
		private var _label:TextField;
 
		public function CustomLabel()
		{
			super();
			addEventListener( Event.ADDED_TO_STAGE, init );
		}
 
		private function init( evt:Event ):void
		{
			createChildren();
		}
 
		override protected function createChildren():void
		{
			super.createChildren();
 
			_label = createField( "HelloWorld" );
			stage.addChild( _label );
		}
 
		override protected function updateDisplayList( unscaledWidth:Number, unscaledHeight:Number ):void
		{
			super.updateDisplayList( unscaledWidth, unscaledHeight );
		}
 
		private function createField( txt:String = "" ):TextField
		{
			var label:TextField = new TextField();
			label.text = txt;
			return label;	
		}
	}

… And the main mxml (NativeWindowExample.mxml):

<mx :ApolloApplication 
	xmlns:mx="http://www.adobe.com/2006/mxml"
	width="200"
	height="100" 
	layout="absolute"
	applicationComplete="onAppInit();">
 
	</mx><mx :Script>
		< ![CDATA[
 
			private var _launchWindow:NativeWindow;
			private var _customWindow:NativeWindow;
 
			private function onAppInit():void
			{
				_launchWindow = this.stage.window;
				_launchWindow.addEventListener( Event.CLOSE, onAppClose );
			}
 
			private function openCustomWindow( evt:MouseEvent ):void
			{
				if( _customWindow != null ) return;
 
				var options:NativeWindowInitOptions = new NativeWindowInitOptions();
				_customWindow = new NativeWindow( true, options );
				_customWindow.stage.align = StageAlign.TOP_LEFT;
				_customWindow.stage.scaleMode = StageScaleMode.NO_SCALE;
				_customWindow.title = "CustomWindow";
				_customWindow.stage.addChild( new CustomLabel() );
				_customWindow.addEventListener( Event.CLOSE, onWindowClose );
			}
 
			private function onWindowClose( evt:Event ):void
			{
				_customWindow = null;
			}
 
			private function onAppClose( evt:Event ):void
			{
				if( _customWindow != null ) _customWindow.close();
			}
 
		]]>
	</mx>
 
	<mx :Button id="windowBtn" 
		top="10" left="10" right="10" bottom="10"
		label="open custom window"
		click="openCustomWindow( event );">
	</mx>

NOTE: the preceding code has some major problems due to mx tags in wordpress, so disregard all affending close tags

— As well, you could extend NativeWindow and add the AS components to its stage to bypass adding them in the main app. –

In the main app file we are just creating a new NativeWindow instance and adding the custom AS component, CustomLabel, to it’s display.

_customWindow.stage.addChild( new CustomLabel() );

What is happening in the constructor of the CustomLabel is of importance in this example, as it listens for its event of being added to a clients stage. From there we can call the override of UIComponent:createChildren, and add whatever we want to the display. When creating AS components NOT to be added to the NativeWindow, that method (createChildren) would be called as long as you call the super constructor. That is not the case when adding components extending the Flex framework in NativeWindow. Again, if i am missing something crucial or if you have more insight, please leave a comment. So that’s it. Once it has been added to the stage, we can go about our business. Of course, when using ActionScript components you lose the inherent layout capabilities within MXML components, but that is why we’ve added the override of #updateDisplayList.
Until Flex came around, i know i spent more than my fair share nailing down layouts for applications- so this is like going back home…

To find out more about extending ActionScript components, visit this post on FlashGen and this doc from the labs.

PS. I’ve been a little lacking in the post area, and though i have the usual excuses- family, work, beer… – i could be more on top of it and you should be seeing more Flex and Apollo thoughts in the near future, but no promises because i love those excuses. I also am working on something that i hope to announce here a little later if all goes well…

Adobe had release their ASDoc command line tool around the 11th- i was otherwise occupied, but am happy to find a way to figure documentation into Keith Peters’ FlashDevelop templates for Flex2 and As3 projects now that i am back at my computer.

( If you haven’t already, follow that link to Keith’s tutorial on adding project templates if you are interested in creating an excellent dev environment in FD and are curious about what i added to target auto-documentation in the ANT process ).

To sum it up, all i added was a couple properties to the build.properties file and a conditional target to the build.xml. The modified files are here:

build.properties
build.xml

… be aware that these are modified files downloaded from keith’s post, so if you have changed some values in the properties file on your own machine you shouldn’t explicitly replace these with your own.

[Note: it's not really actionscript code below, i'm just being lazy]

The additions to build.properties:

1 – under the project properties header…
[as]#document titles
docbuild=false
doc.maintitle=templatetest
doc.windowtitle=’template test’[/as]

… the docbuild property is a string boolean evaluated in a conditional in the build.xml. The others are command params found here. Remember that anything with spaces needs quotes around it, as is the value for doc.windowtitle.

2 – under the tools header…
[as]# where you installed your documenter:
asdoc.dir=C:/Flex_2_sdk
…
# most of this shouldn’t need to change
…
documenter=bin/asdoc.exe
…
[/as]

… where asdoc.dir and documenter are relative to where you unzipped the ASDoc – in this case i threw it into the directory of the sdk.

the additions to build.xml:

1- conditional added to the compile target:
[as]


[/as]
2 – the document target
[as]




[/as]
3 – antcall added to build target:
[as][/as]

… Changing the doc.build value in build.properties to any string other than ‘true’ will cause this to not rebuild the documentation, which can be handy if you are just doing quick tests or bug finding – otherwise, if set to ‘true’ it will document any AS files recursively found in ${source.dir}.

I had a similar build made up for AS2 projects and BlDoc in FlashDevelop using ANT earlier and thought i’d have a go with it using ASDoc, maybe someone else will find this useful…

After i brought those old Game&Watch handhelds home, i started playing them heavily. After being beat into submission hundreds of times i began thinking ‘these games are too damn hard’ – so i put them down and decided to try and recreate one in Actionscript3… here’s the first one i came out with – a remake of Donkey Kong Jr from the widescreen Game&Watch series.

With the previous games i have worked on, i employed a pixel collision detection system to drive game play- but when thinking about LCD games, spaces on the screen are reserved and there is no real overlap of pixels to detected when an enemy runs into a hero, an enemy connects with a projectile, etc. Instead i had to employ a sort-of ‘mother may i’ management system where a call is made from every ‘object’ prior to it’s bitmap update to see if anything is in between where what block it’s in and what block needs to be rendered next. The development was based mainly on Passive Matrix LCDs.

Ultimately how it is put together is by loading a graphics sheet with all the states for each ‘player’ and then basing it’s rendered state upon game interaction and a list of state ‘matrices’. On each ‘allowance’ of movement the bitmapdata is cleared and redrawn with a new state. And in the case of the enemies, based on your progression through the game, the ‘allowance’ timing is sped up.

The biggest thing i have gained from working this through is the beauty of the new Timer class. With the introduction of BitmapData in Flash8 As2 i began rethinking how i was developing, and now with the Timer class i’m doing it again. I loved onEnterFrame for so long, but that just wasn’t gonna hack it for this project… and i’m glad it didn’t.

I kept the architecture pretty open for easy adaptation and extension so that i could make more of these LCD games with ease, but i think i have to step away for a bit. Sound would be a good addition to this and i plan to do a little work on that, but i’m getting pretty busy.
Enough talk, enjoy the game and keep in mind that this is a rough prototype, so you may encounter a bug or two

I trimmed down some processes and stripped any excess so the classes included focus just on the tile scroller. In my previous post the movement was based upon the position of the sprite- here it’s based soley on keystrokes. It also utilizes some of my ImagesLoader classes.

The real meat is in the updateScroll method of the MapScrollLayer class. That handles all the update of bitmapdata to the gridded tiles, and redraw/scroll of the displayed bitmap.
One thing i found exciting was creating custom namespaces. If you take a peek at com.custard.as3.models.TileLayerMap, in the constructor it creates a 2d array based on the data type.

I had planned to make a fuller presentation with some tutorial-like explanations, but my time is pretty thin right now. If enough people are interested in that, i’d definitely get on top of it. A basic understanding of OOP may be needed to gather something from the code. i don’t really plan to go that much into it, but if you are a little rusty, unfamiliar with the concept, or want to learn more, Ben Stucki is going into that this month on his blog.

…also…

every time i go back home to my parents’, there’s some more boxes of ‘junk’ that have been sitting in the basement, stuck in some dark corner, since my room was turned into an office.
this past weekend i went through another said box, and pulled out this bounty!

had forgotten all about these guys…

i’m waiting for the box that had my old etch-a-sketch animator gadget. man, i loved that thing.