What we do is calling Flash/Flex APis through a custom FABridge (That we are planing to contribuate soon). So at the of the day it still a Flash/Flex application but not written in ActionScript/MXML. You can have a look at a demo here : http://flex4j.appspot.com/
For AIR we wrapped the AIR JS API with GWT JSNI(JavaScript Native Interface) This has helped us bring more Java devs to the Flash platform then we used to do with the MXML/AS3 approach. 2012/11/16 Gordon Smith <gosm...@adobe.com> > Did you use some HTML/JS implementation of native Flash/AIR APIs such as > Sprite? > > - Gordon > > -----Original Message----- > From: Alain Ekambi [mailto:jazzmatad...@gmail.com] > Sent: Friday, November 16, 2012 2:43 PM > To: flex-dev@incubator.apache.org > Subject: Re: Flex 5 in haxe > > We dont use ActionScript/MXML at all. > > ActionScript/MXML were not scaling for our customers(most of them use > J2EE) so we exported the Flash/AIR/Flex API to Java using GWT giving > their devs the ability to write Flex using the tools they are familiar with. > > > > > 2012/11/16 Gordon Smith <gosm...@adobe.com> > > > > we have a different approach to Flex development > > > > Can you elaborate on that a little? > > > > -----Original Message----- > > From: Alain Ekambi [mailto:jazzmatad...@gmail.com] > > Sent: Friday, November 16, 2012 2:22 PM > > To: flex-dev@incubator.apache.org > > Subject: Re: Flex 5 in haxe > > > > @Gordon > > We actually see an increasing interest in Flex/AIR coming for our > > customers. > > With the small team that we have we actualy cant keep up with the > requests. > > But i have to say we have a different approach to Flex development tho. > > > > > > 2012/11/16 Alex Harui <aha...@adobe.com> > > > > > > > > > > > > > > On 11/16/12 1:52 PM, "Fréderic Cox" <coxfrede...@gmail.com> wrote: > > > > > > > I'm glad Alex is here because I believe he does not only have the > > > > experience but also great ideas where Flex should be headed. And > > > > he might have been blocked previously by business decisions but > > > > now can take Flex to a even higher level. > > > > > > > Keep in mind that I'm the biggest proponent of the full re-write. > > > We may still find a few performance mistakes in the current code > > > (like the Chart styles init that just got fixed), but really, some > > > very smart people have spent a lot of time on the current code and > > > haven't > > found any easy wins. > > > IMO, the framework is slow because lots of code is running just in > case. > > > This is especially true for mobile apps where you have the most > > > constrained runtime environment. The issue that came in today on > > > the users list about slow List performance I'm sure is in part due > > > to TextLine being a bit slower, but probably more due to lots of > > > other code > > running as well. > > > > > > Plus, as many have recently said, the intertwined code we currently > > > have makes it hard for the volunteer to be successful in their spare > > time. > > > > > > I tried the big refactor and it was too difficult for me, but one of > > > the main difficulties was the fact that there was lots of other > > > development going on in the trunk at the same time and keeping my > > > branch running was nearly impossible. It could be that there won't > > > be as much active development in Apache Flex and a refactor branch > > > will be manageable, but the other problem you run into is that every > > > line of code is needed for some reason at some point, and you tend > > > to start leaving code in. > > > > > > Starting over definitely has its risks, but I think it will have the > > > best outcome. It won't make 100% parity ever and I'd shoot for 80% > > > over two or three years. But it will be designed to port to other > > > platforms, and be modular so the volunteer has a chance of making a > > difference. > > > > > > -- > > > Alex Harui > > > Flex SDK Team > > > Adobe Systems, Inc. > > > http://blogs.adobe.com/aharui > > > > > > > > >
