royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Migrating Enterprise Flex Application
Date Wed, 18 Jul 2018 18:56:30 GMT
Top-posting to try to respond to all other posts in one email...

The goal of the emulation components is to emulate enough of Flex such that a migrated app
can go into production.  Words like "functional" and "subset" can be misleading.  Spark Button
has over 200 APIs.  The API Reports are showing that folks are only using 20 or 30 APIs. 
Those 20 or 30 APIs may not work exactly as they do in Flex, but the goal is to make them
work well enough so that the migrated app can replace the current Flex app and the managers/users
will be happy.  An example of what I mean is something I was working on yesterday:  In the
Flex MenuBar, once you click on a MenuBar item, the menu pops open, but if you then move the
mouse to hover over another MenuBar item, that item's menu will open (without clicking). 
This "scrubbing" functionality is not being emulated at this time.  A volunteer can always
write the code to do it, but I've chosen to skip it for now because scrubbing is of little
use on mobile devices and I'm not sure that scrubbing is essential to the success of these
apps.

I suspect we will never emulate all 200 APIs of Spark Button mainly because nobody is using
them (or 'must have' them).  The API reports mainly prioritize which APIs to emulate first.
 Apache projects like Royale rely on volunteer contributions from folks with limited time,
so we want to devise a development methodology that leverages that. By allowing folks to take
on smaller tasks like "emulate this one API from Flex" that is hopefully more manageable than
asking if there are volunteers to emulate 200 APIs.  If Royale becomes the choice for lots
of folks migrating from Flex, the set of APIs in Spark Button will grow as needed, on-demand,
by contributions from these volunteers.

We will help anyone learn how to make emulation components work.  It isn't hard, it is tedious
at times.  I will try to write up more about how to do it.

The key thing about the emulation functionality is that it reuses beads from Basic and Express,
and potentially Jewel.  This is one of the major payoffs of using composition and beads. 
If there is a Basic DateField or MenuBar, those same beads can be re-used in the emulation
components.  Sometimes as-is, sometimes by subclassing.  The current pain point is that re-using
the beads is exposing lots of places where the Basic beads make assumptions about the classes
in their strands. So the hard part will be teaching folks how to make the right decisions
in re-using beads.

I think at this point that Basic has a bead for just about all of the key Flex functionality,
so the effort to getting the emulation components to run isn't so much a challenge of writing
new functionality as it is about re-using the existing functionality.  The current emulation
components that work well enough to pass our smoke tests don't size the same as Flex and don't
have a nice default look yet.  I've deferred working on the visuals to see if there will be
reusable view beads from Jewel, and also because I think more of our volunteers are comfortable
tweaking visuals than re-purposing beads.

Regarding 3rd party libraries, IMO, replacing those is not a problem unique to Royale.  You
would have to come up with a replacement for those libraries even if you didn't use Royale.
 If those libraries do not have much reliance on Flash then it may be possible to get the
ActionScript source and have it "just work".  Once you choose a replacement library, we can
show you how to integrate it into your Royale app, and it should be much less changing of
your code than rewriting your entire app without Royale.

I said something like this before, but if you think about how much energy goes into every
line of code you write, once you get your code working, it is best if you don't have to touch
it again, so relying on the shared code below your code should be the lower cost and most
importantly, lower risk option.

My 2 cents,
-Alex

´╗┐On 7/18/18, 4:54 AM, "yishayw" <yishayjobs@hotmail.com> wrote:

    To be more precise, they will have a subset of the functionality. The API
    reports are supposed to help us find the relevant subset.
    
    
    
    --
    Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7C15793c03b3694bfc09a108d5eca537f5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636675116702561539&amp;sdata=ngMi2ZZgmK%2FmhOkOv9f%2B6qYxx3JtD2J0gJLMb%2BA27ak%3D&amp;reserved=0
    

Mime
View raw message