Skip to content
April 21, 2014 / Daniel Freeman

MadComponents 0.8 ExtendedMadness 0.3 BETA part 2

MadComponent128exIn the previous part of this blog post, we described five new features in the MadComponents beta release. In this second part, we’ll describe five remaining new features. Most new features are refinements on existing components.  The beta is available on the MadComponents FaceBook Group to download and try now.  (See in pinned thread – the beta is included in the 0.79/0.21 folder).

Please try it out – and report any problems.  There’s a lot of new stuff – so I’d appreciate any help ensuring that all the old functionality is still ok – and all the new stuff works as advertised.

This is what we have left to cover:

6. UIIcons improvements:  The new scheme for specifying images and labels in the XML layout, and different resolution images for different density screens, may also be used with the UIIcons component.

7. UITabPagesSliding:  Another kind of tabbed pages component, with a tab button panel that scrolls horizontally, allowing you to add many buttons, regardless of screen size limitations.

8.  Per-Row Renderers and Background Colours for Lists:  Apply different item renderers, and different settings to different rows of a list.

9. Better List Scrolling Performance and <renderer> Tag:  An easier way to define custom item renderers – that also results in smoother scrolling behaviour.

1o. <model> tag now deals with XML attributes:  Previously, the model tag dealt with <this>kind of data</this> not <this attr=”kind of data”/>.

 

 

So here’s the remaining new stuff in detail:-

6. UIIcons Improvements.

UIIcons has been refined and improved a lot over the last few versions. UIIcons allows for a horizontally arranged line of clickable icons. Each may have a label. (It may have a length of one. Just one icon). Each icon may be pixel-snapped, and unscaled for sharpness. And you can automatically selected from different size images. Here’s a typical UIIcons layout:-

<icons border=”false”
gapH=”30″
leftMargin=”20″
height=”38″
background=”#001133,#000022″
iconColour=”#FFCC33″
activeColour=”#CCCCFF”
pixelSnapping = “true”>
<font color=”#FFEE99″/>
<activeFont color=”#CCFFFF”/>
{DATA}
</icons>;

UIIcons

So this layout describes a line of icons. LeftMargin defines the start position of the first, and then they are spaced by gapH. iconColour and activeColour describe the colour applied to icons, and how it changes if an icon is pressed. The icons are toggled, so that only one is active at any time. <font> and <activeFont> describe the styling applied to the label in the normal and active states. Note that the background has two values, again for normal and active states.

The data is specified in the same way as tabbed pages. Including the use of “ldpi”, “mdpi”, “hdpi”, “xhdpi” and “xxhdpi” attributes. eg:

<data>
<item label=”page 1″
ldpi={getQualifiedClassName(ERROR_LD)}
mdpi={getQualifiedClassName(ERROR_MD)}
hdpi={getQualifiedClassName(ERROR_HD)}
/>
…etc… etc….
</data>
 
 

7. UITabPagesSliding

UITabPagesSliding encapsulates a popular layout that combines UIIcons with UIScrollHorizontal and UIPages to provide a tabbed pages layout with sliding tab buttons. Rather than implement it yourself, from its constituent components – you just need to use a layout like this:-

protected static const PAGES:XML =    <tabPagesSliding background=”#CCFFCC” alt=”true”>
{DATA}
{PAGE0}
{PAGE1}
</tabPagesSliding>;

The data is the same as UIIcons. Note that you can get to instances of the UIPages and UIIcons constituents using the .tabPages and .icons getter methods.

 

8. Per-Row Renderers and Background Colours for Lists

Lists include a new setter method, rendererXML. This allows you to specify a new custom renderer prior to assigning new data to a list. eg:

_myList.rendererXML = RENDERER_XML;
_myList.data = newData;

(There is also a depreciated .renderer setter – use .rendererXML instead, as .renderer will be removed soon)

But it is also possible to specify different renderers for each list row ($renderer). You can also assign different background colours ($colour), whether to draw vertical dividing lines or not ($lines), and whether the list row highlights when clicked ($highlight). These options may be optionally included in the row data. eg:

