Skip to content
April 1, 2014 / Daniel Freeman

RE: Gary’s letter. Chris’s Response. AIR vs PhoneGap, etc.


The following essay is prompted by Gary Paluk’s Open Letter to Adobe, and Chris Campbell’s response.  I wanted to elaborate on some technical insights to Adobe AIR vs. PhoneGap, and the severe limitations of PhoneGap.  In particular, for Enterprise and General Purpose apps.  I also wanted to talk about the Adobe AIR and Flash Platform communities.  How the de-emphasis of Flash has affected the community, and disenfranchised customers.


The AIR Community

I was very proud of the AIR community last week.  They may have soured an unfortunately-worded Adobe announcement with their discontent – but their solidarity, and support of AIR was admirable.  In their announcement, Adobe describe their new PhoneGap toolset as “Adobe’s lead­ing cross-platform app devel­op­ment solution.”  It’s no wonder that AIR developers were upset.

To many, this seemed like the final straw from Adobe, who seem to have already truncated the roadmap, neglected the Flash Platform community, failed to communicate the virtues of AIR, and effectively gagged and silenced the Flash Platform evangelists.  The ACPs, like myself try to keep the flame alive, while Adobe itself remains mostly silent about the Flash Platform and its continued success.

It is not unwise of Adobe to focus on HTML5 toolsets.  Although, the challenge will be to stay ahead of free open-source offerings.  Making a success around open HTML5 technologies is going to be a lot harder for Adobe than it was for them to build successful products around their own proprietary Flash Platform technologies.  If I seem dubious about their ability to succeed – it is because new Adobe seems to have lost much of its surrogate Macromedia DNA now.  I just see corporate grey, public relations whitewash, and bland beige bean-counters.

In response to Gary Paluk’s open letterLuca Mezzalira explained Adobe’s financial motivation.  But why do Adobe’s HTML5 ambitions have to be mutually exclusive to AIR evangelism and support?  When Adobe shifted their focus from the Flash Platform to HTML5 – it was like flipping a switch.  The Flash Platform Community was a tremendous asset.  Adobe’s destruction of that asset makes no sense.  Many disenfranchised customers may never trust Adobe again.  Great news for Unity3D, Ancsa Corona, Titanium, Sencha, and Open Source alternatives.  I wonder if it’s possible to a price on the destruction of the Flash Platform community?  Suppose we could calculate that, and put it under the noses of the myopic accountants steering the good ship Adobe – I wonder if they’d change direction?

I watched an interview with Shantanu Narayen where he talked about the de-emphasis of Flash in favour of web standards (6:00). When asked about Flash on an iPad (7:00) – this was a perfect opening to talk about AIR, and apps – but AIR was never mentioned.  This interview is even worse: “With products like PhoneGap, we want to enable people to build great apps, whether they be HTML or native apps, for the iOS platforms.” …. really?


Those disenfranchised ex-customers

I was in Thailand at the end of last year, and I offered to give a presentation to a Bangkok Web Meetup Group.  I joined their Facebook Group, and I saw a discussion related to WebGL, and I responded to a comment that was pertinent to Stage3D.  I might as well have lit a fire under a hornet’s nest.  These guys turned on me, and flamed me, made me out to be some kind of idiot, and hurled personal abuse – before I left their group in disgust.  There was no point.  Most of my technical arguments were way over their heads anyway.  Tough crowd.  I changed my mind about giving a presentation.

The attack came mostly from Caucasian developers, not Thai, who identified themselves as former Flash and AIR guys.  Disenfranchised with Adobe, and its technologies.  The web designers had switched to HTML5 and the app developers had switched to Unity3D.  There was a lot of hate.


The Power of AIR

Overall, HTML5 never superseded the Flash Platform on technical merit.  It just got adequate for making banner ads and rich experiences on the web, so it stole those markets.  The challenge for Adobe then was to develop the capabilities of the Flash Platform into new markets where HTML5 would flounder.  One important and underexploited market is where you raise the bar on the sophistication of mobile/web apps.  Like Adobe’s own Photoshop Touch app.  Did you realise that this was built using Adobe AIR?  I don’t know why Adobe are so restrained telling people what AIR can do?  I don’t believe the conspiracy theories that claim a sinister collusion with Apple.  But I can see that conspiracy theories are more comforting than blaming it on the incompetence of Adobe’s marketing machine.

I’ve always been fascinated in the ability of AIR to raise the bar on the sophistication of apps.  I built a spreadsheet, illustration, and sophisticated publishing app using AIR on the desktop.  It was my intention to port these to tablet devices – but I got busy with other projects.  ( They’re not available for download anymore – but I’ve got some videos on my youtube channel. ).  The publishing app, e2publish, in particular, leveraged the capabilities of Adobe’s TLF Framework.  HTML5 text layout doesn’t even begin to approach what TLF can do.



