foomonger's blog

Swiz 1.0.0 RC1 was recently released so I've updated my custom metadata processors to work with it. Head over to Google Code to check out [MediateSignal] and [Resource]. Happy coding...

I started using the SwizLogger recently and quickly realized I wanted to do the following:

1. Create ILogger instances without importing Swiz classes in my application classes
2. Easily add targets in MXML

#1 isn't a huge deal if you consider logging to be more of a system tool than an application dependency, but if I'm avoiding Singletons why not keep it up. #2 also isn't a big deal because it doesn't take much ActionScript to add logging targets, but I think it makes a lot of sense to do it declaratively.

Piotr Walczyszyn created a custom LogProcessor to address #1, but I didn't like how the TraceTarget was hard-coded into it. Instead of building more complex processor I decided to create a bare-bones LoggerProcessor and SwizLoggerConfig class.

Here's an example application's source (the SWF is just a button):  Source

The LoggerProcessor is again bare-bones. All it does is inject an ILogger instance using SwizLogger:

[Logger]
public var logger:ILogger;

The LoggerProcessor priority is set to be one above [Inject] so the injected ILoggers are available at [Inject] and [PostConstruct].

SwizLoggerConfig doesn't do too much either. It's just provides a default public Array property which is used to add targets to the SwizLogger.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:utils="com.foomonger.swizframework.utils.*"
        xmlns:view="example.view.*"
        xmlns:local="*"
        layout="absolute">
    <mx:Script>
        <![CDATA[
            import mx.logging.LogEventLevel;
        ]]>
    </mx:Script>
    <utils:SwizLoggerConfig>
        <mx:TraceTarget
                includeCategory="true"
                includeDate="false"
                includeLevel="true"
                includeTime="true"
                level="{LogEventLevel.INFO}"
                filters="*"
                fieldSeparator=" | "/>
    </utils:SwizLoggerConfig>
    <local:SwizLoggerConfigExampleSwiz/>
    <view:MainView/>
</mx:Application>
 

The value of these classes will depend on your personal style and preference. I wrote them so I like them. They're available on Google Code.

Happy coding.

* Update: Here's the MXML syntax for adding multiple packages to the filters Array:

<mx:TraceTarget
        includeCategory="true"
        includeDate="false"
        includeLevel="true"
        includeTime="true"
        level="{LogEventLevel.INFO}"
        fieldSeparator=" | ">
    <mx:filters>
        ["foo.bar.*", "com.foomonger.*"]
    </mx:filters>
</mx:TraceTarget>
 

I'm using the Swiz Framework in a side project which requires runtime loading of all the copy. I decided to use Flex's ResourceManager by parsing static XML files and populating the ResourceManager with the newly created ResourceBundles. Binding resources into view's wasn't too bad, but it could be better. For one thing any component that needed a resource included a ResourceManager dependency. So I thought about it and then created a ResourceProcessor which really cleans things up.

Here's an example application:

• SWF
• Source

I set up the [Resource] tag to mirror the @Resource directive. All you do is decorate a property like so:

[Resource(key="title", bundle="example")]
[Bindable]
public var title:String;

The processor binds the resources so they will update when binding events fire in the ResourceManager. And you only need to include a ResourceManager dependency if you are adding resources at runtime or changing the locales array.

This processor is available in my foomonger-swizframework project on Google Code. Enjoy!

Joel Hooks created this RobotLegs/Signals demo. Ben Clinkinbeard then created this Swiz-version of Joel's demo. I then took Ben's demo and Swiz-ified it even more by using a custom [MediateSignal] processor. Here's the source.

[MediateSignal] is the Signal equivalent of [Mediate]. Here's an example:

[MediateSignal("galleryUpdatedSignal")]
public function galleryUpdated(gallery:Gallery):void

[MediateSignal] takes a Signal Bean name or type and adds the decorated method to the Signal (see GalleryThumbnailsPresentationModel for examples).

This is what I changed from Ben's demo:

