Ok, so if I tell you that eyeGT + b.Tween will make it possible to port Flash and FlashLite content to the iPhone/iPod Touch as native applications, you don’t need any more explanation right?
Maybe not, judging from the huge number of emails I’m getting and the posts I read on the various blogs.
The lack of information is completely our fault however….. until today Barefoot Software has been dealing almost exclusively with telecoms and handset manufacturers to deploy custom applications on mobile platforms. We have never had to explain too much detail on our website as executives generally don’t know how to use a web browser right?…. Just kidding of course!!!
Everything started with a very cool application made by Thomas Joos of Boulevart, a mobile guide to the Rock Wechter concert that will take place in Belgium from the 3rd to the 6th of July. Thomas designed and created the original Flash Lite version running on Nokia phones. Using b.Tween it has quickly been adapted and compiled by Barefoot - directly from the Flash Lite version into an iPhone/iPod Touch native application…. we were supposed to just briefly touch on the b.Tween process in this blog as for the moment our main web site is not yet ready to be assaulted by flash and iPhone enthusiasts but Thomas could not resist [bless his soul] and things are now moving very quickly….
What is eyeGT? (short for “Enhance Your Experience - Graphical Toolkit”) - this is explained in the post below but as a short summary: “eyeGT is a highly efficient graphic renderer, capable of handling vector graphics and bitmaps. Beside the basic services of rendering, eyeGT provides a very extensive API that allow to define: buttons, animations, hierarchical containers, color and special effects, static text, editable fields and much more; think about it as a Windows GDI+ or Mac OSX Quartz2D on steroids, heavily optimized and designed from the ground up … for mobile.”
You may have heard a lot about of other toolkits available that perform similar sorts of things on desktop PCs (my favourite is AntiGrain) but eyeGT is very different and not only in terms of speed.
eyeGT is completely self contained. It does not use 3rd party code like FreeType for fonts (like AntiGrain) and offers a “flat” interface to developers: it never returns pointer to objects, requires you to setup complex classes or intricate design scheme. It is impossible to create applications with eyeGT that have memory leaks or crashes (this is a big claim…… I know, but let’s just say that you really have to apply yourself to crash an eyeGT based app).
- eyeGT comes in the form of a single DLL, Shared Object or FrameWork depending on the platform. [by the way we support many other platforms - not just iPhone/iPod Touch
- Nokia 2nd Edition (6600, 6680, 6630 etc)
- Nokia 3rd Edition (whole range including Feature Pack 1 & 2 models)
- Sony Ericsson UIQ2.x e UIQ3.x (including P800, P900, P910i, P990, W850, W950, W960, P1 and others)
- Motorola Z8 e Z10
- Microsoft Windows Mobile (every smartphone and PDA based on Windows Mobile 5, 6, 6.1 e 6.1 Pro)
- Apple iPhone e iPod Touch
- Nintendo DS (original and Lite)
- Sony PlayStation Portable
- GamePark’s GP2X F100
- Many phone models based on MontaVista Linux and is available to be ported on other embedded platforms as the base requirements are very minimal.
What eyeGT is NOT..
NOTE:: eyeGT is NOT a Flash compatible player or Virtual Machine. It doesn’t pickup a SWF file and “play” it.
Not making it as a “player” was a design decision we took over 8 years ago when we first produced our graphical engine designed to display vector nautical chart with quite stringent constraints: 256 KB ram and 33 MHz processor (I can hear somebody laughing..).
Over the years eyeGT has evolved and scaled considerably without compromising speed and quality and although we had more than a few request in the past to implement a sort of integrated scripting engine, and although we generally liked the idea, we resisted doing it. The reason is simple: when an application is written for a player or VM, it is effectively “trapped” inside the environment and has no possibility of accessing the outer world. Sure it is possible to expand the player with new capabilities to provide those services from within the player - but only VM producers can do it. This solution is also very painful to maintain across all supported devices and unless you can invest in making a JIT compiler, the scripting language can be very slow. Further more, the player already needs to be present on the hosting platform before your app can be deployed and be able to be executed can be problematic to have different versions of the same runtime installed in the same device. That’s exactly what we wanted to avoid at all cost.
Given our long experience in the mobile field, we have noticed that the vast majority of code that makes up an application is GUI related code and that code is NOT portable. So, as you may guess, our intuition was: what if we have something that can leverage and abstract GUI code, making it portable across various embedded systems and we can produce fully native and fast applications without compromising with the typical problem of “closed” player solutions? eyeGT was born!
Does Flash play any role into our application design/making process? Absolutely! We generally start by sketching up the app following customer requirements using Flash, we then produce a quick mockup right on the handset showing the look & feel and some basic interactivity. The application is then refined, tested and the the Flash content is translated into resources that eyeGT can use; finally the logic of the application is coded in C++. Simply put - by following some simple rules we are able to keep the application “platform independent” - so while we don’t enjoy the only theoretical “Write Once Run Anywhere”, we properly enjoy a model of “write once - compile many and deploy everywhere”!
The final application is then packaged, eventually signed and released with no dependency whatsoever. EyeGT is so small that it can be deployed along with the application and the user is unaware of its presence. We put your brand forward not ours…
The first real test was in 2006 when Nokia was looking for an application capable of downloading and displaying so called "e-zines" or "mobile magazines" for their platform; I wont list here their requirements but trust me when I say they were VERY stringent. Together with PocketNET of Taiwan, a cross project between major magazine publishers likes Condé Nast, Financial Times, Vogue, GQ [and many others] and Nokia itself, the PocketBook Store saw the light only a few weeks after its design. The application has been released pre-installed not only on the original phone model it was designed for (Nokia N73) but also every Symbian 3rd and 2nd Edition phone that Nokia has released since then in Taiwan, with very minimal changes only dictated by the ever changing Symbian Signed criteria [more on this later]. For the official presentation over 200 journalists from all over China were invited to the press conference organized by Nokia itself; it was a very exciting time for us and a final verification that eyeGT is a very really solid and sound concept.
So what b.Tween has to do with all?
Even if eyeGT relieves a lot of the pain of coding the GUI by hand and then porting it across many devices, we felt that something was still missing. Quite a few developers that worked with us and eyeGT agreed that while it was great, there was not enough abstraction between GUI related code and the underlying “business logic” code. We then took the chance of designing a framework on top of eyeGT that could further enhance it. By this time Flash 9 was announced with support for ActionScript 3. This new version of AS was much closer to a full OO language and the underlying framework of classes was more or less what we were looking to do on our own. In the mean time Flash developers habits were changing also. Flash Developers were less and less relying on the ‘classic’ Flash timeline to make animations and applications using the infamous quantity of GotoAndPlay() and Stop() statements plastered throughout the movie and moved more to the scripting language to manipulate the appearance and GUI. So the idea was to recreate more or less the underling framework of AS3 in C++ and use eyeGT as the final renderer for the application. This model immediately provided several notable advantages:
- The code that uses the framework is compiled to machine code, this means performance several orders of magnitude faster than the ActionScript equivalent. (AS3 in Flash 9 is JIT compiled but we are talking about mobile platforms here where there is NO AS3 and no JIT compilation.. certainly for the moment at least)
- Parts of the code that are unused are left out of the final compiled application so size and time to transmit/load are reduced to a minimum
- Native code can access ANY feature of the hosting platform: need Bluetooth? Want to process received SMS? Want to read the phone book? This is all possible from native applications BUT not so from a player based version.
Simply put - b.Tween sits between eyeGT and the application’s business logic and provided for the rapid converting of AS3 based applications into native applications with minimal changes.
There is a lot more to document - and in future posts later this week I will explain how the process actually works. i.e. how we move from a Flash/FlashLite application to a native iPhone application.