HTML5 on mobile is buggy, fragmented across OS versions, and performs badly.  While both Apple and Google pay lip-service to HTML5, neither want to compromise their app walled-garden.  The iOS performance of hybrid apps is worse than web apps.  Facebook, LinkedIn, and other companies abandoned hybrid HTML5 apps.  This is essentially the same approach as PhoneGap.

So when the AIR developers gate-crashed Adobe’s party, they weren’t being AIR purists, narrow-minded xenophobes, or fan boys.  They were highlighting a valid technical comparison.  That Adobe AIR is generally much more capable than PhoneGap.  Most of these guys have kept abreast of HTML5 advances, and many know PhoneGap too – warts ‘n all.  Ironically, I’m teaching a five day HTML5 and PhoneGap course to corporate clients the week after next.

PhoneGap essentially makes a mobile app out of web pages.  That sounds easy, doesn’t it?  But once you scratch beneath the surface it involves mastery of a whole load of frameworks and tricks.  Once you get deeply into it, you’ll find yourself missing the simplicity and speed of AIR development.

PhoneGap can incorporate mobile-styled HTML5 forms – does this mean that it’s great for enterprise and general purpose apps?  Not really.  PhoneGap has its niche – but it does not scale up well to sophisticated projects. A lot of developers have got their fingers burnt battling with and performance issues and workarounds with PhoneGap / Hybrid HTML5 apps.  I’ve seen it described as “Build Once – Optimise Everywhere!”.  If you succeed getting your app working, then maybe your project will take many times longer than what it would have taken if you’d used AIR.  If you fail (and I’ve heard accounts from many developers where this has happened), then you waste time and money.

So what is PhoneGap good for?  PhoneGap is good at simple thin-client apps, or HTML5 document-based apps such as WikiPedia, or Cross Platform apps deployed to many target platforms (iOS, Android, Blackberry, Widows 7 and 8, WebOS, Symbian, and Bada).

A while ago, I started a discussion on LinkedIn regarding Hybrid HTML5 (PhoneGap), vs. Native, vs. other Cross-Platform approaches.  It makes interesting reading.  Here are some of comments that developers made about HTML5/Hybrid/PhoneGap apps:-

“I spent 9 months… tweaking a html5 app and I pushed the limits of html5 on mobile… We had to go native… html failed.”

“The argument that it is faster and easier to develop a non-trivial app in HTML5 is total nonsense”

“In XCode using Objective-C I’m a pretty happy camper. My HTML5 days are much less pleasant”

“Building a complicated mobile application in HTML5 has been hard”

“The cost of doing HTML5 UI development is greater …. beyond a moderate level of complexity”


asm.js, Enscripten, and

Obviously, asm.js, Enscipten, and are exciting developments that are worth watching.  But do they solve the problems of mobile hybrid and web apps?  I doubt it.  There’s no point of compiling to asm.js to run inside a mobile hybrid web wrapper.  If we’re going to get into Cross-Compilers, then use OpenFL (Haxe NME) to build a real native app.  If ASNext isn’t going to happen, and clearly PhoneGap will fail, then Adobe should at least invest in OpenFL.

Suppose there is a significant improvement using on mobile?  Enough to become a threat to Apple and Google’s app walled garden.  Are they just going to allow that?  When AIR for iOS was first released in 2010, Apple changed their developer agreement to ban it from iOS.  The embargo lasted six months.  The proposed Cordova enhancement relies on a modified version of Webkit.  Not the standard iOS version.  Would Apple allow that?

(btw, I found this detailed article, that goes into a lot of depth about JavaScript and web app performance on mobile)


AIR 2D and UI Frameworks

Adobe AIR is really good at building Enterprise and General Purpose Apps.  The problem is that Adobe has never backed the right UI framework.  The Mobile Flex Framework was slow, bloated, and its inadequacy did a lot to destroy people’s perception about the power of Adobe AIR on mobile devices.  Flex made AIR look like a joke on mobile, and it initiated the exodus of developers looking for alternative frameworks.  The lucky ones found MadComponents, and stayed with the Flash Platform and AS3.  Others abandoned Adobe technologies and went over to the competition.  The mobile side of Flex hasn’t improved under the Apache group – and Flex remains the worst option on mobile.  Feathers is a great option provided that your project is built using Starling.  So it is more appropriate for menus and controls for 2D games.  But again, Adobe backed the wrong framework with Starling.  Genome2D and ND2D(x)  were always much more capable candidates, that demonstrate the impressive power of Flash Platform more definitively.

