Forthcoming AIR application updates

Along with the new e2publish (online publishing AIR application), I’ll also be releasing updates to e2spreadsheet and e2vector soon.

The next version of e2spreadsheet has:-

1. New, powerful OLAP totals feature.

2. More powerful cell formatting.  Choose currency symbol and number of decimals.

3. Choose number of frequency bins for frequency graph.

4. AVERAGE(), ABS(), ROUND(), TRUNC(), MIN() and MAX() functions added to formula language.

5. Cosmetic changes and a side-palette.

6. Undo graph palette position/resize bug fixed.

7. Append .e2s extension on files.

8. Other minor bug fixes and improvements.

The next version of e2vector has:-

1. A new brush tool!

2. Import and export FXG files – meaning that you can transfer illustrations to and from Flash!

3. Undo pen tool drawing bug fixed.

4. Other bug fixes and improvements.

The overall plans is to make these client AIR applications stable and powerful.  Next I’ll write the server-side stuff to allow users to collaborate and share documents.

I’ll announce when all these updates are available here or on twitter.

Adobe’s restrictive font licensing rules

Some of the features that I described in my video tour of e2publish won’t be making their way into the first release.  Adobe’s font licensing is just too restrictive.

It looks like ligature, digit case and digit width only have an effect on certain fonts.  But there are licensing issues with those fonts.  Adobe sells five user licenses for US$29 or US$35 per font.

Five user license?  What does this mean in a networked collaborative online context?

Well, according to Adobe this licensing model is VERY restrictive.  Too restrictive for online use.

“You may not use the fonts on any internet or web-hosted service outside of your internal network”

This means that Adobe’s guided tour of the Text Layout Framework is somewhat misleading.  Because technically, you wouldn’t be allowed to make your own website or collaborative application using fonts like Selentium Pro.

Adobe can do it – because they’re obviously exempt from their own licensing conditions.  But for anyone else – it would be technically illegal.

So it seems like Adobe’s heavy-handed legal shackles are restricting our potential to really fly with the technology.

Clearly, Adobe need to think about this.  (I’m not holding my breath.)

How should Adobe monetise the online use of its fonts?  There is a licensing model for Monotype fonts that they may want to look at.

. . . . . . . . . . .

I don’t twitter often because software development doesn’t lend itself to commentary.  Coding is esoteric.  An internal mental process not easily shared with others.  I’ve lost many subscribers due to my inactivity.  However, whenever I have something important to say, or an announcement or new release of an e2application – I’ll twitter it.  So if you’d like to be alerted about the public beta test of e2publish – you can subscribe to my twitter or this blog.

Announcing an Adobe AIR publish application.

I started working on this application in 2007.  It was to be my entry for the AIR developers derby.  However, I ran into limitations with text capabilities in Flash player 9.  Then, Buzzword was announced.  A well-funded and well-hyped competitor, supported by Adobe.  So I abandoned this project for a couple of years.

Now, with Adobe’s Text Layout Framework, and forthcoming “Squiggly” spell-checker – it seemed like a good time to finish what I started.

I’m still finishing things off for the first Beta version.  (and I’m also busy with paid work).  But I’ve prepared a video tour of the application so you’ll know what to expect.

The original vision for this project was to create an online service where users could collaborate to create slick-looking online magazines.  Right now, e2publish is just a client application.  But document sharing and collaboration are on the roadmap.

The most powerful features of e2publish are the page layout capabilities, and the way in which text wraps around pictures – even when pictures are between columns.

The old goat bites back

In reply to my previous post Gumbo, Substance behind the hype? – Jones wrote “Flex a hindrance? Only for old goats who sneer at changes to their old way of doing things.”

If someone doesn’t know about software development, then Flex is great. It’s ok for dragging together a quick application that exploits the components in the limited way they were intended. But as soon as you want more customised behaviour – it’s quicker to code from scratch with Pure ActionScript, than to wrestle with Flex idiosyncrasies. And I know these idiosyncrasies better than most people.

In my professional capacity as a senior Flex developer – I’m always getting asked to do with things with Flex components that Flex components don’t do. Ok coding custom components and objects may be an “old way of doing things”, and being an experienced software developer and AS3 expert may make me an “old goat” – but it gets the job done, and I get paid very well for it.

In the early  days, the market for Flex was predominantly existing Flash developers.  They probably didn’t delve as deeply into things as programmers do.  But now, I suspect that a lot of experienced software goats are moving to Flex.  I don’t think Gumbo went far enough to accommodate for this new user base.

The bloated swiss-army-knife monolithic components were written to be manipulated inside the Flex GUI – they were NOT designed to be inherited and extended by a programmer.

Anyway, since when is Flex a new idea? It’s like Visual Studio for ActionScript.  I hate .NET more than I hate Flex.  Jones is probably too young to remember when Visual Basic first came onto the scene. The problem with these drag-and-drop software making GUIs is how they handle the transition to more customised behaviour – Flex does not handle this well.