• Created the MediateSignalProcessor
• Added [MediateSignal] metadata to the Signal listeners
• Made the Signal listeners public
• Named the Signal Beans
• Removed [PostConstruct] methods that added the Signal listeners
• Removed injected Signals that weren't being using to dispatch

[MediateSignal] makes using Signals in Swiz very parallel to using Events (especially if you define the Event dispatcher as a Bean and inject it by name). And just like Events, you only need to [Inject] the Signals into Beans who are dispatching Signals. I was pretty excited to create my first custom processor and play with Signals for the first time. Let me know what you think!

Disclaimer: I set up MediateSignalProcessor to also handle DeluxeSignals and remove listeners, though to be honest I didn't test those.

* Update: I've posted the processor on Google Code and it contains unit tests (including DeluxeSignals and removing listeners).

** Update: I've created a bare-bones example application: SWF and Source.

Test-driven development. Tried it. Sometimes loved it. Rest of the time hated it.

I think TDD is great when you know what the code should do. When I'm writing parsing code or something else very utilitarian I definitely prefer to write the tests first. As a Flex/Flash developer, most of my code is directly for the UI, and often I find that I'm not entirely sure what my code should do right away. I'm becoming a big fan of the Presentation Model pattern, but even with that, I find that it takes exploratory development to determine exactly which component should do what and which logic should go where.  I found it very burdensome to update both the regular code and tests step-by-step . Not being a TDD expert I could easily be doing something or interpreting something incorrectly. Or perhaps I'm just lazy.

I've decided, at least when it comes to UI development, to follow a looser Testable-driven development technique. As I'm fleshing out my component logic, I constantly ask myself, "Is this code testable?" or more generally "How will I know if this works?" This primitive technique gives me the freedom to write exploratory code while helping to reign in potential magic logic. I then write tests once things have settled down, refactoring any logic to make things more testable as necessary. This technique also fits my style of coding where I like to sketch out logic with small tracer bullets.  It definitely takes some discipline to think about the testability of the code, but so far I'm much more comfortable with testable-driven development for UI work.

I've been using mock-as3 in my Flex unit tests a lot recently discovered a couple useful strategies for mocking things that are not obviously mockable at first glance:  Loader and Services (AsyncToken).

Here is the source for a Flex project that I'll be referencing that contains a sample controller with its tests: MockingLoaderAndServices

Most of the relevant code is in com.foomonger.blog.mockingloaderandservices.controller.ControllerTest.

ControllerTest contains tests for Controller which has 2 methods: loadAssetsSwf() and loadDataXml(). Those methods call corresponding methods in the Delegate. loadAssetsSwf() demonstrates loading a SWF using a Loader. loadDataXML() demonstrates loading XML through an HTTPService. In ControllerTest I create MockDelegates which is then injected into the Controllers.

flash.display.Loader

When loading a SWF into another SWf, you use the Loader class and listen for events from the contentLoaderInfo property. To mock the loading of a SWF, you have to simulate events being dispatched from contentLoaderInfo. The problem is that you can't call dispatchEvent() nor subclass LoaderInfo and instantiate it.

The solution: LoaderInfo2. In the source you'll see that the class flash.display.Loader2  subclasses Loader and adds a contentLoaderInfo2 property of type IEventDispatcher. By default it's set to the normal contentLoaderInfo, but can be set to a generic EventDispatcher for testing. When you set contentInfoLoader2 to an EventDispatcher instance, you can then call dispatchEvent() on it. Note that Loader2 is used instead of Loader in the Delegate and Controller. See ControllerTest.test_loadAssetsSwf_complete() .

This is not an ideal solution but works well enough for my uses.

mx.rpc.AsyncToken

When loading data using Flex service objects, you get back an AsyncToken which you can add event listeners and responders. I typically add responders. To mock the service calls, you have to simulate the calling of the responders. The problem is how do you trigger the response?

After a little digging around, I found that ResultEvent and FaultEvent have the mx_internal method callTokenResponders() which triggers the response. So the solution is pretty straight-forward: create the appropriate Result(Fault)Event object, passing an AsyncToken,  and call callTokenResponders() .  See ControllerTest.test_loadDataXML_result().

