Perhaps you don’t know, I’m the Tech Lead of the ELIPS Studio Product (feel free to try it for free here!) . For those of you who have already jumped on board, I really hope you enjoyed the first releases we have posted …and you have as much fun playing with it as we have building it!
We are pretty busy right now bringing some exciting stuff to the table, like, well, as promised the iPhone.
I just wanted to share with you the approach we have selected, and the path we are following.
iPhone : Widgets and the runtime part
We have decided to follow a different path than for the other platforms regarding widget handling.
As you all may know the S60 and WinMob widget toolkits are well, pretty dated and replacing it by some modern flex widget is a definitive plus. But in the iPhone case, this is the opposite, the iPhone has a very comprehensive, modern and user friendly widget toolkit, with physics, hardware acceleration, etc…and Apple requires you to use it to pass its dreaded Appstore approval.
So we had two choices here:
- Redeveloping, in Flex the iPhone widgets so applications will “as much as possible” look like real iPhone ones, or ..
- Mapping the Flex UIComponent widget tree directly to real iPhone widgets to leverage the platform strength
The first solution has its advantages, like code reuse accross platforms, consistency when developing in the simulator vs a real phone opposed to the second one which is requiring a much bigger porting effort, impossibility to precisely simulate the application, BUT when you do an application at the end, it really feels like a real Objective-C one, following iPhone standards … but coded in AS3.
So yes we’ve taken the hardest path: we have followed the native widget route … and we are pretty happy about that
The biggest issue with such an approach is for us, not for you: this is the porting time. We have to map all the iPhone widgets with their yet to be created MXML counter part and implement those new MXML widgets in a generic form (read pure AS/MXML) for the other platforms.
Today the iphone list is mapped, meaning that you simply have to declare a list with your own item renderer, data provider everything you know and love … and it will look and behave like a real iPhone list, with its unmatchable physics and hardware acceleration for smooth scrolling. Look at the following video for a very simple list with an item renderer in Flex and a data provider …no iPhone code at all but a real iPhone list anyway
Text entry (in place and not in place) is ported too.
Of course all the “normal”, non mapped widgets are working well and can be completely and transparently mixed with the native mapped one: you won’t notice the difference.
And we are at that point: Shall we release it to let people try it even though a lot of widgets are not mapped? Or shall we work a little bit more to map all iPhone widgets?
iPhone : the toolchain
As you have noticed, for now, our tools are Windows only (just to let you know I’m writing this article on my Mac ). Perhaps as you know too from our documentation we are compiling the MXML/AS to C++ for the applications, but also to develop our runtime and libraries: for the iPhone we have simply used our compiler and tools to generate a bunch of C++ files from our Flex SDK, alongside an XCode project then we transfer it to a Mac and we are able to build a fully native iPhone application, right from XCode, running in simulation and on device with C++ debugging….sweet.
In that case, for the application developer, the flow is:
- Develop in FlexBuilder With ELIPS Studio plugin on a PC (or better on a Mac, in a Windows VM, like Parallels, my favorite, or VMWare)
- Generate the C++ files from your MXML/AS with the ELIPS Studio build button
- Put this source tree on a Mac (if you were working on a VM … simply put it in a shared folder of your VM)
- Open it in XCode, build, simulate, debug, deploy on the Mac
Of course in parallel we are working on a full Windows only toolchain, based on one of the patented unique OpenPlug technology: platform independent software components (used today in our WinMobile and Symbian platform and on Android also, oups, yes I’ve said that too look at the video , exact same list code as in the iPhone video, but in “Flex Only” mode, no natif mapping, pure MXML/AS for the list implementation:
Look at the performance on a G1 ).
Bottom line, we are wondering if it makes sense to release the current hybrid toolchain, or in the contrary wait for the integrated one.
iPhone : the next steps … tell us what you think!
So here we are today: we are able to release an iPhone technology preview, with a limited set of native widgets, and an hybrid toolchain.
Beside this, the iPhone roadmap is pretty clear (and we are already progressing on it):
- Complete the UIComponents mapping to have all the iPhone widgets available
- Complete the Windows only iPhone toolchain
- …Port our tools under Mac, at least for iPhone development
I hope those insights helped you understand how our iPhone support will be completed, and I really would like to have your point of view and comments (either via twitter, in the forum or in this blog post):
- Are you willing to try our first shot for iPhone dev, with its limitations (very few native widgets)?
- Are you ready to develop in such an hybrid environment?
We need your feedback!