With Adobe’s announcement last week at Adobe MAX that they have added export to iPhone in an alpha version of Flash CS 5, there has obviously been a lot of discussion about this.

There are various strands of discussion, however the strand that interests myself is that of whether Apple will actually allow this.

Some background…

Apple have from the start had a very closed environment for developing iPhone applications.
Amongst many things:

• Developers must sign-up (and pay) for the privilege of being able to publish to the iPhone.
• Developers must use only documented API’s from the Cocoa API.
• Developers must not publish anything that can load in other code (eg a runtime such as the Flash Player, and this point has been the most problematic to Adobe).
• The only way to get an application onto the iPhone is by submitting it to Apple who check it conforms to all their rules before it goes onto the app store (which is the only way to distribute iPhone applications).

One of the reasons for this closed environment is so that 3rd party applications all look and work in a similar fashion, are all stable and wont interfere with other aspects of the iPhone.

The obvious problem for Adobe is that this means they cannot get the Flash Player onto the iPhone and Apple have not bowed down to the sometimes very public pressure Adobe have been putting on them to put/allow the Flash Player on the iPhone.

So what Adobe have done is found a way to allow its users to output native iPhone applications from the Flash IDE – therefore not requiring the actual Flash Player.
However, and importantly, these output applications are not Objective-C Cocoa Touch applications.
There is also as yet no information whatsoever from Apple as to whether this technique of bypassing the runtime is to be endorsed.

This last point is very important. Apple has historically been very tough when it comes to getting applications through their approval process. They have created an environment whereby they retain a very tight control of the applications that get onto the devices. And while there would be no actual Flash runtime on the device, there would be an ecosystem of iPhone development that Apple had much less control of.

The two biggest concerns for Apple would be a) performance and b) lack of look and feel.
Regarding performance, obviously to a large degree this comes down to the developer. But if the byte-code Flash spits out is of poor quality, then its down to the tooling (Adobe).
Regarding look and feel, this again in largely down to the developer, however Adobe is working on a mobile version of the Flex framework (codenamed Slider) and it would be highly likely many iPhone apps would make use of this and therefore not look and feel like iPhone apps but look and feel like Flash apps. And from a user experience perspective, this is very bad for Apple. Apple have always been keen advocates of precise and consistent user experience, as always reflected in their Human Interface Guidelines.

So all said, do you really think Apple are going to quietly let this happen?

I really hope Adobe are doing this with the full support from Apple. If this is the case, we have some great things to look forward to from Adobe. If not, well, just a flash in the pan.

Over the last couple of days I have been busy porting the popular Cairngorm framework into JavaFX and have just uploaded the source into a fresh Google Code project: Cairngorm-FX

http://code.google.com/p/cairngorm-fx/

At CJT we have been very busy with JavaFX and are very excited about the technology. We also happen to use Cairngorm extensively in our Flex based projects as it really helps keep code structured/organized and when working in a team, is a real time saver (aside from coding in a reusable and scaleable way of course).

So a port of Cairngorm to JavaFX was pretty obviously going to be very useful to us! And as it will probably be useful to loads of other developers, we thought we would open-source it (under the MIT License).

Anyone who has done a lot of skinning in Flex will know the simplest, quickest and most effective way is to use a PNG with a scale 9 grid (via the Embed directive).

As an example, applied in CSS:

