Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of coxfrederic@gmail.com
 designates 74.125.82.43 as permitted sender)
User-Agent: Microsoft-MacOutlook/14.2.1.120420
Date: Fri, 16 Nov 2012 23:40:15 +0100
Subject: Re: Flex 5 in haxe
From: =?ISO-8859-1?B?RnLpZGVyaWM=?= Cox <coxfrederic@gmail.com>
To: <flex-dev@incubator.apache.org>
Message-ID: <CCCC7CF2.46DC3%coxfrederic@gmail.com>
Thread-Topic: Flex 5 in haxe
In-Reply-To: 
 <CAGw=_tx0uL50K8O-tk=-kTedOC-g=A=2jGqUqy_f1t2CDiRsYw@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

@Gordon, Alex,

We are also creating new apps as well as maintaining older ones. We
previously created web-only OR mobile-only apps. But lately we are
creating a library project which holds 95% of the code and 2 specific
projects for mobile and AIR versions of the app. Just today I presented a
sales application where our sales team can sign contracts with clients
using an iPad app and even manage the same data from the same app on their
laptop. The only difference is a native extension in the mobile version
which adds a meeting in the iOS calendar. It is pure brilliance and
management was very satisfied with this. For a new project we will create
a project where users can upload photos, video and send them to us
(something like WeTransfer.com but more specific to our company) and this
will be both mobile as desktop with the same codebase (and only one
developer working on it, just like for the sales app. It's rapid
development nonetheless)


On 16/11/12 23:22, "Alain Ekambi" <jazzmatadazz@gmail.com> wrote:

>@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 <aharui@adobe.com>
>
>>
>>
>>
>> On 11/16/12 1:52 PM, "Fr=E9deric Cox" <coxfrederic@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
>>
>>