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" <yishayj...@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&data=02%7C01%7Caharui%40adobe.com%7C15793c03b3694bfc09a108d5eca537f5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636675116702561539&sdata=ngMi2ZZgmK%2FmhOkOv9f%2B6qYxx3JtD2J0gJLMb%2BA27ak%3D&reserved=0