The way I develop software regularly evolves as I learn better practices, and this is particularly true in the way I organize view code in Flex applications. I've seen (and built) too many applications where the code is unncessarily difficult to jump into and maintain. Inspired by domain-driven design and test-driven development, I've been organizing view code in such way that I believe helps maintainability and also helps answer the question, "Where should I put this component?".

Here are some guiding principles:

• The view code should reflect how you talk about the application with the entire team.
• The view code should reflect how you interact with the application.
• Repeating yourself can be a good thing.
• Components and events should be contextual.

Let's way we have an application that manages contacts. There's a list of all your contacts on the left. There's a list of recent contacts on right right. The selected contact's detail shows up in the middle. There is also a Twitter feed widget in the contact's details. Here's a wireframe:

Here's how I would create the view package:

com.foomonger.contactmanager.view.ContactDetailsView
com.foomonger.contactmanager.view.contactdetails.events.ContactDetailsEvent
com.foomonger.contactmanager.view.contactdetails.TwitterFeedWidget
com.foomonger.contactmanager.view.AllContactsView
com.foomonger.contactmanager.view.allcontacts.ContactItemRenderer
com.foomonger.contactmanager.view.RecentContactsView
com.foomonger.contactmanager.view.recentcontacts.ContactItemRenderer

So what did I do? I created components that reflected the wireframe. There is a component for each major section (all contacts, contact details, recent contacts). I named the Twitter component "TwitterFeedWidget" even though I thought the "widget" part was dumb but that's what the product owner and overall team calls it. I also created a ContactDetailsEvent class within an "events" package specific to the ContactDetailsView component. That may be a bit extreme for some people, but I find that it helps me keep track of the purpose and scope of view events. I also created a ContactItemRenderer for both the AllContactsView and RecentContactsView. Even if the code was identical in each item renderer, I prefer to keep them distinct instead of having a common one in a generic "itemrenderer" package. I argue that what I lose by repeating myself I gain back in maintainability. If there was a common ContactItemRenderer, after many months of new feature development with several developers it'll be easy to lose track where it's used. If the item renderer has to do something different in one particular case you can of course add properties and states to keep it multipurpose. However I've found this to be regression prone. If you have distinct contextualized components, you can be more confident that a change will not cause regression elsewhere.

I used to always look for even the slightest resemblance of a pattern and abstract all kinds of code into shared components. But I've realized that developing an application is different from developing a component library or a framework. In a component library you can have a generic color picker. In a framework you can have a generic "itemrenderer" package. I'm not saying you can never do these things in an application, but I am saying that I think application development should be very (domain) specific.

RPSConquest was my first Google App Engine/Django/Flex/Facebook application. It's a turn-based rock-paper-scissors game played within Facebook. I built it to learn a variety of technologies and to see how well those technologies worked together. I was particularly interested in using Google App Engine and learning Python. In this post I'll elaborate on the technologies used, discuss curveballs I faced, and share some conclusions.

Technologies:

• Back-end:
  • Google App Engine (SDK 1.2.4)
  • Python (2.5.4)
  • Django (1.0.2)
  • Google App Engine Helper for Django (revision 90)
  • PyAMF (0.5)
    • PyAMF Test Client (Slightly modified from the original Test Client)
  • Pyfacebook (0.1)
• Front-end:
  • Flex (3.3.0)
  • Swiz Framework
  • Facebook ActionScript Library
• Development Environment
  • Windows XP
  • Eclipse
    • Flash Builder 4 Plugin
    • Pydev

Flex has been my primary technology over the past couple years, and I wanted to build a Facebook game with it. I'm addicted to the Swiz Framework so I continued to use that (instead of Cairngorm). The app required a Flex Facebook-Friend-Selector component so I also needed the Facebook ActionScript Library for the FqlQuery command.

I planned to build an AMF service layer for the Flex app and almost went a LAMP/Zend setup on my personal web server. I was introduced to Google App Engine by a colleague and quickly went with it because of the automatic scalability and free quota.