Button
{
    downSkin: Embed(source="/assets/skin_button_pressed.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
    overSkin: Embed(source="/assets/skin_button_hover.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
    upSkin: Embed(source="/assets/skin_button_normal.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
}

So we get passed a PSD from one of the designers, export the PNG’s, then using an on-screen ruler or the guides in Gimp, work out what the scale grid parameters need to be. And its this last step that is just a bore.

So while toying around with JavaFX 1.2, I knocked together a little application which allows us to simply load a PNG, drag four guides to mark the scale grid, then click a button to copy an Embed tag with correct scale grid values to the system clipboard ready to paste into the code.

I know all of us at CJT will be using this little gem of a time-saver, so for anyone else who fancies using it too, I have packaged it up as a Java Web Start application.

Install and launch here:

In my previous post, I described how the architectural frameworks that have sprung up for flex/actionscript developers are not the best thing since sliced bread for implementing well designed applications.

They attempt to take the design pattern, MVC, along with some other design patterns and bring them all together into one monolithic architectural framework.

However, you do not need to use these frameworks to program using the MVC pattern or indeed any of the other patterns used in these frameworks.

So for those developers who understand the various design patterns already, and are opting not to use these architectural frameworks, I present something I feel rather useful in terms of actionscript and the MVC pattern inparticular.

As you will already be aware, in the MVC pattern, you ideally want the actors (the Model, the View and the Controller) highly decoupled.
Therefore its common to see the coupling achieved via notifications (the observer pattern AKA publish-subscribe) or some other kind of eventing.
In actionscript 3, its a very common practice to make use of events, as the event model (an implementation of the W3C DOM event model) is built in.
However, the bubbling and capture phases of the event flow only work when the dispatchers are part of the display list. This means events can only flow when the dispatcher is a view element.
Therefore anywhere else, you need to tightly couple to the dispatcher in order to receive events from it. Not ideal.

This brings me onto the Objective-C/C++ NSNotificationCenter found in Apple’s Cocoa API (and of course the GNUstep framework).
This a very elegant, lightweight, fast and easy to use class.
The usage is simple…

1. Any object which wishes to send a notification, can easily send one via the NSNotificationCenter’s postNotification method (or its variations).
2. Any object wishing to observe notifications can observe via NSNotificationCenter’s addObserver method.

The most useful part of this is that the observer can choose to listen for specifically named notifications, specific senders of notifications, both by name and sender or listen for *all* notifications regardless of name or sender.
It is up to the developer what level of coupling to use.

Users of the NSNotificationCenter most commonly make you of a static instance retrieved via NSNotificationCenter’s defaultCenter class method, though of course a more compartmented usage can be achieved via instantiating multiple NSNotificationCenter’s. One such usage could be a more modular application whereby a module wishes to have certain module private notifications, yet also publish and subscribe to the rest of the application.

Actual notifications can either be NSNotification instances or instances of sub-classes of NSNotification.
By creating sub-classes, you achieve a stricter interface, though as you see in Cocoa, this is an uncommon practice.

I am sure anyone already familiar with these classes will understand, they can be very useful indeed.
As such, I have ported NSNotificationCenter (and as such also NSNotification), into actionscript 3 (and also into C/C++ while I was at it) for all to use.

Full source code including example/test applications for download here.

Update: Download link now also contains JavaFX version as well.

Flash/flex developers have been bombarded by so called MVC frameworks (I say ‘so called’ because they are not really MVC frameworks, but rather a collection of design patterns, including the MVC pattern).

This is partly to do with the evolution of actionscript, from something very rudimentary, simply to help add some interactivity to animations, to procedural, to semi-object orientated and then finally to the fully object orientated language it is today.

It is also partly to do with the fact that actionscript has mostly been used by designers, not developers, and hence many designers have become developers in-line with actionscript’s growth.

So why have all these architectural frameworks been raining on the actionscript community? No other language attracts this kind of attention. Its not because actionscript is better than other languages or because its in greater need for these kinds of frameworks than any other language.

For the most part, other OOP languages are largely used by developers who already understand the principals of OOP and design patterns.
There is no need to develop an MVC framework for developers to use – MVC is a design pattern.
Developers make use of design patterns to create object orientated solutions to common problems in software design. This does not mean the liberal application of every design pattern ever conceived to every project you work on, but use them where they solve a problem, where they make sense.

I guess this is my biggest point against frameworks like PuveMVC and Cairngorm.
By attempting to create a basis for good software design, they can actually fail by creating over-designed, or even badly designed, applications by failing to recognise an applications specific domain needs, requirements and problems.

There are positive benefits of these architectural frameworks too however (if used where appropriate).
Firstly they enforce development teams to work to the same prescribed architecture.
This mostly benefits teams with some novices in the wings. They need not understand why the patterns are used, or how the framework implements it, they just read the documentation and the tutorials of the framework and off they go.
Secondly, and due to the first point, it makes it easier to hire people (and I am speaking specifically for flex/actionscript developers). If they have a working experience of one of these frameworks, it makes it less risky for the employer. There are plenty of very inexperienced actionscript developers out there (due to the evolution of actionscript and its community).
Therefore, with a mixture of well skilled and not so well skilled developers, these frameworks really help bridge the gap.

So, lets say you already have highly skilled developers.
There can be good cases to not use these architectural frameworks for some, even several, applications.
In this scenario, your team will author code that makes use of the correct design patterns as and where needed.

My next post will introduce what should be a highly useful class to actionscript developers not using one of these architectural frameworks.