MobileAppDev

August 8, 2015 / Daniel Freeman

I’ve uploaded a beta of the next release of MadComponents/ExtendedMadness. The download is pinned at the top of the MadComponents Facebook Group. This is an FDT archive file of the source classes. The .swc library is in the lib folder. You can just take this .swc, and include it in your own project,

This beta fixes some idiosyncrasies with lists that were introduced in the previous release. There are also five new features.

1. Radial Slider

This is the most exciting new addition. It’s inspired by Apple Watch UI elements. A radial slider is a circular slider control. This component has a lot of options to customise its appearance. In the centre of the concentric sliders, there’s a textfield that can be written with XML, or assigning to the .text property of UIRadialSlider. This component dispatches UIRadialSlider.CHANGE, and UIRadialSlider.SELECT events. UIRadialSlider has a .values property that yields an array of slider positions. a .index property gives you the index of the last slider changed. (There is also a .value property, that gives the value of the last slider changed. – but it’s not wired up yet in this beta version.)

Screen Shot 2015-02-06 at 21.39.08 Probably the best way to learn what all the attributes do – is just to play around, and experiment with different values. Here is the XML Layout to generate the four radial sliders above:-

<radialSlider
  values="0.7,0.4"
  rounded="false"
  offsetAngle={-Math.PI}
  maximum="0.8">
  <font color="#66FF66"/>slider
</radialSlider>

<radialSlider
  values="0.2,0.7,0.3"
  background="#FFCCCC,#FFCC99"
  colours="#CC6666,#CC9966"
  buttonColours="#FFFFCC"
  sliderThickness="8"
  margin="4"
  spacing="8"
/>

<radialSlider
  numberOfSliders="3"
  values="0.3,-0.3,0.3"
  minimum = "-0.4"
  maximum = "0.4"
  background="#666699"
  colours="#666699"
  buttonColours="#FFEE99"
  margin="-8"
  offsetAngle={1.5 * Math.PI}
/>

<radialSlider
  numberOfSliders="2"
  values="0.4,0.6"
  width = "50"
  sliderThickness="12"
  margin="4"
  alt="true"
  colours="#CCFFCC,#CCCCFF"
  outlineColours="#339933,#333399"
  background="#99CC99,#9999CC"
  maximum = "0.8"
  spacing="2"
/>

*Note that in this beta we specify angles in radians – this is an oversight, and will be changed to degrees in the next release.

2. Circular Arrangement

The <circular> containers allows you to arrange simple components (such as icons, buttons, or images) in a circlular arrangement. For example:-

<circular>
   <button/>
   <button/>
   <button/>
   <button/>
   <button/>
 <circular/>
Obviously this example is more exciting if the buttons have text or custom skin images.

3. Spacing

The <gap> component allows you to tweak the spacing between vertically or horizontally spaced components. For example:

<vertical>
  <button/>
  <gap height="20"/>
  <button/>
</vertical>

4. <image>{DATA}</image>

There’s a change to the <image> component that allows you to specify data for different screen pixel densities, in the same way as the <tabPages> and <icons> components. Although the <imageX> component allows you to accomplish this in a different way, <image> is now more consistent with other components. Hence <imageX> is depreciated now.

<data>
  <item
    ldpi={getQualifiedClassName(ERROR_LD)}
    mdpi={getQualifiedClassName(ERROR_MD)}
    hdpi={getQualifiedClassName(ERROR_HD)}
  />
</data>

5. FTE Label

The <labelFTE> component is like the <label> component, but it utilises the Flash Text Engine. The XML attributes match the properties of the flash.text.engine.ElementFormat and import flash.text.engine.FontDescription classes. There’s also a leading and a rightToLeft attribute.

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/

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