Buggy, bloated and badly conceived is not a new idea either.

Google O/S – Why not Adobe?

In the pre-history days before Central or Flex, I wrote a Flash-based operating system.  (I’ll try and dig-up pictures one day).  I called it “CoreOS”. It was a fully functional windows interface with REAL applications.  A spreadsheet, drawing apps, a word-processor, a game and some fun stuff.  It even had a console application and its own small command-line language.  It ran inside a browser window which adjusted itself to fill the screen – but what I really wanted was to break out of the browser.  What I did was just a demonstrator to hint at the potential.

I never took CoreOS any further, but the applications have evolved.  The spreadsheet, drawing application, and e2publish (probably the most sophisticated Flash-based word-processor never published).

Around 2001/2002 – I thought it was inevitable that we’d see a REAL Flash-based operating system really soon.  All the pieces seemed to be forming.  When Macromedia Central was released, I considered it to be a step in the right direction, and vindication that my ideas were right all along.  I thought AIR could be lead to a truly ubiquitous “internet O/S” for desktop, devices, hand-held, embedded, etc…

But it never happened – after all the years I’ve wasted on going-nowhere Macromedia/Adobe technologies.

Finally, years later, Google have made the leap.

So, why didn’t Adobe get there years ago?  Too timid?  I suspect they don’t see it as their business.  Adobe = eye-candy.  They’re not that committed to software (Real programmers don’t use Flex – at least, not for their own projects).  And you only need to look at the proposals that got Open-Screen funding to realise that Adobe is only interested in style – not substance.  Ground-breaking new algorithms, new classes of applications, speculative new ventures – I don’t think any of these things reflect the way Adobe see themselves.

Gumbo. Substance behind the hype?

Just like everyone else, I downloaded the public beta of Gumbo as soon as I found out about it.  But is it better than its predecessor?

My biggest problem with Flex is the components and the framework.  I hate Adobe’s bloated swiss-army-knife software approach.  I waste so much time struggling with Flex components, trying to get those monolithic beasts to behave in the way I want them to.

In the pure-actionScript world, I deal with small and efficient fit-for-purpose components.  If something doesn’t quite do what I want, I inherit it and override or add what I want it to do.  Everything is small and easy to understand.  (No wading through hundreds of methods and properties in the Flex documentation or source code).

Hence developing an application in Pure ActionScript is ultimately faster than Flex.  Flex Builder may initially look easier, with its drag and drop interface – but that’s deceptive.  But Pure ActionScript development is faster in the long run because Flex is a blunt instrument that’s inept at crafting the details.

So this was the issue I expected to be addressed in Gumbo.  I’d heard about the new “Spark” components.  The word “Spark” carried connotations of “lightweight”, and “rapid”.  So I was hopeful that Adobe were moving away from Swiss-army-knife approach, in favour of something that empowers the programmer and their Object Oriented methodology.

But it doesn’t look like Gumbo gave us anything like this.  It will take a while for me to determine whether Gumbo is an improvement for the programmer (apart from the workflow with the graphic designer ).

Opening files in e2spreadsheet

A user has reported that they can’t open their saved work in e2spreadsheet.  There should be no problem opening files from within the application FILE->OPEN…,

but there is a workaround to allow you to open files by clicking on the file icon, or dragging it to the application icon, or on the dock.

Just manually add the extension “.e2s”.  So if your file was called “myspreadsheet” change it to “myspreadsheet.e2s”.

However, the user has reported that even with this workaround – they still can’t open their file.  So I need to know if the problem is widespread.

Is anyone else having this problem?  Please try it out.  Save a file from e2spreadsheet, (close the window), and open it again.  Let me know if it works or not on your computer.

……………………..

File saving in Adobe AIR is a little awkward because the browseForSave() method doesn’t have a typeFilter parameter (whereas all the other browseFor methods do).  So the AIR application programmer can’t specify a default file type.  There IS a workaround – appending the extension after the browse window.  I’ve done this in e2vector – but the workaround isn’t perfect.

Church Of The Flying Meta-Tag Monster

In “Blashphemy! Burn the Flex-hating heretic!”, I likened Flex evangelism to a religious cult.  If I pursue this theological metaphor, then Pure ActionScript developers, like myself, are clearly atheists.  Our choice is not dictated by faith or devotion to Adobe Flex.  Pure ActionScript is IDE agnostic.  It’s a pragmatic individual choice.  It does not blindly follow the congregation.  (Most information on Flex, most blogs and training courses, will focus on MXML.)

It is possible to utilise the Flex-framework and components, via a Pure ActionScript approach.  However, I am presenting Pure ActionScript approach here as an ALTERNATIVE to the Flex components.  Not a complimentary philosophy.

So, let’s compare the use of Pure ActionScript to the Flex/MXML (Flying Meta-Tag monster) approach.

The Ten Commandments of the Church of the Flying Meta-Tag Monster…

1. Thou shalt use meta-tags.

