Your milage may vary, but I actually found that my code improved when I was forced to convert ArrayCollection to ArrayList. Some cases did not really need collections at all, and I did not really use ArrayCollection features anywhere. Being forced to use getItem() rather than indexes made the code clearer. The only issue I had was getting rid of uses of refresh() (which caused me to optimize some things) and replacing Sort with native Array sorting (which is also not a bad thing).
None of the cases where I had ResultEvent and FaultEvent really made a lot of sense to keep that logic in Royale (events should generally be of type Event), so keeping those events would just mask places where code should probably be rewritten. What I did while migrating my code was create dummy classes for these events (with constants). This allowed me to analyze where they where being used while eliminating compiler errors. My $0.02, Harbs > On Feb 15, 2018, at 11:38 AM, Carlos Rovira <carlosrov...@apache.org> wrote: > > Hi Piotr, > > I considered that scenario, but the fact that this classes (ArrayCollection, > ResultEvent and Fault Event), are so close to Flex and to what all people out > there like us did to build their Apps, ends make me think that this is our > task to make this as easy as possible. We are not talking here of a flex > third party component or class that some people was using. We are talking of > some core framework classes that are present in almost all Flex apps. > > So if we want to ease migration of flex to royale, this is a huge point to > consider since it will be lots of DTOs (or VOs or value objects or POJOs) out > there that can be copied without any modification, and the same for > Controllers that works with HTTPService, RemoteObject or WebService > classes...as well lots os BusinessDelegates, and other classes that are close > to the server communication part of the Royale client code. > > If we don't create counterparts those means lots of changes in code bases and > not only recreate UI-UX with mxml and new UI sets... > > So I think this is important not for concrete users, but for Royale as a > project that has an important task in make as easy as we can ports from Flex > to Royale. > > > > > 2018-02-15 10:30 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com > <mailto:piotrzarzyck...@gmail.com>>: > Carlos, > > I believe it is the matter of trying. Harbs did try and replace his > ArrayCollection without the problem with ArrayList. I did try it with some > demo apps and it went well. If you start your migration and face a wall - it > doesn't have to end up with solution where you adding some things to Royale. > You can always implement ArrayCollection in your application and use it. > > My thought is that not everything need to be part of Royale. :) > > Thanks, Piotr > > 2018-02-15 10:25 GMT+01:00 Carlos Rovira <carlosrov...@apache.org > <mailto:carlosrov...@apache.org>>: > Hi Harbs, > > mostly agree but for me ArrayCollection, FaultEvent and ResultEvent are very > close to the business logic we don't want to migrate or try to left > untouched. > I think that three classes should have Royale counterparts to reduce > migration pain. > > I'm talking more from a user role or someone that wants in the end make the > same Alina is doing with our Avant2 app at Codeoscopic > > thanks > > > 2018-02-15 10:15 GMT+01:00 Gabe Harbs <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>>: > CloseEvent,FaultEvent and ResultEvent are not really needed in Royale. Royale > takes a much more “laid back” approach to Events and only creates new Event > classes when they are absolutely needed. > > 99% if the uses of ArrayCollection can be replaced with ArrayList which > exists in Royale. > > Sort and SortField do not exist, but I’ve found that I was able to replace my > uses with a simple Array sort. > > For Alert, you can either use Alert or SimpleAlert. Another option is an MDL > Dialog. > > StringUtil is a direct port from mx. The functions in StringUtil will > gradually be deprecated in favor of package level functions. > > Make sure you really need PopUpManager. Like was already mentioned, you can > probably just use addElement(). > > HTH, > Harbs > >> On Feb 15, 2018, at 9:06 AM, Alina Kazi <alina.k...@d-bz.com >> <mailto:alina.k...@d-bz.com>> wrote: >> >> Hi, >> >> I have replaced few imports in Apache Royale Project after comparison in >> terms of functionality. >> As you all are more familiar to Flex and Apache Royale. >> Are these correct substitutes? >> import org.apache.royale.html.Alert; //instead of import mx.controls.Alert; >> import org.apache.royale.events.CloseEvent; // instead of import >> mx.events.CloseEvent; >> import org.apache.royale.net.events.FaultEvent; // instead of import >> mx.rpc.events.FaultEvent; >> import org.apache.royale.net.events.ResultEvent; //instead of import >> mx.rpc.events.ResultEvent; >> import mx.collections.ArrayCollection; //very similar to >> org.apache.royale.collections.TreeData >> import mx.collections.Sort; // No Alternate found >> import mx.collections.SortField;// No Alternate found >> import mx.managers.PopUpManager; //org.apache.royale.core.IPopUp or >> .IPopUpHost >> import org.apache.royale.utils.StringUtil;// instead of import >> mx.utils.StringUtil; >> >> Reference: >> http://apacheflexbuild.cloudapp.net:8080/job/Royale_ASDoc_Example/lastSuccessfulBuild/artifact/examples/royale/ASDoc/bin/js-debug/index.html >> >> <http://apacheflexbuild.cloudapp.net:8080/job/Royale_ASDoc_Example/lastSuccessfulBuild/artifact/examples/royale/ASDoc/bin/js-debug/index.html> >> >> Thanks, >> Alina Kazi > > > > > -- > Carlos Rovira > http://about.me/carlosrovira <http://about.me/carlosrovira> > > > > > -- > Piotr Zarzycki > > Patreon: https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki> > > > -- > Carlos Rovira > http://about.me/carlosrovira <http://about.me/carlosrovira> >