Please blog and tweet about this project (#MadComponents) and help to spread the word. Also, don’t forget to leave a “star”, or “g + 1″ recommendation on the Google Code site. Also, help promote the new Github repository.

January 25, 2015 / Daniel Freeman

Eight MadComponents XML Layout features that I’d like to see in Feathers.

For every Adobe-endorsed AS3 Framework, there tends to be at least one non-endorsed AS3 Framework that is much better in some ways. Diversity is a good thing. So, Adobe endorsement is a mixed blessing. On the one hand, it’s great that Adobe takes frameworks that have been incubated by the community – and injects money, publicity, and surrogate credibility. On the other hand – exclusivity is bad for the AS3 community, and it stifles innovation and advancement. Adobe only shines its spotlight on ONE framework in each category. Everything else is cast into the shadows. Developers naively assume that Adobe-endorsement means that the Adobe-endorsed framework will do everything better than the non-endorsed framework. So when the Adobe-endorsed framework fails to deliver – that developer will look elsewhere. They’ll jump the fence to HTML5, Unity3D, Corona, etc, rather than consider fantastic non-endosed AS3 Frameworks. I know that this has happened, and that the Flash Platform has needlessly lost credibility and developers to the competition.

Adobe supports three significant AS3 frameworks, for three significant use-cases. Away3D for 3D animation. Starling for 2D animation. And Feathers for UI Form-based apps. For each of these use-cases, there are amazing non-endorsed frameworks. Zest3D, and Flare3D for 3D animation. Genome2D, and ND2Dx for 2D animation. MadComponents for UI Form-based apps.

There is no silver bullet. The best framework for one project, may not be the best for another. In some respects, Adobe-endorsed frameworks are better. In other ways, non-endorsed framework are better. It will all depend on the requirements of the application. For example, Away3D is well-known and mature. But Zest3D performs better on devices. Adobe endorsement of Starling has created tremendous interest. But Genome2D performs better. Feathers allows for smoother page transitions, and list scrolling. Also Feathers mixes well with Starling. But MadComponents is better with pixel-snapped images, embedded fonts, ease of adding customised components, a faster start-up time, and it has many more components, including the most performant mobile-optimised datagrids of any AS3 UI Framework. I’m not trying to discredit the Adobe-endorsed frameworks, or their developers. But I have a lot more respect for the developers of non-endorsed frameworks, for their tenacity, ingenuity, and dedication, despite being cast into the shadows. I just wish there was more discussion about the relative merits of both Adobe-endorsed and non-endorsed frameworks. I wish the authors of the Adobe-endorsed frameworks would shed more light on the alternatives, rather than silently reinforcing a misconception of theirs is the only AS3 way to do the job.

Actually, there is just one previously Adobe-endorsed framework that I would remove from the face of the planet if I had the chance. The inadequacy of Adobe Flex for Mobile (now Apache Flex) has done a lot of damage to the credibility of Adobe AIR on devices.

I was interested to read that Josh Tynjala plans to incorporate MXML layouts to Feathers. He is looking for corporate sponsorship. Or he may consider Kickstarter funding.

I was interested that some of the respondents to Josh’s tweet were worried that an XML layout might introduce performance problems. Some developers assume this, because Flex on Mobile is slow and bloated. But the problems of Flex on Mobile are not caused by the MXML. They are caused because the Flex framework was not originally designed for mobile devices, and Flex is optimised for (slow) CPU rendermode. MadComponents is built around a powerful XML layout language that was designed for mobile layouts, and loosely based on native Android development. And MadComponents is agile, lightweight, and easy to develop for. So XML layouts are obviously a good idea. The main benefit of a layout XML language is that it makes UI development much much faster and easier. Also easier to maintain and modify. I hope that Josh manages to do this, because it opens up some powerful possibilities. To illustrate my point, here are eight MadComponents layout features that I’d like to see brought to Feathers. (The following list will also be of interest to developers learning MadComponents)

1. Easy Page Navigation Without Code

We want our layout XML language to save us coding and effort. Let’s look at the way that MadComponents layout deals with navigating pages. Suppose we have defined the XML layout of several pages. PAGE0, PAGE1, PAGE2, etc… If want to make navigation for those pages, we don’t want to mess around with glue code AS3. We don’t want to mess around with listeners, and handlers, that call the API to change the page. We want just want to write the layout XML, and let the framework handle the nitty-gritty. For example,

<tabPages>
   {PAGE1}
   {PAGE2}
   {PAGE3}
</tabPages>

The above layout would generate tab buttons at the bottom of the page. And those buttons are wired-up to work, without any additional code. Later, we will see how we can even define labels and icons as XML data.

from MyAstrolabeSky app on App Store

Or suppose you want a standard list-based navigation that leads to a detail page. We want the framework to deal with the nitty gritty of responding to list clicks, sliding-in the detail page, the detail page, and the back-button operation. So this is all we need:

<navigation>
   {PAGE1}
   {PAGE2}
   {PAGE3}
</navigation>

Even pressing a button to change page shouldn’t require the developer to bother with additional glue code:

<button goTo="home_page" transition={UIPages.SLIDE_LEFT}>GO</button>

2. Custom Renderers

If Josh bases his UI layout language on MXML, then he will likely incorporate itemRenderers. Here is the MadComponents way to do it:

<list>
   <horizontal>
      <image id="picture">40</image>
      <label id="name" alignV="centre"/>
   </horizontal>
</list>

3. Lazy Rendering

Stage3D apps don’t tend to start up as fast as GPU rendermode apps. That’s because uploading textures, and vectors to the GPU is an overhead. Lazy Rendering ensures that render pages as they’re displayed, rather than rendering all the pages when the app starts up. In MadComponents we might say something like:

<pages lazyRender="true"/>

4. Pixel Density Matched Images

For the sharpest and best quality images, we will want to snap pixels, and match the unscaled image size to the screen pixel density. So we might specify the image data for icons or tab pages like this:

<data>
     <item label="page 1"
        ldpi={getQualifiedClassName(ICON_LD)}
        mdpi={getQualifiedClassName(ICON_MD)}
        hdpi={getQualifiedClassName(ICON_HD)}
    />
 …etc… etc….
 </data>

5. Different Layouts for Different Screens

If we want to build universal apps. Or if we want to cater for devices with very small screens (240×320). Or even if we want different layouts for portrait and landscape orientation – then our XML layout language should deal with alternative layouts for different size dimensions.

<screens id="screens" lazyRender="true" recycle="true">
 <vertical size="320x240">......
 <vertical size="640x480">.....

For more information about the screens tag, see here.

6. Better Labels

Recently, a developer told me that his Hebrew text list was taking about ten seconds to initialise in Feathers. This bottleneck was due to rendering the text on the display-list, then uploading each row label as a texture. In MadComponents, there is no noticeable start-up delay. So, it would be great if there was any optimisation that could be done in Feathers to initialise embedded font text faster. In MadComponents, an embedded font label looks like this:

[Embed(source="/fonts/SomeHebrewFont.ttf", fontFamily="Hebrew", embedAsCFF="false")]
protected const Hebrew:Class;

<label id="label" alignH="fill" embedFonts="true" antiAliasType="advanced"/>

7. The Model Tag

The model tag enables communication with a server. It handles retrieval of JSON, XML, or AMF data, parsing, and deriving the data for a form or list.

<model url="http://localhost/MobileTestDrive/gateway.php" service="EmployeeService.getEmployeesSummary" action="loadAMF">
    <firstname>label</firstname>
    <lastname>label</lastname>
    <photofile>image</photofile>
    <title/>
    <id/>
</model>

The entire example that this code snippet comes from can be found here.

8. Make It Extensible

MadComponents was designed to be easily extensible, with both pre-existing display-list libraries, and new components. This extensibility philosophy even applies to the XML layout language. Here’s an example of using a MinimalComps component inside a MadComponents layout:-

<vertical xmlns:minimal="com.bit101.components">
    <minimal:PushButton label="push me" alignH="fill" height="32" skinClass="com.dgrigg.skins::ButtonImageSkin"/>
</vertical>;

Conclusions

An XML UI layout saves you a lot of time, effort, and coding when developing an application. This is because a powerful XML UI layout language will replace a lot of code. Not only does the layout replace the code to render a UI to the target device screen size. It also handles orientation change. And we’ve seen how aspects of the layout language can also replace the code to navigate an app, custom renderers, managing resources to match screen pixel density, layouts for different screen sizes and orientations, server communication, and many more capabilities. So XML Layouts for Feathers are definitely a good idea.

links

Feathers: http://feathersui.com MadComponents: https://www.facebook.com/groups/madcomponents github: https://github.com/danfreeman/MadComponents video: https://www.youtube.com/watch?v=CMf2XGRhkOk

November 14, 2014 / Daniel Freeman

Flash Platform, OpenFL and Adobe AIR links.

Adobe Feeds are disappearing soon. So I thought it would be useful to publish a list of useful AS3/Flash/OpenFL links, groups, blogs, aggregates, websites etc. This isn’t an exhaustive live. Just a starting point lashed together from my own favourites, and contributions from other developers. So if I’ve left anything out – please let me know. Also, please subscribe to THIS website.

October 13, 2014 / Daniel Freeman

MadComponents 0.8 Released

The long-awaited milestone release is out now! MadComponents 0.8 / ExtendedMadness 0.3 includes more datagrids, tables, faster custom list renderer, and better support for images matched to screen density.

The source code is still hosted on GoogleCode. But since, the .swc libraries can’t be downloaded from there, we’re hosting on Github too. The .swc libraries can be downloaded from Github.

Many of these new features have been discussed already. (See previous posts, part1 and part2). A new datagrid component made its way into to the final cut. UISimpleDataGrid subclasses the other datagrids. It doesn’t have as many features, but it renders even faster than UIFastDataGrid. And, just like the other datagrids, it is optimised for mobile screens. UISimpleDataGrid achieves its speed by rendering all grid cells within a single TextField. Text items separated by newlines and tabs. Of course, this means that there are some restrictions on cell text formatting. And no multiline or text-wrapped items. But provided that you can work within those restrictions – rendering is very, very fast. If these restrictions get in your way – then simply use UIFastDataGrid instead. As the name suggests, it’s no slouch either. Here’s an example layout:

<simpleDataGrid id=”dataGrid” titleBarColour=”#333333″ background=”#333333,#FFFFFF,#CCCCFF”>

<title><font color=”#FFFFFF” size=”18″/>Datagrid example</title>

<headerFont face=”Arial” size=”16″ color=”#EEEEFF”/>

<font face=”Arial” size=”13″ color=”#333333″/>

{DATA}

</simpleDataGrid>;

UISimpleDataGrid may be nested inside UIScrollDataGrids. And UIScrollDataGrid has a new “datagrid” attribute. For example:

<scrollDataGrid datagrid=”simple”>

or

<scrollDataGrid datagrid=”fast”>

or

<scrollDataGrid datagrid=”special”>

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/

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

April 21, 2014 / Daniel Freeman

MadComponents 0.8 ExtendedMadness 0.3 BETA part 2

In 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>;

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

The 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).

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.

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.

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.

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 leading cross-platform app development 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 letter, Luca 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.

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?

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

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

