so the the long journey has come to a milestone. Xojo API2.0 has shipped GA (general availability). aka it is released to the general public for use. and for those of us not paying attention to what API2.0 is, it is a mixture of classic framework plus some new framework. in theory the new framework could be killed once iOS is migrated to API2.0. personally I really dont like the new framework as it reminds me of java. and I hate java with a passion.
this milestone is a big one for Xojo. congratulations on the win.
there were hundreds if not thousands (to be honest I didnt count them all - but I read numbers like 1,500) of changes from API1.0 to API2.0. I know that sounds daunting but its isnt as bad as it seems. most of the changes are to rename methods to a new name. why? I guess to be more clear, maybe. maybe to be more consistent across the framework. cant say for sure.
I am not going into details about the various changes as people that are smarter than me have already done so. (in no order…)
here is the common theme/synopsis. some name changes make sense, and some dont. ( and I am looking at arrays and their name changes make absolutely no sense to me ). they renamed all (or at least most) of the events for windows/controls to make it clearer of when/what they are doing. like
.Open is now
.Opening. why? as open didnt tell us when during the opening process the event occurred. still doesnt but hints its during the opening process. one of the major stumbling blocks of API1.0 is somethings are 0-bases (zero) and some are 1-based (one). and remember which one is which was painful for many. now them all being 0-based is awesome. we all know what to expect.
if you start an application is 2019R1.1 or before, you can still use API1.0 framework, no matter which IDE you use. if you start an application is 2019R2 (or later), it will only use API2.0 and have to use 2019R2 (or later). OUCH that makes it more difficult to have backwards compatibility. so most of us will have 2019R1.1 on our systems for now till a very long time in the future.
between the event and method changes in the API1.0 to API2.0, it really hurts plugins/controls makers. you cant have an
.Open event in API2.0 systems and you cant have an
.Opening in API1.0 systems and you cant have both on your control. so which one do you do? I have several custom controls that I use in my various apps that I now need to have 2 versions of. API1.0 and API2.0 versions. now I can delay that second version for a little while but starting all my apps in 19R1.1 (or before) and let it use API1.0. but still I am running on technical debt. the concept that you are relying on depreciated APIs/frameworks/code that is not going to be supported in the future (or even work).
so I think overall API2.0 is a good thing with a few cavoites. I hope this makes the ability to get WEB2.0 and Android out sometime before I retire. but i am n ot holding my breathe
I cant wait till 2019R2.1 or 2019R3 (whatever is next) so the documentation can get better. the example code still has remnants of API1.0 in it. and that is confusing as hell to newer programmers. and it confuses use more experienced programmers moving from API1.0 to API2.0