Call me biased, but MadComponents is still the best UI framework for AIR General Purpose and Enterprise apps.  The next release will include better tab pages, better scrolling responsiveness for lists with custom renderers, and even more powerful datagrid capabilities.  There’s a video introduction to MadComponents here.  I’ve always wanted to build a drag-and-drop UI Builder app for MadComponents.  But unlike Feathers, MadComponents is not supported by Adobe, and I can only do so much with no funding.  But considering that it has evolved slowly, whenever I’ve had the time – it is pretty impressive.

My App

Most of last year, I spent developing a very sophisticated AIR app that peaked at #4 in its iTunes category.  I don’t want to say too much about it now.  Later in the year, I’ll make updates that will attract a wider release, and I’ll make public announcements when the time comes.

I used Adobe AIR – because it is so powerful, versatile, Cross-Platform, and it scales-up very well to sophistication. I did seriously consider other options.  Xaramin, and OpenFL (Haxe MNE).  But AIR allowed me to utilise MadComponents – and this was a huge bonus in favour of AIR.  It allowed me to incorporate powerful datagrids and novel UI elements.

In the future, both MadComponents, and my app may be ported to OpenFL.  But right now, Adobe AIR is still very much alive and kicking, despite any speculation to the contrary.

Actually, before I got involved with this project, another developer had attempted to implement the app using PhoneGap. Given the sophisticated nature of the app, I’m not surprised that they failed.  PhoneGap was a naive choice that wasted time and money.


Chris Cambell’s Response

I was impressed by how quickly Adobe responded to Gary’s letter.  Chris describes himself as a “customer advocate” for the Flash Runtime product team.  I don’t think we have evangelists anymore.  I wonder how much sway this advocacy has inside Adobe, outside of the marginalised Flash team.

Personally, I’m not unhappy about the updates to AIR.  But I think they need to give us Windows 8 support soon.  Vote on that feature request here.  Also, Android x86 support.  Vote on that here.

Chris mentions “video and gaming” several times in his text.  And every mention of this grates on my nerves.  Adobe AIR is a versatile and powerful technology.  It’s not PhoneGap.  If you build an enterprise app, beyond a moderate level of complexity, you run a higher risk of failure if you use PhoneGap, than if you use Adobe AIR.  The AIR development time will likely be shorter anyway.  YES – AIR is great at Gaming and Video – but it is great at a lot of other things too.

The decision to compartmentalised AIR into Gaming and Video, and PhoneGap into Enterprise, was likely made by some technologically naive Adobe accountant at a board meeting.  It’s a decision that doesn’t stand up to an experienced developer’s objective technical scrutiny.  It was a dumb decision that will backfire – the same as hybrid HTML5 backfired for Facebook and LinkedIn.

If you tweet this – please use the hashtag:  #ListenToYourCommunity )

March 26, 2014 / Daniel Freeman

Gary Paluk’s Open Letter to Adobe

Open letter to @Adobe & Adobe AIR.  (Link to original source)

Please share, re-post, circulate, blog, twitter, link-to, like – and forward to Adobe representatives.

