I recently started writing about my experience in porting Tongits (a game running on Adobe AIR) to the iPhone. So far I’ve already written two introductory posts. I’ll be regularly posting technical articles and tutorials specific to iPhone game development as I progress with the project. For those interested in how I will be pulling this off you can visit iTongits and subscribe to the feed.

I had to blog this since we encountered this issue twice already. I found the solution from BetaDesigns but we encountered a slightly different case the 2nd time that requires a different approach.

In the first case, you just need to delete a line from the mm.cfg file. If you’re using Windows XP, you’ll find the file in the C:\Documents and Settings\{your user name}\ folder. Find the line that contains the string ProfilerAgent.swf and delete it.

Different Approach

In the second case, you might not find that line from the mm.cfg file. So what we did was delete or rename the ProfilerAgent.swf file from the .metadata\.plugins\com.adobe.flash.profiler folder in your workspace.

Hope this helps.

It has been a great experience so far working with PureMVC. There was quite a huge barrier for entry due to its steeper learning curve but after gaining enough practical knowledge of the framework, my team was able to quickly implement most of the UI related logic and some business logic requirements of our project while maintaining integrity of the code. Now the only thing left to do is to connect the application to the data in the backend.

In this post, I would like to discuss the general flow of an application built on top of PureMVC. This is how we understood the framework and it’s the approach we used for our application. The flow is actually pretty simple and straightforward, even obvious. We used the Multicore version of PureMVC but this discussion will focus on the Standard version.

The View

This part of your application contains the MXML components, Mediators, custom events, and maybe some Interfaces.

Ideally, you should create a separate Flex Library project for all your MXML components. In this way your UI guy can easily take ownership of that area of your project. He does not need to share any code from the other developers, he just needs to focus on one separate and independent area of the application. He practically just needs to checkout a separate folder made especially for him only.

These MXML components do not know nor care about PureMVC or any other architecture that you may have in your project. Their only concern is the user interface. They take care of input from the user by dispatching appropriate events. They also expose a minimal set of API that allows interested parties (the Mediator in PureMVC’s case) to manipulate the user interface.

One example of this API exposure is an “update” function exposed by a custom tab navigation component that requires extra UI-only processing such as transition effects, alpha, hiding, disabling etc. These extra UI related processing or logic is encapsulated inside the component’s exposed “update” function. You may also even go as far as define a standard Interface for all related MXML components to implement to make it even easier and more intuitive for interested parties to access their API.

The Mediator is the entity that connects the MXML view components to PureMVC. It has a direct reference to one or more of your MXML components. If you are expecting that one of your Mediators will be taking care of more than one MXML component, it’s good practice to standardize access to these components via a common Interface. However, this does not mean you only have to register the Mediator once, you still have to register the Mediator for each MXML component it is interested in.

The heart of PureMVC is its Notification system and a large chunk of that can be found inside Mediators. From the name itself, the Mediator “mediates” the flow of data and acts as a middle man between the View and the rest of the application. The way it does this “mediating” is through Notifications.

The Mediator listens to events dispatched by the MXML components and forwards this to the rest of the application using Notifications. Commands mapped to the Notifications will be triggered. The Commands may then perform business logic related processing such as comparing values and deciding based on those values. This will in turn update the appropriate Proxy or more succinctly, update the application’s data.

The Mediator also handles Notifications it is interested in especially those coming from the Proxy. Since the Proxy takes care of the application’s data, any change to it should also reflect on the UI. This UI update process is also accomplished through Notifications. We will discuss details of the Proxy and it’s role in the program’s flow in another post.

You can also directly access Proxies (Model) from the Mediator but I do not recommend this approach since this will tightly couple your Mediators to your Proxies. I suggest you limit the Mediator’s role to sending and handling Notifications and just leave Proxies to your Commands (Controller). We will discuss this relationship (Mediator <-> Command <-> Proxy) in detail in a later post.

Summary

Although I tried putting in everything I know so far about the framework, I’m sure I still missed a lot of essential stuff. Working with PureMVC entails continuous learning anyway so I’m sure we will be discovering more interesting things along the way.

I was planning to discuss all the aspects involved in the flow (the Model & the Controller) in this post but decided to split them into parts seeing that this post has become this long already.

So much good stuff to discuss, think in PureMVC!

If you’re working with Subversion (and you should), you probably noticed the .svn folders in Flex Builder’s Navigator pane. It doesn’t really bother me that much seeing those folders in there but I wondered if they can be hidden to make the source tree a bit cleaner. It turned out that it’s just as simple as activating a filter for the Navigator pane. Simply select the .* filter from the Navigator menu according to this thread.

