Hi Carlos, Looking at the screenshot Alina shared, plus some past discussion, lots of folks just used the default skins. I don't think they care too much if the Royale skin looks like Spark or not, but those who disagree should speak up now.
s:Button has over 100 APIs. Many of which are inherited from Flash Sprite. It would take us a long time to replicate everything. On the other hand, many folks use s:Button in mxml with only a few attributes, and a bunch more also reference it in their code to dynamically manage the UI. ArrayCollection may or may not be that different from s:Button. I've definitely seen ArrayCollection used in fx:Declaration blocks in MXML. Seems like a simple search and replace should also work here. If that's too risky, then it is time to find a volunteer to mimic these classes using the same package name. But in theory, 99% of your business logic shouldn't be working off of ResultEvent handlers. The handler should be calling some entry point in your business logic. The key points here is, as I mentioned in the other thread, expectations and time. You want an org.apache.royale.collections.ArrayCollection? Go build it. Don't wait for me or Peter. We need to change the mindset that the components are being created by Adobe. They need to be created by everybody. You don't even need agreement from others. We've proven that the tool chain can handle different component sets. Create a component set or two that reduces the number of lines you have to change when migrating. On the technical issue: In order for ArrayCollection to support array access in Flash (myAC[0]) ArrayCollection extends Proxy. Array accesses call a function that has to do a string to int and then access the internal array. It is much slower than getItemAt. I have implemented Proxy in JavaScript. It has to make the same slow function call. There are alternative implementations available for JavaScript if you make certain assumptions. For example, if there won't be add/remove on the ArrayCollection, you could prepopulate the index properties on the instance. Might not be fast for 10,000 rows at conversion time, but access afterwards would be faster than getItemAt. And there are options in-between where for add/remove you take the time to repopulate the index properties. That is another reason in Royale we have beads and multiple component sets. We don't have to choose just one implementation. There might be a "ReallyFastArrayCollectionForImmutableArrays". And so on. My 2 cents, -Alex On 2/15/18, 1:44 AM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote: >Hi Alex, > >I assume that UX is very different and although we have a "s:Button" lots >of changes must be done, so in the end, I think people must rewrite UX. >But AS3 classes are almost the same (lots of vars type String, Number, >int, >Boolean,....and ArrayCollection). In this point, it will be a shame to >make >people to go each file making changes to get ArrayCollections to match >other classes methods and signatures... > >In the other hand, about internals of how ArrayCollection operates, I >think >that can be reworked in order to perform better, right? > > > >2018-02-15 9:20 GMT+01:00 Alex Harui <[email protected]>: > >> If the goal is to further reduce the number of changes to migrated code, >> we should just start a new component set. IIRC, ArrayCollection usually >> has very bad performance if you use array indexing to access it. >> ArrayList should perform much better but you can't use array indexing. >> Filtering and sorting should be written as beads. >> >> My 2 cents, >> -Alex >> >> On 2/15/18, 12:11 AM, "Piotr Zarzycki" <[email protected]> >>wrote: >> >> >Hi Carlos, >> > >> >We have ArrayList which is enough close to ArrayCollection. I have with >> >success replace ArrayCollection to ArrayList in my examples. >> > >> >Thanks, Piotr >> > >> >2018-02-15 8:47 GMT+01:00 Carlos Rovira <[email protected]>: >> > >> >> Hi >> >> >> >> I saw Alina post in user list about substitutes and I think one >> >>important >> >> one is: >> >> >> >> import mx.collections.ArrayCollection; //very similar to >> >> org.apache.royale.collections.TreeData >> >> >> >> In order to ease the port of Flex apps to Royale, one thing we try >>is to >> >> reuse as much AS3 logic, while in UX we need to create all new code >> >> >> >> ArrayCollection is very close to business logic, and widely used in >>AMF >> >> calls. >> >> >> >> I suggest we should have ArrayCollection in Royale and even respect >> >> namespace to avoid users to change any line in AS3 code. >> >> >> >> Only with this point we can remove lots of pain in migration process >> >>from >> >> Flex to Royale >> >> >> >> what do you think? >> >> >> >> -- >> >> Carlos Rovira >> >> >> >>https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me% >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C10ecbb5b8c464b4ed36708 >> >>d5744bcadb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> 7C63654279123032447 >> >>4&sdata=RY6LraL22n2Yt9QiNyJc0FQms64yALaKy16%2FNW7XHJc%3D&reserved=0 >> >> >> > >> > >> > >> >-- >> > >> >Piotr Zarzycki >> > >> >Patreon: >> >*https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fwww.patr >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com% >> 7C10ecbb5b8c464b >> >4ed36708d5744bcadb%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C6365427912 >> >30324474&sdata=mwO%2FFFYUAHHA8VlHeJQreNzUOMKzd% >> 2BeqaMV6%2FNPhIKk%3D&reserv >> >ed=0 >> ><https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fwww.patr >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com% >> 7C10ecbb5b8c464b >> >4ed36708d5744bcadb%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C6365427912 >> >30324474&sdata=mwO%2FFFYUAHHA8VlHeJQreNzUOMKzd% >> 2BeqaMV6%2FNPhIKk%3D&reserv >> >ed=0>* >> >> > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdebccabe22ef4904561808d5 >7458b8c1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636542846770085665&s >data=3o5OEwQO1Nxv3fIRjJ2BGa%2BZ8gHCVobqfeACbrhFsCI%3D&reserved=0
