Xojo 2020 Release 2

The second major release of Xojo 2020 landed this week.  This release is filled with changes that will make many Xojo developers very happy.  Let’s dig into some of the details.

To say that iOS had a major update doesn’t quite do it enough justice.  iOS is now using the global framework so the old Xojo framework is now deprecated.  What this means is that code shared between web, desktop, and iOS is now considerably more compatible.  Plus, iOS is more complete with many of the missing classes, like XML, TCPSocket, RegEx, to name a few finally make their way to the target.  And, perhaps more importantly the String and Variant classes can now be used instead of Text and Auto (and their requisite pain of usage).

This release also lays some of the groundwork for Android.  No longer are the classes named with an iOS prefix but now use the Mobile prefix.  Presumably whenever Android is released there will be many classes that crossover just like Desktop targets do right now.

Another big change in iOS is the ability to use plugins.  This allows plugin developers, like Monkeybread Software, to add an extreme amount of functionality to iOS that simply wasn’t available until now.  Simply looking at the Monkeybread website shows some of their biggest items available for iOS including Barcodes, Compression, CURL, DynaPDF, GraphicsMagick, SQL, XL, and XMP to name a few.  Expect more and better things to be available to your iOS projects in the future.

How well does iOS work?  I can’t really tell you.  I have several iOS projects that use some of the iOSKit extensions and it will be a fair bit of work, I think, to replace everything.  The sad part is that I’ll likely be forced to update them soon so I can release some client updates.  I’ll keep you informed of my progress and pain when I do that.  If you have some current experience with this iOS release please share your experience with us.

The R2 release also brings us the new Worker Class.  The Worker is a way to utilize more cores on your machine than using a traditional Thread can use.  Essentially you’re offloading work from the single core that your Xojo application uses and it starts a separate console application to do that work thus utilizing more cores on your computer.  You could always do this on your own using a variety of methods but this automates the process.

You start by creating a Worker class object and implement the events Error, JobCompleted, JobRequested, and JobRun.  When you want it to do some work call Worker class Start method that then fires the JobRequested event.  This event is where you pass in some string data that the JobRun event uses.  When that job is completed the JobCompleted event fires passing in whatever string data you need.  The Error event is there to help pick up the pieces.

When run in the Debugger the worker classes is a thread but when it’s compiled a console application is placed in the appropriate placed for each target.  This means that there is a real difference between running something in the debugger versus your final application so it’s very important to test your results.  Since you’re limited to string data it’s probably not a great idea to pass large amounts of string data between your app and your Worker so maybe coming up with an intermediary (like a database file) might be useful.  

The Worker class is only available for Desktop targets for now and will presumably come to Console, Web and iOS targets in a future release.  I think developers will use this a lot and I expect some more advanced features coming to this class in the future.

With Apple releasing their first arm64 Mac’s just a few weeks ago this release also marks the first version that allows for native ARM applications as well as universal Mac apps (i.e. both Intel and arm versions).  The only thing I’m aware of that is not arm compatible is XojoScript and that will presumably come in a later release.  One thing to be aware of (this has been true for a while) is that to compile for macOS you need to be running Xojo on a Mac.  If you are running in Windows or Linux you cannot build macOS apps.  Xojo seems to think this is a temporary situation so hopefully that’ll happen soon.

The Graphics class received some love in this release adding LineCap and LineJoin properties.  It also adds support for Linear Gradient Brush, Radial Gradient Brush, Shadow Brush, and Picture Brush that allows a developer to do some really cool drawing effects.  This is long overdue.

For the first time in many years Xojo has added several highly requested and long overdue controls to the desktop.  New in R2 is a Search Field and a DateTime Picker.  The Search Field has pretty standard features.  The new DateTime control has the ability to be used in text-only mode or in graphical mode.  Again, it’s my opinion that these controls should have been added a long time ago but it’s nice that we have them now.

A few API 2.0 framework changes happened for TextField and TextArea controls.  The Value property is Text and the ValueChanged event is now TextChanged.  I think these changes make way more sense than Value and ValueChanged.

ColorGroups are now available for desktop, web, and iOS targets.

All in all this is another big release from Xojo adding new desktop controls, adding new capabilities to the Graphics class, the new Worker class, and doing a massive update to iOS.  The Xojo roadmap has their next big item as Android and with the R2 release it’s clear that they are getting close.  Will there be an R3 for the end of the year?  My spider sense says no but there might be a dot release to fix any major bugs that slipped through the cracks.

What say you Xojo developers?  Is R2 a good release?  What quibbles do you have with any of the decisions they’ve made?  Happy Coding!