← Older

1. Radial Slider

2. Circular Arrangement

3. Spacing

4. <image>{DATA}</image>

5. FTE Label

Join The Community

1. Easy Page Navigation Without Code

2. Custom Renderers

3. Lazy Rendering

4. Pixel Density Matched Images

5. Different Layouts for Different Screens

6. Better Labels

7. The Model Tag

8. Make It Extensible

Conclusions

links

FACEBOOK GROUPS

LINKED-IN GROUPS

GOOGLE+

WEBSITES

CODE

NATIVE EXTENSIONS

FLEX AND ACTIONSCRIPT (Thanks to Cato Paus Skrede for providing this list).

OPEN-FL

GENOME2D

ND2Dx

STARLING

FEATHERS

MADCOMPONENTS

MINIMALCOMPS

ZEST 3D

AWAY3D

FLARE 3D

Join The Community

6. UIIcons Improvements.

7. UITabPagesSliding

8. Per-Row Renderers and Background Colours for Lists

9. Better List Scrolling Performance and <renderer> Tag

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

Join The Community

Join The Community

The AIR Community

Those disenfranchised ex-customers

The Power of AIR

PhoneGap

asm.js, Enscripten, and famo.us

AIR 2D and UI Frameworks

My App

Chris Cambell’s Response

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

Categories

Recent Posts

Archives

Follow Blog via Email