_myList.data = [{label:"Hello World", $renderer:XML_RENDERER, $colour:0xFF9900 , $lines:false, $highlight:true }];

 

9. Better List Scrolling Performance and <renderer> Tag

This new version has tweaked the performance of lists so that they scroll more smoothly. There is also a new, more efficient way to declare common custom renderers. The most common custom renders declare text fields one after another, with an optional image on the left. Up until now – we would have used nested <horizontal> and <vertical> tags to achieve this. But a nested, more complicated, Sprites within Sprites, display-list tree turns out to be less optimal when it comes to scroll performance. Especially, when your list has many renderers made up like this. The new UIRenderer class results in a flatter row renderer.

So, instead of writing a list renderer like this:-

<horizontal>
<image id=”img”>60</image>
<vertical alignV=”centre”>
<label id=”line1″>Hello World</label>
<label id=”line2″>second line of text</label>
</vertical>
</horizontal>

You can simply write it like this:-

<renderer>
<image id=”img”>60</image>
<label id=”line1″>Hello World</label>
<label id=”line2″>second line of text</label>
</renderer>

It’s easier, and it performs better. But obviously, the old method is still appropriate for any general renderer layout where <renderer> can’t be applied.

 

1o. <model> tag now deals with XML attributes

The <model> tag has always made it easy to read XML, JSON, or AMF data from a server – and use it to populate a list or form. But previously, the XML capability was limited to reading data between tags. <this>kind of data</this>. Now we can deal with <this attr=”kind of data”/>.

Consider the following XML data:-<?xml version=”1.0″ encoding=”utf-8″?>
<stuff>
<item gender=”male”>
<name>Fred Bloggs</name>
<age flag=”2″>32</age>
</item>
<item gender=”female”>
<name>Sarah Wilson</name>
<age flag=”3″>28</age>
</item>… etc…etc…..

You could write the following layout to extract this data and display it in a list:-

<list>
<model url=”http://127.0.0.1/people.xml&#8221; action=”loadXML”>
<stuff>
<item gender=””>
<name/>
<age flag=”flagg”/>
</item>
</stuff>
</model>
<renderer>
<label id=”name”/>
<label id=”age”/>
<label id=”gender”/>
<label id=”flagg”/>
</renderer>
</list>

… so that’s all the new stuff covered.  Please download the Beta, and try it out.  Let me know about any problems.

Join The Community

For community discussions about MadComponents, and to download the latest .swc libraries, come and join the facebook page:-http://www.facebook.com/groups/madcomponents

You may also be interested in the Stage3D Facebook group: http://www.facebook.com/groups/stage3d/

here’s an introductory video to MadComponents here: http://www.youtube.com/watch?v=CMf2XGRhkOk

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.

 

April 17, 2014 / Daniel Freeman

MadComponents 0.8 ExtendedMadness 0.3 BETA part 1

MadComponent128exThe next version of MadComponents/ExtendedMadness will include some significant changes and additions.  The beta is available on the MadComponents FaceBook Group to download and try now.  (See in pinned thread – the beta is included in the 0.79/0.21 folder).

Please try it out – and report any problems.  There’s a lot of new stuff – so I’d appreciate any help ensuring that all the old functionality is still ok – and all the new stuff works as advertised.  Here are 10 new features:

1. Depreciated Components and New Components:  Experimental undocumented, and previously depreciated components have gone.  But the ancient UIDataGrid has gone (use UIFastDataGrid), and the ugly UIArrow component is also gone (use <list arrows=”true”>).  There are also new components added: UITable, UISpecialDataGrid, UITabPagesSliding, UIScreens, and UIRenderer.

2. Support for Multiple Screen Sizes And Pixel Densities:  Use the <screen> tag to specify alternate layouts for different screen sizes.

3. UISpecialDataGrid:  A fast and capable Datagrid with images.  optimised for mobile devices and GPU rendermode.

Screen shot 2014-04-17 at 12.57.45

