Reading the latest blog post about “Your path forward with API 2.0” just reassured me that the pain API 2.0 brought to third parties was not understood. It puts those who create and sell code to others or who sell applications to a broad base of customers across many OS versions in a tough spot.
Xojo is a great tool. Many of us have said that over and over. In part what makes it great is that we can, from a single code base, support a diverse set of customers with a single code base. This is often critical to a third party working in the Xojo ecosystem. That ecosystem is just not large enough to focus solely on one version or one OS.
Often this means that we need to use new versions to support those customers who update to the latest OS the day it is released, and older versions to support those who choose to stay on older versions of their OS for whatever reasons.
Until now that has been a very simple proposition in Xojo. Xojo never deliberately did things that they knew would break code until or unless they absolutely had to. That changed dramatically with 2019r2 and API 2.0.
But now we can’t do that. Not just “we can’t do it well”.
We can’t do it at all. Certainly not for third parties that provide code to their customers.
And certainly not from a single code base any longer.
Those who want to update to the very latest version of Xojo want our products to support API 2.0 immediately. And those who use older versions need us to remain supporting the older API’s for now.
With the advent of API 2.0 that is actually not possible in a single code base.
The only reason its not is because of the events that were renamed. Everything else could have been handled invisibly to our users with #if Target or #If Xojo version conditional compilation.
Just. Not. Events. 🙁
So there are third parties that simply aren’t updating their products today because doing so would cut their customer base significantly. Not because they don’t WANT to update. But because doing so would hurt their business and their customers.
Others may not provide code but instead create bespoke applications. Their customers may be using the very latest OS versions or really old ones for many reasons. Once again the only option that these Xojo developers have is to avoid using API 2.0 because once they do so they cannot go back to old Xojo versions to update their products for their customers. They can’t use API 2.0 at all. Certainly not any of the renamed events. And they may not be able to even use the latest Xojo versions for anything but a “compile only” option as editing their projects in 2019r2 introduces so many changes that they cant make heads or tails out of their version control system change logs.
All these concerns were voiced during the betas for 2019r2. And apparently fell on deaf ears.
Anyone trying to support users of their code or products across multiple versions of Windows. macOS across many versions of Xojo is simply not possible in a single code base. We’ve been asking how to do this since betas started appearing with API 2.0 and have so far had no response that acknowledges that API 2.0 creates this problem.
So far it seems that Xojo’s advice is “update to 2019r2 and the world is all sunshine and light”. But its not. Not for anyone that has to support customers that may have no choice about NOT moving up to the latest version or cannot move up to the latest OS. 20192 and API 2 are a non-starter in that case despite what Xojo Inc tells us.
The only other choice is to create two ce bases and try and keep them in sync between the API 1.0 code and API 2.0 code. This effectively doubles everyones work load.
And brings few benefits for that doubled workload.
The old APIs continue to work and, as noted in the Xojo bog post,
Many deprecated APIs still share their implementation with the API they replace.
https://blog.xojo.com/2019/10/29/your-path-forward-with-api-2-0/
many third parties are just not touching API 2.0, or 2019r2, for now and are just supporting the old API’s for now since that makes is possible for every Xojo version to use their code.
This situation didn’t have to exist. But, as Bob notes, feedback given during betas seems to have been ignored.
I’m truly disappointed.
EDIT : As was pointed out to me off the forums & lists I neglected to mention that the rename of properties also causes issues. Not quite the same issue as events but still significant backward & forward issues.