Alex,
> 1) It is hard to follow these threads without more context. I think Royale
> is going to require that folks make it clear which components they are using.
> Flex always had a primary set (MX then later, Spark) so we could make
> assumptions about what components you are referencing.
That makes sense, on our Flex side of the house we stayed as much as we
could on the spark components. If you needed a complete listing of those we
could produce one, but probably wouldn't be helpful in this thread since I was
referencing Royale items and more specifically Jewel versions of them for the
most part when I references the "Alert, PopUp, SnackBar, ToolTip" part. I was
not being clear enough when talking about the Apache based projects vice our
own corporate internal resources / libraries. I will work at being more clear
between all of these but making references to Royale, Jewel, Flex, or Air for
SDK clarity and can use terms like internal / organization for our end user
requirements.
> 2) The Basic components don't have a PopUpManager (yet) because nobody needed
> one. Simple stacking and unstacking of popups doesn't require a
> PopUpManager. In Basic you use org.apache.royale.utils.UIUtils. The
> emulation (MXRoyale) set has a PopUpManager that tries to emulate the Flex
> PopUpManager. I just saw it work. Jewel can have its own way of managing
> popups.
Our organizational popup management is more complicated than stacking and
unstacking. We will require something that manages popups and layers / sets of
popups. For issues we have seen internally such as having things like
notifications appearing behind a modal popup because of the Flex PopUpManager
opened the notification/popups at the same time. Or maybe there is a longer
term notification showing file uploads / download status that needs to always
be in the foreground. In the Flex side we added an additional manager which
would correct layering issues by reordering items in the stack if it detected a
problem, but that required something checking or updating after each popup or
notification is created / removed. If we have to reinvent the wheel for our
organization while using Royale we might create our own PopUpManager. We
definitely will not use something that emulates the Flex PopUpManager since we
could make one that handles all the different sets of layers we use to ensure
certain types of popups are always on top regardless of the current stack.
That would combine some of our managers and make it much more efficient for us
internally.
Array stacks like using zindexes in a way to keep certain items on top of each
other. (Value ranges shown just for being descriptive of the concept)
zIndex of 1000 - 1999 Standard popups and modal background layers.
zIndex of 2000 - 2999 Notifications, toasts, and snackbar's layers.
zIndex of 3000 - 4000 Critical application errors / complete stoppages / etc...
> 3) mx.collections.ArrayList and mx.collections.ArrayCollection are emulations
> of the Flex version. I'm not inclined to add new features to it. However,
> there should be no hardcoding of those classes ?outside of the emulation
> components, so folks not using the emulation set should be able to just use a
> different collection implementation, and if they use the same classAlias,
> Royale's AMF should be able to use it now that Greg got IExternalizable
> working. So, if you want a different way of handling changes to the
> collections, take a look at the Basic collections or write a new
> implementation. In ?Royale, we want to try to make it such that there is no
> one single implementation that everyone must use.
Sounds like a good idea, we will just write our own organizational
Collection class so we can add/remove functionality. We do not like the way
Flex ListCollectionView did business with queued events in a giant pile
(example being the private function handlePendingUpdates in
ListCollectionView.as), we had to add special handling to some of our
components that would ignore these events sent by a ListCollectionView and wait
for a separate event to handle the changes. The only event that the
ListCollectionView took into was the CollectionEventKind.UPDATE. It would
create an array of those queued collection events and send out 1 event with all
the changes in it. There are even comments in the ListCollectionView.as file
describing a need to come back and optimize the way it handles events, because
whom ever created that piece of code/sdk knew there could be times it would
send out a large volume of events.
I agree we don't need the Royale / SDK copy to be hard coded, it can stay
the way it is now and is intended to be. Our internal organizational libraries
will all be hard coded to standardize the features available. We chose to keep
the bead strand usage because we liked the way the beads were encapsulating
segments of code, so we hard coded the bead assignment internally. An example
of an organization component we've created for our test is an inherited copy of
a jewel TextInput. We hardcoded it with the Disabled / Restrict / TextPrompt /
ToolTip beads references to make it always contain those features and allowed
us to put in convenience getters/setters for things like
enabled/restrict/prompt/toolTip. However the references are null until a
setter is used the first time then it creates / adds the bead one time, so
processing wise its lighter until used, even if the download is larger.
Just to be clear, I'm not looking to use the emulation component to replace
stuff like this. I would like to use some of the new SDK components, but with
added compatibility we gain from making inherited organizational versions. I
just want the standard properties to exist by name so when we do our app
conversions (18 apps) later this year we only will have to change library
references, some support code for the views, 100% of the layout containers for
the views.
-Mark K
-----Original Message-----
From: Alex Harui [mailto:[email protected]]
Sent: Wednesday, March 20, 2019 5:00 PM
To: [email protected]
Subject: [Non-DoD Source] Re: PopUpManager question
A few thoughts...
1) It is hard to follow these threads without more context. I think Royale is
going to require that folks make it clear which components they are using.
Flex always had a primary set (MX then later, Spark) so we could make
assumptions about what components you are referencing.
2) The Basic components don't have a PopUpManager (yet) because nobody needed
one. Simple stacking and unstacking of popups doesn't require a PopUpManager.
In Basic you use org.apache.royale.utils.UIUtils. The emulation (MXRoyale) set
has a PopUpManager that tries to emulate the Flex PopUpManager. I just saw it
work. Jewel can have its own way of managing popups.
3) mx.collections.ArrayList and mx.collections.ArrayCollection are emulations
of the Flex version. I'm not inclined to add new features to it. However,
there should be no hardcoding of those classes outside of the emulation
components, so folks not using the emulation set should be able to just use a
different collection implementation, and if they use the same classAlias,
Royale's AMF should be able to use it now that Greg got IExternalizable
working. So, if you want a different way of handling changes to the
collections, take a look at the Basic collections or write a new
implementation. In Royale, we want to try to make it such that there is no one
single implementation that everyone must use.
HTH,
-Alex