(Twitter: #ListenToYourCommunity )


Hi Loni, firstly, thank you for your response to questions. I was a developer of the Away3D TypeScript HTML5 project which was funded by Adobe. I wrote my own Flash/Air 3D engine called Zest3D which had no funding from Adobe, so I’m in quite a good position to comment given my experience with the technologies being discussed.

The comments here illustrate just how concerned developers are, developers that have invested in Adobe technology over the years. I have invested 13 years of my own development career in Adobe products and evangelized the technology over that time. Your users can see that there is a perfectly good technology that does more than the new HTML5 offerings and they are evidently frustrated that you are not supporting developers that do not see why they aught to retrain to use an inferior technology.

Whilst I understand business choices are being made to support HTML5, Adobe should understand developers will leave rather than use inferior technology. I, for one, would resent moving to your HTML5 technology and every highly skilled developer that I have spoken to has said the same. You can see that in the comments already received.

Many of those developers feel that Adobes evangelist attitude to HTML5 is misplaced and a PR/market bending directive that is damaging their livelihoods and the skill-sets that they have accumulated and as most people would understand, developers and artists want to use the best products and workflows to get a job complete. In this case, the best product is Adobe Air and certainly not PhoneGap. So why do we keep seeing Adobe pushing the technologies that the developers do not want?

I would like to take the opportunity to ask Adobe to speak out and offer their support to existing developers with serious PR and coverage and continued accelerated roadmap for the Adobe Flash and Air product before all your best developers leave and take their years of development and programming skills with them. Adobe has seen this already as developers have sought to find other native solutions, Unitiy has become the entry level tool of choice and companies like myself and Minko are essentially planning or working on building superior tools that may soon make Air obsolete whilst supporting native and HTML5 development without the need for an Adobe toolchain. This is the effect of alienating your development community will lead to loss of sales of your supporting tools.

Personally, I do not want to see Adobe Air or Adobe Flash disappear as they both have a formidable user base, excellent workflow, perfect cross-platform capability. With a small amount of investment, I feel that Flash and Air could be a much superior technology and with this approach Adobe might regain the trust of their developer community whilst continuing to enrich the lives of those developers who have continued to champion Adobes history of excellent web technologies.

Gary Paluk


AIR Developers – if you care about AIR, please share Gary Paluk’s open letter. Please share it (Facebook, G+, etc..). reblog it, circulate it, twitter about it using the hashtag #ListenToYourCommunity , or simply re-tweet Gary’s tweet,

And please forward a copy of the open letter to your favourite Adobe representative.

September 25, 2013 / Daniel Freeman

8-Bit Nostalgia

About 30 years ago, I had some computer programs published in popular UK computer magazines of the time.  Simple graphics experiments that I’d written while still at school.  Time has passed, and I’d lost any record that I had – apart from my vague recollections.  But this summer, I was visiting the UK, so I decided to dig up my past in the British Library, and indulge in a little microcomputer nostalgia.


I had to wade through several thick bound volumes from the archives before I struck gold.  Glossy-page recollections of a very different technological time.  8-bit microcomputers.  Most were slow, black-and-white, with blocky lo-res graphics and no sound.  But with these humble and primitive beginnings – the consumer Home Microcomputer boom took off in the UK, just before it took off in America.

In the hours that I spend flicking through the archived magazines – I found the two wireframe graphics programs that I remembered.  Both written on the school RML 380Z.  And a machine code utility, (which I don’t remember), but obviously written on my friend’s Sharp MZ-80K.  The final program, I lifted from a digital online archive.  It had been written on my own Sinclair ZX81 – the first computer I owned.  I’d worked a summer job in a green-grocers to afford it.  It had 16Kbytes Ram, a “real” keyboard, built from a Maplin kit, and a DK-Tronics ROM with extra character sets.  Programs were stored on cassette tape.


All my published programs were written in BASIC.  Some have Z80 code thrown-in.  In those days, I could write Z80 machine code, straight from my head, directly in Hex.

It might be cool if anyone’s up to the challenge of re-writing the old 380Z BASIC code using contemporary Stage3D or WebGL instead.  Any takers?

Screen shot 2013-09-25 at 22.27.20

Here are the full published listings of the two wireframe graphics programs.  graph3d (Practical Computing. September 1983. Pages 154 and 157). and plotting (Practical Computing. March 1984. Page 172).

The final two programs are hybrid BASIC + Z80 code for manipulating the memory-mapped display in weird and wonderful ways.  Likely not relevant to the way things work nowadays – but nostalgic nevertheless.  Here’s the listing for the ZX81(Sinclair Programs May 1983 page 20):-
And here is the program for the Sharp MZ-80K are here: MZ80K1 and here: MZ80K2.  (Personal Computer World. Pages 265 and 266).

Sharp MZ80K

If you’re reading this – and you also remember those days with fond nostalgia – feel free to leave a comment below.

September 11, 2013 / Daniel Freeman

New MadComponents DataGrids

MadComponent128exThe latest release of MadComponents incorporates four new datagrid components.  UIFastDataGrid, UIScrollDataGrid, UIScrollDataGrids, and UITouchDataGrids.

MadComponents is still primarily for mobile application UIs – although you can also use it to build desktop and browser apps.  So the new datagrids components are specifically designed primarily for mobile screens.  They’ve been engineered and refined to run on mobile devices, with specific attention to detail in areas of performance, viewable data, and interactivity.

Download MadComponents from here.

Screen shot 2013-09-07 at 22.42.58


This component is similar to the existing UIDataGrid component, but with additional capabilities.  UIFastDataGrid is optimised for memory usage, and it recycles cells so that rewriting the grid is faster.

If you change the datagrid data, and the new data has a different number of rows and columns – a new render algorithm augments or removes the necessary rows and columns to the old grid.   (As opposed to clearing the datagrid, and then redrawing it).

It also incorporates methods for swapping, adding, and removing, grid rows – without the need to rewrite the entire grid.  This is faster.

There are also new public methods for swapping, inserting, and removing rows.  Common operations that would have necessitated redrawing the entire datagrid previously.

The column width calculation is “smart”.  If the width of all the columns is less than the width of the datagrid, then it will add padding to each column to make the datagrid fit exactly.  (Unless you have explicitly fixed each column width using the widths attribute).

Useful XML Attributes

widths = “i(%),j(%),k(%)‚…”  (similar to the <columns> component)
multiline = “true”  (allow text in cells to wrap around)
recycle = “true” (recycle cells – use old cells rather than instantiating new ones)recycle = “shared” (If you have several datagrids you can pool their recycled cells together)

Useful Methods

public function swapRows(rowIndexA:int, rowIndexB:int):void

public function insertRow(rowIndex:int, rowData:Array):void

public function deleteRow(rowIndex:int):void

Example Code

There’s some example code that incorporates a UIFastDataGrid here.


If you require a scrolling datagrid, you could just nest a UIFastDataGrid inside a scrolling container (UIScrollVertical , UIScrollHorizontal, or UIScrollXY).  For example:-

<scrollXY border=”false” width=”1000″ height=”1000″>
<fastDataGrid id=”datagrid” />

While that will allow you to scroll a datagrid that is larger than the screen size.  The column heading will scroll with the data.  It is better to keep the column headers visible at the top of the datagrid, regardless of which part of the data you’re viewing.  Also, scrolling datagrids, often allow you to fix one of more columns at the left of the datagrid.  These fixed columns never scroll out of view.

The new UIScrollDataGridComponent allows you to create a scrollable datagrid, while keeping column headings in view at the top of the datagrid, and fixed columns in view at the left of the datagrid.

slideFixedColumns = “true”

Fixed Columns are useful.  But on a very small screen, fixed columns leave very little actual scrolling area.  So the UIScrollDataGrid has a slideFixedColumns attribute.

If you declare this as true, then the fixed columns will slide out of the way temporarily when you scroll the datagrid left and right.  This allows you to view more columns while the grid is actually scrolling.  With up and down scrolling, the user is more likely to need to view fixed columns – so with up and down scrolling, they remain where they are.

Useful XML Attributes

fixedColumns = “n” (The number of leftmost fixed columns)
slideFixedColumns = “true” (employ fixed column sliding scheme)
lockSides = “true” (restrict scrolling left and right beyond limits)

Useful Methods

public function swapRows(rowIndexA:int, rowIndexB:int):void

public function insertRow(rowIndex:int, rowData:Array):void

public function deleteRow(rowIndex:int):void

Example Code

There’s some example code that incorporates a UIScrollDataGrid here.



This is a powerful component for stacking a collection of scrolling datagrids one on top of the other.  This is a container component, that you can nest around several <fastDataGrid> components like this:-

<scrollDataGrids id=”dataGrids” gapV=”0″>
   <fastDataGrid id=”dg0″/>
   <fastDataGrid id=”dg1″/>
   <fastDataGrid id=”dg2″/>

Just like a UScrollDataGrid component, the column headings remain visible at the top.    But as you scroll up and down, through different datagrids, the column headings are switched to correspond to the actual datagrid currently in view.
Useful XML Attributes

alignGridWidths = “true” (pad out the last column so that all datagrids are the same width)

Useful Methods

public function get dataGrids():Vector.<UIFastDataGrid>public function doLayout():void

Example Code

There’s some example code that incorporates UIScrollDataGrids here.


All of these new datagrid components have been designed for mobile devices.  You may have noticed that none of them allow the user to edit a cell.  The old UIDataGrid component allowed you to do this.  The user was able to tap on a cell, and type in a new value.  That capability has been dropped from the new components.  (But UIDataGrid is still there if you need it).  The reason I dropped it is because – on a small screen it’s just too fiddly to interact with a datagrid like that.  Especially with a small mobile screen and a clumsy finger.  The old desktop/mouse conventions just aren’t appropriate here.  The cells, and text is likely small – because we want to pack as much data as we can on a small screen.  While it is big enough to be legible, it’s not big enough to edit comfortably on a touch screen.

Hence, the app developer is encouraged to make mobile device editable datagrids in a different way.  Select a row, and click on an “edit” button, and this edit button can be linked to another page, or a pop-up form, where you can allow the user to edit datagrid fields.

UIScrollTouchGrids includes the ability to select a row, and it has an edit button.

edit button


Useful Events

UIScrollTouchGrids.EDIT_BUTTON_MOUSE_DOWN    (The edit button has been pressed, but this may not be a click)UIScrollTouchGrids.EDIT_BUTTON_MOUSE_UP   (The edit button has been clicked)

UIScrollTouchGrids.EDIT_BUTTON_LONG_CLICK  (The edit button has been long-clicked)

UIScrollTouchGrids.EDIT_BUTTON_LONG_CLICK_END  (The edit button long click has ended)

UIScrollTouchGrids.ROW_SELECTED  (A row has been selected)

UIScrollTouchGrids.HEADER_DOWN  (The top datagrid header has been pressed – but this may not be a click)

UIScrollTouchGrids.HEADER_CLICKED  (The top datagrid header has been clicked)

Note:  You’ll notice in the comments about, I’ve made the distinction between a touch and a click.  When the user touches a component – it might be initiating a CLICK action, or it might be the start of a different gesture.  For example, an edit button can be dragged as well as clicked.  So if you want to listen specifically for Click gestures, listen for CLICK or MOUSE_UP events, not DOWN events.

Example Code

There’s some example code that incorporates UIScrollTouchGrids here and here.

Join The Community

For community discussions about MadComponents/MC3D, come and join the facebook page:-

You may also be interested in the Stage3D Facebook group:

here’s an introductory video to MadComponents here:

Please blog about this project and help to spread the word. Also, don’t forget to leave a “star”, or “g + 1″ recommendation on the Google Code site.




September 7, 2013 / Daniel Freeman

New MadComponents Release!

MadComponent128exIt’s been a while since MadComponents was updated.  But in the meantime I’ve still been developing the framework.  Also, developer interest in the framework doesn’t seem to be subsiding anytime soon.

The new version of MadComponents and ExtendedMadness has greatly improved the behaviour of many components.  Also, I’ve introduced a number of new components into ExtendedMadness, with an special emphasis on data grids.

Download MadComponents from here.

Stage3D vs. Display List

While prevailing opinion favours Stage3D over the display list graphics – it all depends on the application.  Many developers assume that Stage3D is better and faster – but is it really better for general purpose User Interfaces?

MadComponents is based on the traditional display list.  Originally, I had intended to redevelop MadComponents and base it on Stage3D.  I intended to merge MC3D and MadComponents.  But after gaining a thorough understanding of Stage3D – I changed my mind.  I concluded that the Display List was the way to go, after all.  While MC3D demonstrated a few neat tricks, and impressive transitions – I wasn’t happy with what this cost in other respects.

The Stage3D approach lends itself naturally to Games – but the good old-fashioned Display List is better suited to building general purpose mobile UIs.

That is, unless your application uses Stage3D anyway.  If you’ve built your game in Starling, it makes sense to build your UI with Feathers.  Because Feathers and Starling interoperate better than Starling and MadComponents.

But assuming you’re not using Stage3D for anything else – why go for a Display List framework?

1. Ease and Speed of development are particular strengths of MadComponents.  For example, if you take a look at this Feather’s Tutorial   Now take a look at the equivalent MadComponents code.  (link).   MadComponents makes it all much simpler.   But MadComponents was designed specifically to do this kind of thing, and to make it easy.

I’m not saying the Feathers approach or the tutorial isn’t useful.  If you were building a lists and navigation for a Starling game – the approach described in the tutorial, and Feathers would be the way to go.

2. Image sharpness is another advantage of the display-list.  Stage3D textures aren’t appropriate for pixel-snapped sharp images.

3. MadComponents UIs are easily styled and coloured just by tweaking attribute values in the XML layout.  You can accomplish some striking and beautiful user interface designs – without any skinning.  (Although MadComponents supports skinning too).

4. You can easily combine MadComponents with legacy display-list code, Minimal Components, even Flex.  And it’s easy to add your own custom components.

5. MadComponents and ExtendedMadness contains about 80 different components.  Including exotic components such as Wheel Menus, Page Turn and Charts  That’s many more components than any Stage3D-based framework.

Screen shot 2013-03-06 at 17.23.51

6. While Stage3D is fast once it gets started – the set-up and upload times are still a bottleneck.  Especially when the textures are dynamically generated (not just static sprite sheets).  A sophisticated UI is either going to have a lot of textures to upload, or a lot of vertices, or both.  With Stage3D this will incur a significant set-up and upload delay.  But the Display List and GPU-rendermode won’t incur this.

Improvements to MadComponents

The new release of MadComponents introduces many refinements to existing components.  Lists, Switched and Sliders respond much better to touch events.  Sliding transitions and List Scrolling is smoother.  There are also some minor improvements to appearance.

There are a couple of enhancements to the way you to navigate to change the page.  There’s a new goToPageId method in UIPages, UINavigation, etc.

Rather than specifying a numeric index for the page, you can refer to a page by its id.  For example.


Also, if you have a button, and you want to switch page when the user clicks the button, you can use a new goTo attribute.  You don’t need to write any AS3.

<button goTo=”home_page” transition={UIPages.SLIDE_LEFT}>

Finally, you can use absolute positioning within a frame layout now.

     <button x=”100″ y=”200″/>
     <slider x=”200″ y=”300″/>

But be careful how you use it.  Don’t forget that Android screens come in many sizes – and elastic layouts are better.


Additions to ExtendedComponents

There are four new DataGrid components, specifically designed for viewing and interaction on mobile devices.   (UIFastDataGrid, UIScrollDataGrid, UIScrollDataGrids, and UITouchDataGrids.).  These will be discussed fully in the next post.

There are a few further additions too <labelShadow> for labels with a drop shadow.  <arrowButton> for buttons that have an up or down arrow symbol, and <textSlider> for sliding controls.  For example:  <textSlider>A B C D E</textSlider>



Finally, there’s a new container component called <screens>.  This is useful for developing layouts that might be arranged differently for different screen sizes and orientations.  For example, a screen might be laid out one way for small screens, a different layout for a larger screens, and possibly a different layout again for tablet devices.

You would build each layout like this:

<vertical size=”P320x220C”>
    layout here

Notice the size attribute.  The first letter is optional.  Either P for portrait or L for landscape.  Next, you specify the size of the layout.  (horizontal x vertical).  Finally, there’s and optional C character.  If you specify C then the layout will be centred on the screen.

Having declared several layouts for several screen sizes, you use the <screens> container like this:

<screens lazyRender=”true” recycle=”true”>

The screens container will dispatch a UIScreen.SCREEN_CHANGED when a layout is selected.  It you use the same components inside each layout (with the same ids) – then you should put all your findViewById()’s inside the UIScreen.SCREEN_CHANGED handler.

There’s a example for the new <screens> tag here.

Join The Community

For community discussions about MadComponents/MC3D, come and join the facebook page:-

You may also be interested in the Stage3D Facebook group:

There’s an introductory video to MadComponents here:

Please blog about this project and help to spread the word.
Also, don’t forget to leave a “star”, or “g + 1″ recommendation on the Google Code site.
June 2, 2013 / Daniel Freeman

Introduction to Stage3D and AGAL

Stage3D and AGAL

A while ago, I did a presentation for the Hawaii Flash User Group.

It was a free online event, and the theme was Stage3D.  Specifically, fundamental concepts of 3D graphics, AGAL, and how to utilise Stage3D without a 2D or 3D Framework.

The event was aimed at beginners with no prior background in 3D graphics. While the examples were built using ActionScript and Stage3D, the general concepts are applicable to OpenGL, WebGL, Direct-X, etc.

Screen shot 2013-05-08 at 18.27.24

I also presented some of my experiments on procedurally generated corridors and rooms.

Screen shot 2012-01-15 at 22.34.54Screen shot 2012-01-23 at 19.29.52

Gary Paluk is followed-on with a talk about how to build your own 3D engine from scratch.

Altogether, it was an exciting event – not least because I had trackpad and mouse problems – and half way through the presentation, my computer went haywire, and started launching random applications.

Recording, Slides, and Code Samples

If you missed it, don’t worry – everything was recorded, and you can download the sample files.

Here is the recorded session:

(I can’t bear to listen to this – I can’t stand the sound of my own recorded voice.)

My slides are here:

My code samples are here:

( Please “star” the code site, and recommend it on “g+”. )

Gary’s code samples are here:

and an example at:

My Other Open-Source Projects

This seems an opportune time to summarise my various Open-Source contributions.




Spriter Plug-In For Marmalade Quick:

e2Publish.  Powerful Flash-Based TLF word-processor…. Ok this isn’t open-source yet.  I’ve offered it to the Apache Flex Group, and they didn’t seem too interested.  I’ve toyed with the idea of converting it to Haxe, and releasing a Haxe version.  Although, right now, I don’t have the time to transition this substantial project to open source, let alone port it to a different framework.  But if there’s enough interest from people – and if other developer’s seem motivated in actively continuing this project – I’ll see what I can do about raising the priority of an Open Source release.

Flash Camp Hawaii

The Free Flash Camp Hawaii conference is going to feature the best in 2D and 3D Flash-Platform Gaming!  Register Here:

Join The Stage3D Facebook Group

April 29, 2013 / Daniel Freeman

MadComponents and the Virtual Keyboard

MadComponent128exA common question that I’ve had from MadComponents developers is how to deal with the virtual keyboard.  Specifically, the problem of input textfields getting obscured under the virtual keyboard.

The approach involves moving the UI up so that the input field is above the top of the virtual keyboard.  But what do you use to trigger this action?  How do you know the dimensions of the keyboard?   And how do you know when to restore the UI back to where it should be?

There are SoftKeyboardEvent.SOFT_KEYBOARD_ACTIVATE, and SoftKeyboardEvent.SOFT_KEYBOARD_DEACTIVATE events dispatched by TextFelds and StageText objects.  You can respond to these to know when to adjust the UI, and when to restore it.  When the virtual keyboard is active, you can query stage.softKeyboardRect object to determine the rectangle area occupied by the virtual keyboard.  Then it’s just a matter of raising the position of the UI, so that the input textfield is moved above this rectangle.

Here’s the code:-

package com.powerflasher.SampleApp {

 import com.danielfreeman.madcomponents.*;
 import flash.text.ReturnKeyLabel;
 import flash.text.SoftKeyboardType;
 import flash.text.StageText;
 import flash.geom.Rectangle;

 public class InputHelper {

protected static var _stageText:StageText;
 protected static var _input:UIInput;

 public function InputHelper() {

 public static function initialiseStageText(fontSize:int = 20, colour:uint = 0x000000):void {
// var stageTextInitOptions:StageTextInitOptions = new StageTextInitOptions(false);
_stageText = new StageText();
_stageText.fontSize = fontSize;
_stageText.color = colour;
_stageText.stage = UI.uiLayer.stage;
_stageText.visible = false;
_stageText.addEventListener(SoftKeyboardEvent.SOFT_KEYBOARD_DEACTIVATE, softKeyboardDeactivate);

 public static function setSoftKeyboardListeners(input:UIInput):void {
UIBlueText(input.inputField).addEventListener(SoftKeyboardEvent.SOFT_KEYBOARD_ACTIVATE, softKeyboardActivate);
if (!_stageText) {
UIBlueText(input.inputField).addEventListener(SoftKeyboardEvent.SOFT_KEYBOARD_DEACTIVATE, softKeyboardDeactivate);

 public static function removeSoftKeyboardListeners(input:UIInput):void {
UIBlueText(input.inputField).removeEventListener(SoftKeyboardEvent.SOFT_KEYBOARD_ACTIVATE, softKeyboardActivate);
UIBlueText(input.inputField).removeEventListener(SoftKeyboardEvent.SOFT_KEYBOARD_DEACTIVATE, softKeyboardDeactivate);

 protected static function finishStageText():void {
_input.text = _stageText.text;
UIBlueText(_input.inputField).visible = true;
_stageText.visible = false;
_input = null;

 public static function applyStageText(input:UIInput, autoCorrect:Boolean = false, softKeyboardType:String = SoftKeyboardType.DEFAULT, returnKeyLabel:String = ReturnKeyLabel.DEFAULT):void {
if (_input) {
UIBlueText(input.inputField).visible = false;
_stageText.visible = true;
_stageText.text = input.text;
// The following line won't work in the current public release of MadComponents.  But it will work in a later release which has a password getter.
//_stageText.displayAsPassword = UIBlueText(input.inputField).password;
_stageText.autoCorrect = autoCorrect;
_stageText.softKeyboardType = softKeyboardType;
_stageText.returnKeyLabel = returnKeyLabel;
_stageText.viewPort = input.stageRect();
_input = input;

 protected static function softKeyboardActivate(event:SoftKeyboardEvent):void {
var inputField:UIBlueText = UIBlueText(;
var input:UIInput = UIInput(inputField.parent);
var stageRect:Rectangle = input.stageRect();
var difference:Number = UI.uiLayer.stage.softKeyboardRect.y - stageRect.bottom;
if (difference < 0) {
UI.uiLayer.y = difference;
if (_stageText) {

 protected static function softKeyboardDeactivate(event:SoftKeyboardEvent):void {
UI.uiLayer.y = 0;
if (_stageText) {


How to use InputHelper

Suppose you have a MadComponents Form with username and password inputs:

<vertical background=”#222244″>
    <vertical alignH=”centre” alignV=”centre” width=”200″>
        <input id=”username” prompt=”username” alignH=”fill”/>
        <input id=”password” prompt=”password” password=”true” alignH=”fill”/>
        <button id=”login” alignH=”right”>Login</button>

To utilise the InputHelper class, your AS3 code would look something like this:-

_username = UIInput(UI.findViewById(“username”));
_password = UIInput(UI.findViewById(“password”));

( To remove inputs listeners, for memory management purposes, just call InputHelper.removeSoftKeyboardListeners(_input); )


The InputHelper also includes a mechanism for utilising StageText.  StageText can take advantage of auto-correction.  Also, you may wish to customise the type of virtual keyboard.  Alphanumeric, Numeric, Email, etc.  ( To access this capability, you might want to modify the helper slightly, and use the optional parameters in the applyStageText class.)  The applyStageText class temporarily replaces your <input> textfield by a StageText field.  (When the user completes their text input – the text is transferred into the <input>, and the StageText becomes invisible.)

To enable this capability, you must first initialise it by calling the initialiseStageText() method.  ( Call it prior to any setSoftKeyBoardListeners() calls )

On one Android test device, I noticed that StageText SoftKeyboardEvent.SOFT_KEYBOARD_DEACTIVATE event wasn’t always being dispatched properly when the soft keyboard disappeared.  (So the UI wasn’t being restored to its usual position).  But just tapping on the UI background tended to sort out the problem.


The popular MadComponents (+ ExtendedMadness) frameworks are about to get a new lease of life.  I’ve recently been commissioned to develop a mobile app (which I can’t talk about yet), but I’m basing it on MadComponents.  As the project will embody a lot of customised UI / UX  design – this is going to result in a lot of improvements to MadComponents, and some great new components too.  Watch this space, and join the Facebook MadComponents Group. 

There’s an introductory video to MadComponents here: 

If you like MadComponents, don’t forget to leave a “star”, or “g + 1″ recommendation on the Google Code site.