13 thoughts on “Xojo 2020 Release 2

  1. > One thing to be aware of (this has been true for a while) is that to compile for
    > macOS you need to be running Xojo on a Mac. If you are running in Windows or
    > Linux you cannot build macOS apps. Xojo seems to think this is a temporary
    > situation so hopefully that’ll happen soon.

    Since debugging on newer versions of macOS requires an ad-hoc code signature you would need to be able to code sign on Windows or Linux using proper maOS signing which is unlikely to be ported to Windows or Linux (since it relies on a private Apple framework)

    Workers should be the same in debug as in a build. Anyone trying out Xojo cant actually test out workers completely. Nor can someone be sure their debug code is going to actually build. It struck me as an odd choice to make workers this way.

    • This is a very exciting release and this is a relatively optimistic, even glowing/hopeful review from Bob which says a lot! He’s one tough customer. Can’t wait to see what they come up with next year. Hoping for database improvements, more modern desktop controls, and most significantly a robust style editor for Web.

      • I’m not sure I’d call it a ‘glowing review’ but if you take it as such . I can’t really speak about any of the major iOS changes but Desktop has been fairly solid in my day-to-day use. My employer hasn’t officially upgraded yet so git commits get a lot of discarded files at this point.

        As far as the arm builds there simply aren’t enough M1 Mac’s out in the world yet to know for sure how well Xojo is handling it. I suspect there will be a ton of little, minor things that will cause us grief for the next couple of release cycles.

  2. Oh Bob, how I’ve been waiting for a new post on your blog and agree that 2020r2 is a really great release. I love the Graphics extensions, also GraphicsPath, LineJoin, LineCap and LineDash, LineDashOffset have been added to PDFDocument.

    Now you have to update the DateTimePicker on Windows in one point release to get the right height. Hopefully the company will continue to do so well next year with all the goals in each release.

  3. “Essentially you’re offloading work from the single core that your Xojo application uses and it starts a separate console application to do that work thus utilizing more cores on your computer.”

    Yikes. I hope that’s not actually true. Either that, or someone wasn’t paying attention to performance on Windows when making this decision. (Process creation on Windows is well-known to be *very* slow — I would expect Worker to be basically useless on Windows unless the task is incredibly heavyweight. https://www.bitsnbites.eu/benchmarking-os-primitives/ has some good graphs of how bad it it.)

    • “Process Creation:

      Unfortunately Windows does not have any corresponding functionality, so only Linux and macOS were benchmarked.“

      I can’t see anything about Windows from these graphs.

      Furthermore he compares wildly different systems (i5 2core MBP & a Mac mini with hard disk to high-end 8core Linux systems with SSDs) and then claims the “creation of 32,000 files” was not influenced by the hardware???

      Sorry, that is the worst comparison I have ever seen. It’s so bad that I would consider it actively misleading.

      • Sorry for picking a particularly bad source!

        However, it’s not like five minutes of searching with your favorite search engine won’t bring up report after report about how slow process creation is on Windows.

        (Btw, he does have numbers, it’s the graph below on launching programs.)

    • ” Either that, or someone wasn’t paying attention to performance on Windows when making this decision”

      Has anyone there after you left? 😉

      The worker demos I’ve seen have all been on Macs. Now that the feature has been released, I suspect In the next few months the there will be posts on the forum about their efficiency in various situations on different platforms.

      Given that the framework is not safe for anything but cooperative threading, it would seem something like this, or totally separate console apps, are the only practical way for Xojo apps to use more than 1 core. (something I’m sure you know)

      Is there another way? How would you have approached it?

      That said, in general in a lot of areas my impression has been that really good performance has not been at the top of the list of priorities for Xojo.

      • I agree that separation like this is likely the only way you’ll get thread safety out of the framework given it’s lack of actual thread safety. Trying to retrofit that thread safety would be a huge undertaking, but given how many times I’ve heard Xojo described as having a “new framework”, I can’t help but wonder why thread safety wasn’t taken into account when designing and implementing that new framework. I suspect “new framework” is “old framework with new ways to spell things”.

        In terms of how I’d do it, I’d start by inventing a time machine. 😉 I don’t think Xojo is really the product for preemptive multithreading unless thread safety is fully baked into the framework and leaves a lot of the fiddly decisions out of the user’s hands (e.g., you may not get peak performance but your code won’t have data races). If that’s not a possibility (perhaps due to unsuccessful time travel), I’d consider adding coroutines to the language and deprecating preemptive threads. They’re a bit like cooperative threads but more powerful. Might not be ideal, but I think they’d be less mysterious than preemptive threads and certainly have better performance than spinning up a whole different process and dealing with the IPC between processes.

        Keep in mind: I thought preemptive threads weren’t a bad idea in REALbasic at one point, so who knows how right I am here. 😀

  4. Well, the worker thing could also have been implemented via preemptive threads!
    They control input/output and can use a separate object/string list per thread.

    Maybe easier would be to provide XojoScript to run on a preemptive thread with separate globals and limited context object usage.

    Like our MT functions on JavaScriptEngineMBS class.

Comments are closed.