Yeah, I think so, but I think that's no problem since we want in this part maximum compatibility so people could use royale with the server they use for flex with almost not changes (just use ArrayCollection if they use MX or use ArrayList if they use normal Royale UI APIs)
El jue., 21 feb. 2019 a las 18:45, Greg Dove (<[email protected]>) escribió: > Sounds good, Carlos. > > Actually as another implication... > This does mean that I am also adding IExternalizable to > > org.apache.royale.collections.ArrayList > > and obviously uncommenting/adding to > mx.collections.AC > mx.collections.AL > > I don't think there is any 'PAYG' way to do that which would be compatible > across targets, I just need to add this. > > But I do think the same IExternalizable interface with IDataInput and > IDataOutput could be used for different serialization formats in the > future... > > > > > > On Fri, Feb 22, 2019 at 6:09 AM Carlos Rovira <[email protected]> > wrote: > > > Hi Greg, > > > > that's great. In that way I can test about our app as a first step, then > if > > all goes ok, I can try a second time turning on small messages to try > > IExternalizable. Finally I can as well enable compression :) > > > > El jue., 21 feb. 2019 a las 17:54, Greg Dove (<[email protected]>) > > escribió: > > > > > Hi Carlos, > > > > > > Thanks for your comments. Sure, I have things set up in a local > branch, I > > > was just hoping to get feedback as to whether I needed to use that > > remotely > > > or not. > > > > > > So I will do that. > > > > > > > > > > > > On Thu, Feb 21, 2019 at 10:13 PM Carlos Rovira < > [email protected]> > > > wrote: > > > > > > > Hi Greg, > > > > > > > > that sounds to me like an amazing work. Thanks for working on this. > > > > > > > > I think the best way to integrate this should be creating a branch so > > > Harbs > > > > and others could adapt the other code to the new API changes, and > > commit > > > to > > > > that branch that fixes (if there are located in our repo) so all is > > > working > > > > when merged. Or all could test our code against those changes and try > > to > > > > adapt what we see in our code and report if we find any problem that > > > should > > > > be taken into account before merge. > > > > > > > > Don't know the uses behind that, but seems that knowing how we should > > > > change the existing code should make us adapt to the new changes fast > > and > > > > easily. > > > > > > > > About reflection, I tried some months ago to do some work on that and > > as > > > > you said, I found some parts was not working. So great to see you > fixed > > > > that as well :) > > > > > > > > I think getting APIs more close to the original flash but all in a > > Royale > > > > API would be good for all since we'll get other step close to ease > > > > migrations. > > > > > > > > Thanks and can't wait to see that code! :) > > > > > > > > > > > > > > > > El jue., 21 feb. 2019 a las 9:15, Harbs (<[email protected]>) > > > > escribió: > > > > > > > > > What did you change? I’m using these methods, so it’s significant > to > > > me. > > > > > > > > > > > On Feb 21, 2019, at 7:20 AM, Greg Dove <[email protected]> > > wrote: > > > > > > > > > > > > I had to change the writeBytes/readBytes method signatures. > > > > > > The original method signature is still available but will become > > > > > > writeBinaryData/readBinaryData > > > > > > > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > http://about.me/carlosrovira > > > > > > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > -- Carlos Rovira http://about.me/carlosrovira