Flex evangelists will tell you that MXML is simply an equivalent way of expressing ActionScript.  (The apples vs. apples argument).  While this is true, and you can always express MXML as ActionScript, it does not work the other way around.

It is possible to automatically convert MXML script to ActionScript script.  So it is also possible to automatically generate ActionScript from a Flex Design View visual representation.  Yet Flex doesn’t include this feature for the benefit of Pure ActionScript developers who want to manipulate, resize and position their components visually.  Why not?

2. Thou shalt find me difficult to learn.

Actually, MXML evangelists often claim the opposite.  “MXML resembles HTML – therefore it is easy to learn.”  But in actuality, this resemblance is superficial, and it certainly does not prepare the novice for the finer points of MXML development.  But the similarity between ActionScript and other programming languages is much more profound.  For a software developer, the transition to Pure ActionScript is relatively painless.  Whereas MXML requires the user to ascend a steep learning curve, irregardless of their transferrable skills.

3. Thou shalt not produce a small file.

The Flex-framework is incredibly bloated!  Flex evangelists will claim that file size is irrelevant.  But at least the smaller, leaner, files produced using Pure ActionScript don’t keep you waiting, staring at a loading bar, while the application loads.

4. Thou shalt not create applications that run efficiently.

Ok, it depends how you write it.  But you have much more control over the computational load with a hand-crafted Pure ActionScript program.

5. Thou shalt not use any other IDE.

A Pure ActionScript application can be developed in Flex, Flash, or third-party IDE.  Or you can switch between IDEs, depending how you feel that day, or the phase of the moon.  This also means that you are free to re-use your code across IDEs, and collaborate on Flex-based projects, Flash based projects, work with other programmers, or graphic designers.

6. Thou shalt not target multiple platforms.

In Flex you decide at the outset whether your project is for the browser or the desktop.  Flex is dogmatically restrictive.  Suppose you have a Browser project, and you open a file that references AIR-runtime objects.  Flex will actually delete the include statements from your source code!

When I develop a Pure ActionScript AIR application, I write it first without AIR-runtime methods.  Then I include those methods within a main class that inherits the main class of the non-AIR program.  This methodology enables me to deploy my applications to either AIR or the browser, and to test most of my application without launching the AIR runtime.

Pure ActionScript produces a smaller file-size and lower computational load.  These are important considerations for adapting an application to a Mobile device.

7. Thou shalt not port thy applications to any other language.

It is easy to port Pure ActionScript code to another programming language.  But it is easier to pass through the eye of a needle than it is to port a Pure ActionScript / MXML hybrid.  Some developers have ported ActionScript programs to the iPhone.

8. Thou shalt be required to read the documentation daily.

This is my penance as a Flex contractor.  Sometimes, I’m required to make Flex components behave as if they were not Flex components.  If I’m very lucky, this can be achieved be overriding a method, or responding to an event.  Each Flex object has hundreds of documented properties, methods and events.  Each documented with a very brief description.  Sometimes, you can hit upon something useful by trial and error, just reading through the list, and trying out things that looks relevant.

The problem with the Flex components is that they are too complicated.  Adobe has tried to make them flexible and configurable, adding so many bells and whistles.  I would have preferred the Flex components to be smaller, simpler, with fewer parameters.  But documented from the point of view of a programmer who might want to override its methods.

9. Thou shalt not change the sacred private methods.

Sometimes, it’s not enough to treat a Flex component as a black box implementation.  Sometimes, you need to familiarise yourself with the code, and override private methods.  Why did Adobe make them private?  Why are they sacred?  Why not just protected?

10. Thou shalt not embark on sophisticated projects.

Flex makes simple things a little simpler.  But, In the author’s opinion, more sophisticated projects, and highly customised interfaces should be approached using Pure Actionscript.  It is easier to write a custom component from scratch than to change and rewrite custom Flex components to do precisely what you want.

As a hard-core Pure ActionScript programmer, it’s often quicker for me to write something that to search for, and understand, a third-party object.  (Why use a DataGrid? – when you can write a couple of nested for loops that set up a grid of TextFields.)

. . . . .

I set out to present a polarised and contentious argument, and to promote discussion.  But, the process of contrasting two approaches started leading me into constructive ideas about how the Flex environment could be improved for the benefit of Pure ActionScript developers.

Automatic generation of ActionScript from a design view and a simpler set of Flex components designed and documented for the programmer who likes to use inheritance and override methods.  If these Flex components were small and simple enough, then perhaps they could be appropriate for mobile devices, and Open Screen deployment.

An introduction to e2spreadsheet

This is my second video.  A quick tour of the features in e2spreadsheet.

This application has been around a long time.  It was originally written for flash 5, it was ported to Macromedia Central and then to AIR.

e2spreadsheet can be downloaded from here.

An introduction to e2vector

As promised, here is a video tour of e2vector’s features.  Occasionally, I’ll also twitter about hints and tips for using my AIR applications.

e2vector can be downloaded from my website.