HI Mark,
If you want to contribute your PopUpManager to Royale or otherwise share it
with others, that would be great. Royale will probably not have a single
one-size-fits-all PopUpManager. Different implementations will hopefully
become available as folks like you implement them.
The Basic components have a Collection.swc that has an ArrayList that might
serve as a starting point for your collection needs.
HTH,
-Alex
On 3/21/19, 6:18 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil.INVALID>
wrote:
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:aha...@adobe.com.INVALID]
Sent: Wednesday, March 20, 2019 5:00 PM
To: dev@royale.apache.org
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