4. UITable:  Another way of displaying tabular/grid layouts.

5. Icons and Labels For Tabbed Pages:  Previously, you needed to do this programmatically using the setTab() method. Now, you can specify labels and images in the layout – and you can even specify multiple versions for different screen pixel densities.

6. UIIcons improvements:  The new scheme for specifying images and labels in the XML layout, and different resolution images for different density screens, may also be used with the UIIcons component.

7. UITabPagesSliding:  Another kind of tabbed pages component, with a tab button panel that scrolls horizontally, allowing you to add many buttons, regardless of screen size limitations.

8.  Per-Row Renderers and Background Colours for Lists:  Apply different item renderers, and different settings to different rows of a list.

9. Better List Scrolling Performance and <renderer> Tag:  An easier way to define custom item renderers – that also results in smoother scrolling behaviour.

1o. <model> tag now deals with XML attributes:  Previously, the model tag dealt with <this>kind of data</this> not <this attr=”kind of data”/>.

 

So, as there’s so much new stuff – it’s going to take a while to go through the details.  So I’m going to split the details between two blog posts.  This, and a sequel to follow soon.

1. Depreciated Components.

UIArrow, UIDataGrid, UIDetailList, UIField, UIArrowButton, UIAccordionList, UIPopUpButton, and UITextSlider.  Sometimes, ExtendedMadness included experimental trial components that were never formally documented - and it’s mostly those that have been removed here.  Be careful that UIArrow is gone now – as some early examples used this.  <fastDataGrid> is mostly equivalent to <dataGrid> – so there’s usually no problem replacing <dataGrid> with <fastDataGrid>, and UIDataGrid with UIFastDataGrid.

 

2. Support for screen sizes and pixel densities

The <screens> tag allows you to define multiple alternative layouts, for various screen sizes, orientations, or pixel densities.  Use it like this:-

<screens id=”screens” lazyRender=”true” recycle=”true” border=”false” autoResize=”false”>
{LAYOUT0}
{LAYOUT1}
{LAYOUT2}
</screens>

Each LAYOUT will define a size attribute.  For example:

protected static const LAYOUT0:XML = <vertical size=”P320x200C”>…etc…

The size code may optionally begin with a P or L, for portrait or landscape.  Next we specify the minimum screen size for this layout: WxH.  (Note that this is the screen size AFTER pixel density scaling.)

There’s an optional C – which will centre the layout on the screen.

Alternatively, specify the minimum pixel density.  eg:  size=”320DPI”.

You would arrange LAYOUT0, LAYOUT1, etc… in order from smallest to largest.  With the default specified last.

 

3. UISpecialDataGrid

I briefly considered calling this an Advanced Data Grid.  But I didn’t want to imply any Flex bloatedness.  The UISpecialDataGrid is optimised for performance with GPU rendermode and for mobile devices.   UISpecialDataGrid subclasses UIFastDataGrid and adds the ability to incorporate images (or any DisplayObject) inside grid cells.

The data for a UISpecialDataGrid starts with the two dimensional array for rows and columns – but any cell that includes more than one item (eg: text + image) will itself be defined as an array.

eg: ["Here s my text", IMAGE_CLASS]  or [ IMAGE_CLASS, "Here is my text" ].  There is a restriction, in that you are only allowed ONE text part.  But you may use multiple images, both before and after the text.

(There is a possible work-around to this restriction – if you were to specify a DisplayObject that comprises of both images and text, and whatever else – but I haven’t tried this.)

 

4. UITable

MadComponents has always provided more than one way of constructing tables.  Originally, with the old UIDataGrid component – and using a list with a custom renderer and lines=”true” – to construct vertical dividing lines within each row.  <rows> and <columns> containers have always allowed you to arrange components into a tabular/grid arrangement – but there are no dividing lines.  The new UITable component can be used instead of UIRows – but each cell may have a background and outline colour.

Instead of writing this:

<rows>
    <columns>
        etc….

Just write this:

<table>
    <columns>
         etc….
 