App Engine currently supports Java and Python, and I went with Python because the Django framework sounded really interesting. Using the Google App Engine Helper for Django almost seemed like a must for a newbie like me.

There were a couple AMF libraries for Python, and I first tried DjangoAMF but quickly found it to be unusable for my Flex 3 app. I ended up using PyAMF which worked out really well. I wanted to write unit tests (which Django is great for) and found that I needed a test client for the remoting classes. I founded one on a random blog post and added it to my PyAMF files (with some minor modifications). With the remoting test client and the Django test client I was able to write and debug unit tests for all my AMF services.

My app needed to notify Facebook users and post messages on walls. Instead of doing this on the client-side, I did this in Python with Pyfacebook.

Instead of using the standalone Flex Builder, I used Eclipse with the Flash Builder 4 and Pydev plugins for development environment. I was able to  locally debug both Flex and Python code all while running the app within Facebook (thanks to port-forwarding).

Curveballs

Version Compatibility

Though it was documented, I still stumbled with the version compatibility of Google App Engine, Python, and Django. Be sure to double-check what works with what in the latest documentation.

Locally Running the Python Server to be Available through Facebook

For local development I created a development Facebook application which pointed to my machine's IP address using port forwarding and dlinkddns.com. What I didn't understand until I read the docs more carefully is that when I ran the development Python server using "manage.py", it defaulted to the IP address 127.0.0.1 (on port 8000) which prevented Facebook from being allowed to hit the server even though it could hit my machine. I ended up using "manage.py runserver 0.0.0.0:8000" which allowed Facebook to hit the development server.

Google App Engine Datastore is not a Relational Database

Before I decided to go with App Engine I had sketched out my model to create tables in a MySQL database. I had about a half-dozen tables which in Django directly correlates to a half-dozen model classes. As I was developing the business logic I learned that the App Engine datastore is not a relational database. I couldn't do joins. That forced me to significantly refactor and basically de-normalize my model down to 2 classes.

These links helped me understand what was going on:

• http://tech.boradev.com/?p=38
• http://code.djangoproject.com/wiki/AppEngine

Mocking or Lack Thereof

The service code uses Pyfacebook and requests data from Facebook. I didn't want that code to run during unit tests largely because it wouldn't have the proper session keys. I briefly looked into mocking some of the Pyfacebook code for the unit test but without success at first pass. I cheated using a settings flag so that code wouldn't be run during unit tests to just get the features done for now. I hope to properly learn mocking in Python in the future.

Facebook Session Keys and AMF

From my understanding normally HTTP requests from a Facebook application would contain a bunch of Facebook data such as session keys. With AMF service calls, those HTTP requests do not have that data so the facebook object that the Pyfacebook middleware creates doesn't have some values set such as the session key. And that session key is needed for some of the API calls I was using. I ended up not using the middleware according to this post, manually created the facebook object, and manually set the session key which I parsed out from authentication data sent to the service methods. The authentication data was based on the Facebook fb:swf notes which allows you to verify that the swf was loaded from your Facebook app.

Facebook One-line Story Publishing

I was very confused about how my application should post messages (stories) to Facebook users' walls and the permissions it required. For now I wanted to avoid explicitly asking for elaborate permissions. Posting one-line stories  seemed like it didn't require the "publish_stream" extended permission. I ended up making sure the user was logged in, that the app was added to the user, and using the feed.publishUserAction API. I didn't use the recommended stream.publish API because it appeared to only publish "short stories" which required extended permissions.

Conclusions

I loved using Python and Django. I found Python to be a very friendly yet powerful language and Django to be a very efficient yet powerful framework. It let me quickly build up a tested AMF service layer. I'm very curious about the future of Django in commercial projects.

I think using Google App Engine, Django, and Flex is a great way to quickly build scalable Facebook applications. You definitely have to get used to programming for App Engine though. If you're not afraid to commit to coding specifically for App Engine then it seems like a great solution. I think development speed and scalability are key aspects in social media application development. This combination of technologies seems to address those aspects very well.