After installing FF3 a few weeks ago I found myself unable to debug my Flex projects using it. I resorted to using IE as my main debug browser. This worked fine at first but I still really needed to debug in FF3. So today I tried looking for a possible solution and came accross this bug. In a nutshell, the bug is about incompatible add-ons in FF3 that prevents the Flex debugger from running.

For my browser it was Google Toolbar that’s causing the problem, uninstalling it allowed me to debug again. Good thing it wasn’t Charles or TwitterFox.

I’ve been trying to play around with the PureMVC framework during the past few weeks and I would like to post my thoughts on the subject. This will serve as my reference later on and may also be of help to others who are interested to learn the framework. One obvious thing I should point out is that the learning curve for PureMVC is quite steep. Familiarity with the concept of design patterns is a requisite to be able to understand the framwork.

Notifications are similar to Flex Events. This may seem like a duplication of function at first but as you gain more understanding of this concept, you’ll learn to appreciate its purpose. Also a major reason why notifications exist is the language and framework agnostic nature of PureMVC. This approach made it possible for PureMVC to be ported to other languages or frameworks, not just Flex or AS3.

I’ll now proceed with the discussion of the major components of PureMVC and how they behave in relation to Notifications. I recommend going through the Minimalist MVC Example first to gain an understanding of the components that I will be discussing.

Facade. The Facade sends only one Notification, the initialization event called startup by convention. It doesn’t listen to any other Notification. The Facade is also responsible for assigning or registering a Command with a Notification.

Command. The Command only takes care of one Notification, the one assigned to it by the Facade. The Command is automatically invoked, or more specifically its execute method is invoked, whenever the Notification assigned to it is sent or triggered. In the execute method, you gain a handle to a Proxy via the Facade to retrieve, store, or manipulate data. The Command may also send a Notification to trigger an update in the user interface via the Mediator.

Proxy. The Proxy cannot listen to Notifications. It however may also send a Notification that will trigger an update in the user interface. The Proxy takes care of retreiving and storing data and announcing these changes to interested UIs via Notifications. The Mediator listens to these Notifications and is the one responsible for updating the UI.

Mediator. The Mediator is the only one allowed to listen to Notifications. It may also send a Notification that will trigger a Command and in turn cause an update to the application’s data via the Proxy. After the data has been updated, the Proxy may then send an update Notification that the Mediator can try to listen to and react to by updating the UI. The Mediator is also responsible for listening to native Flex events dispatched by the UI. Usually the Mediator reacts to these events by sending related Notifications, this is often referred to as “translating” from a native Flex Event to a PureMVC Notification.

So far this is how I understood PureMVC’s Notification system. Feel free to point out any mistakes or inconsistencies in the post. I will be using PureMVC in all upcoming projects and will be sharing my experience and learnings through this blog.

I just found out that my recipe, How do you display swf objects as items in a Menu using an item renderer?, was included in the recently released O’Reilly book, Flex 3 Cookbook. You can view a sample of the recipe here. It’s in Chapter 7 with a title of Display SWF Objects as Items in a Menu by Using an Item Renderer.

I wonder if the contributors will receive a complimentary copy of the book…

I also would like to apologize for the lack of updates recently. I have been very busy with studying PureMVC and with my new job. This means most of the articles that I will be publishing from now on will be related to this framework.

One of the many things I learned from my development experience with Tongits is that the CHILD_REMOVE event of the ChildExistenceChangedEvent object actually happens just when a child is about to be removed and not after the child was removed. This means numChildren is still the same inside a CHILD_REMOVE event listener. On the other hand, the CHILD_ADD event happens after the child has been added to the display list.

This is a small experiment on simple ball physics and collision detection wrapped in a frustratingly difficult game. You have to successfully shoot a ball to progress to the next level. The arrow simply rotates by 1 degree on each level. If you successfully complete all 51 levels you’ll be able to play the game in “free play” mode where you can control the direction of the arrow with the mouse. If you manage to finish the game please do tell us about your accuracy rating and how many minutes it took you to win the game. It took me about 15 minutes to finish the game with a very low 24% accuracy. I think this kind of gameplay coupled with a nicer reward system plus better graphics has potential to be a nice little flash game.

Play Thrower

Source Code 

I had some free time this week so I tried to make a Tetris clone. It is a complete game in under 600 lines of pure AS3 code. It mainly uses 2 dimensional arrays to represent masks for the bricks and to make collision detection easier. The output is simply a bitmap data filled onto a shape object and then scaled to a more comfortable zoom level. I did not refer to available algorithms online, I tried figuring them out by myself so you might find them to not be the most efficient.

Just add some sound, fancy graphics and high score submission and this could be a nice little online game though TTC won’t be too happy about that. I named the game TINT for Tint Is Not Tetris.

Play TINT

Source Code

Disclaimer: This is purely for educational purposes only.