5.  Icons and Labels for Tabbed Pages

Previously, the icons and labels on on tabbed pages needed to be constructed programmatically using the setTab method.  Use a data tag:

protected static const DATA:XML =
    <data>
        <item label=”page 1″  image={getQualifiedClassName(ERROR)}/>
        <item label=”page 2″  image={getQualifiedClassName(SYNC)} />
        <item label=”page 3″  image={getQualifiedClassName(CHAT)}  />
    </data>;
 
protected static const LAYOUT:XML =
    <tabPages>
        {DATA}
        {PAGE1}
        {PAGE2}
        {PAGE3}
    </tabPages>;

In this new version – you may specify them within the XML layout.  Also, you can deal with screens with different pixel densities.  You can use a size attributes to specify screen dpi, as you would for the <screens> tag.  Pixel Densities specified in ascending order, and multiple DATA definitions.

<data size=”160DPI”  >

There’s another way to specify images for multiple pixel densities.  Using ldpi, mdpi, hdpi, xhdpi, and xxhdpi attributes.  Like this:-

protected static const DATA:XML =
    <data>
    <item label=”page 1″
        ldpi={getQualifiedClassName(ERROR_LD)}
        mdpi={getQualifiedClassName(ERROR_MD)}
        hdpi={getQualifiedClassName(ERROR_HD)}
    />
    <item label=”page 2″
        ldpi={getQualifiedClassName(SYNC_LD)}
        mdpi={getQualifiedClassName(SYNC_MD)}
        hdpi={getQualifiedClassName(SYNC_HD)}
    />
    <item label=”page 3″
        ldpi={getQualifiedClassName(CHAT_LD)}
        mdpi={getQualifiedClassName(CHAT_MD)}
        hdpi={getQualifiedClassName(CHAT_HD)}
    />
</data>;
 

Join The Community

For community discussions about MadComponents, and to download the latest .swc libraries, come and join the facebook page:-http://www.facebook.com/groups/madcomponents

You may also be interested in the Stage3D Facebook group: http://www.facebook.com/groups/stage3d/

here’s an introductory video to MadComponents here: http://www.youtube.com/watch?v=CMf2XGRhkOk

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.

 

April 1, 2014 / Daniel Freeman

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

air

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.

 

PhoneGap

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 famo.us

Obviously, asm.js, Enscipten, and famo.us 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 famo.us 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 famo.us 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 )

Re: http://blogs.adobe.com/digitalmarketing/web-experience/adobe-experience-manager-mobile-app-announcement/

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
http://www.plugin.io

__________________________________________________________________

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, https://twitter.com/plugin_io/status/448887602238611458

And please forward a copy of the open letter to your favourite Adobe representative.
https://www.facebook.com/garypaluk/posts/10152028727336149

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.

magazines

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.

ZX81

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):-
fastdisplay
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

UIFastDataGrid

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.

UIScrollDataGrid

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” />
</scrollXY> 

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.

 

UIScrollDataGrids

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″/>
</scrollDataGrids>
 

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.

UIScrollTouchGrids

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:-http://www.facebook.com/groups/madcomponents

You may also be interested in the Stage3D Facebook group: http://www.facebook.com/groups/stage3d/T

here’s an introductory video to MadComponents here: http://www.youtube.com/watch?v=CMf2XGRhkOk

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.

wheels
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.

_pages.goToPageId(“page_two”);

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.

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

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>

testSlider

<screens>

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
</vertical>

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”>
   {LANDSCAPE_SMALL}
   {PORTRAIT_SMALL}
   {LANDSCAPE_MEDIUM}
   {PORTRAIT_MEDIUM}
</screens>;

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:-http://www.facebook.com/groups/madcomponents

You may also be interested in the Stage3D Facebook group: http://www.facebook.com/groups/stage3d/

There’s an introductory video to MadComponents here: http://www.youtube.com/watch?v=CMf2XGRhkOk

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.
Follow

Get every new post delivered to your Inbox.

Join 89 other followers