Musings on the Xojo Framework

The Xojo framework was first introduced with Xojo 2014 Release 3 (December of 2014).  That’s when iOS was added as a target to Xojo.  Since it’s initial release it’s received plenty of bug fixes and some libraries have been added to the desktop, web, and console targets that use the new framework.  But it sure seems like there hasn’t been much news about the new framework.

If I go back into my archives and what I’ve reported from past XDC’s we were told in March 2014 the new Xojo framework would come first to iOS with it’s own version and then to console, web, and finally to desktop apps.  At the time I took that to mean that they’d be a replacement to the old global framework but, in retrospect, it’s obvious that they meant what they had done for iOS would get introduced to those targets.  That meant that the core data types, Auto and Text and the core classes, MemoryBlock, Date, DateInterval, Dictionary, FolderItem, Crypto, and so on, were available for use.

Some things like the Xojo.Net.HTTPSocket are now the ONLY way to communicate with some servers because it can handle HTTP 1.1 and supports proxies which the old global HTTPSocket can’t do.  So for some things we are forced to use the new version.  For some it’s quite a change because the old global version could do things synchronously but the new version can ONLY do things asynchronously.  Using sockets from the new framework is not a simple proposition.

There are still huge swaths of functionality that is not available in the new framework and if you need it you’re forced to either develop it yourself, or to use one of the open source projects the Xojo community has released.  While the community has been generous this goes against the modus operandi of Xojo where they’ve provided all of the basic functionality.  This is particularly vexing for newbies that know there’s a new framework but need functionality not provided yet.  And as someone who has tried having global and Xojo frameworks working together it’s not very fun.

Because it appears we’re not seeing much progress, Xojo developers are starting to get nervous and asking questions.  Is the Xojo framework a bust and will Xojo be going in a different direction?  I’m hoping that both of these questions get answered in a couple of weeks in Denver at the annual Xojo Developers Conference (XDC).

We already know that Xojo Web 2.0 will be introduced at XDC 2018.  If it’s still using the old global framework I think it will call into serious question on whether or not the Xojo framework is viable.  I mean, if you’re going to the trouble of rewriting the web framework, why not make it use, exclusively, of the Xojo framework?  If it’s not, why not?  

Well also know that we’re getting some major news for Android for Xojo at XDC 2018.  Will it use the new Xojo framework?  If not it’s a clear sign that the Xojo framework is dead on arrival.  If it is but Web 2.0 is not again I have to ask why not?  Xojo then is sending out mixed messages as far as what the Xojo framework means to their future.

XDC 2018 is going to be an important one.  We’re going to learn about the progress on Web 2.0 and Android.  Hopefully we’ll have reasonably firm targets for releases.  As part of that I really want to know what the status of the Xojo framework is what the future brings for it.

Other topics that I hope to hear about:  plugins made in Xojo, and Interops

What are your thoughts about the Xojo framework?

Xojo.Core.Date Revisited

Geoff Perlman wrote a blog post https://blog.xojo.com/2017/11/04/get-better-dates-with-the-new-xojo-framework/ on how the new Xojo.Core.Date gives you a better date.  Better in that it does a superior job of handling timezones.

I will concede the point that the new Xojo Date class is better at timezones.  Timezones are icky and there are various areas of the world where they observe only partial increments of timezones.  The existing, global framework simply can’t handle those geographical timezones properly.  In addition to that, the global framework can get it wrong.  So the new framework is inherently better with timezones:  got it.

Where Geoff’s blog post goes sour, in my opinion, is when he talks about how the new Xojo Date and DateInterval classes cause more code but then goes on to show how it can made shorter.  I think his shortened example is indicative of the overall problem with new framework.

He starts with this example (note I am not implementing the Using keyword on purpose):

Dim d As New Xojo.Core.Date (2017, 11, 5, Xojo.Core.TimeZone.Current)

Dim di As New Xojo.Core.DateInterval

di.Hours = 3

d = d + di

MsgBox(d.ToText)

The results is a message dialog displaying:  2017-11-05 02:00:00.  This is what the old Date.SQLDateTime method returned and what many developers need for database SQL operations.

He then goes on to show that this code can be reduced to:

Dim d As New Date (2017,11,5,TimeZone.Current)

Dim di As New DateInterval(0, 0, 0, 3)

d = d + di

MsgBox(d.ToText)

Sure, it’s reduced, but now we’re passing parameters into the DateInterval constructor that we have to just know what they are.  Granted, it’s not hard to figure it out but when I’m reading code I don’t want to have to ‘figure it out’.  Whereas the first example was pretty explicit (add three hours) now I have to parse the number of parameters to figure out it’s three hours and not three days or three months or three seconds.  If when writing code I accidentally leave out a 0 it wouldn’t be immediately obvious that I’m not adding three hours but three days.  Ambiguity is never a good thing and I can’t tell you how many errors I’ve found in methods that have multiple parameters with default values because someone (usually me) missed a parameter.

I’d also argue that the documentation for Xojo.Core.Date is using, at worst, wrong example code or, at best incomplete documentation.  Using the variations of ToText results in some counterintuitive results.  If you use Xojo.core.Locale.Current (as all of the Xojo examples do), you get results based on YOUR system settings.  Really what you should be using is Xojo.core.Locale.Raw.  Below is a table that shows the differences for the following line of code when run on my macOS machine:

Dim s1 As String = d.ToText(Xojo.core.Locale.X, Xojo.core.Date.FormatStyles.Full, Xojo.core.Date.FormatStyles.None)

X = Xojo.core.Locale.CurrentXojo.core.Date.FormatStyles.Full 2017-11-05
Xojo.Core.Locale.Current Results
Format Result
Xojo.core.Date.FormatStyles.Long Sunday, November 5, 2017
Xojo.core.Date.FormatStyles.Medium Nov 5, 2017
Xojo.core.Date.FormatStyles.Short 11/5/2017
Xojo.core.Date.FormatStyles.None
Xojo.Core.Locale.Raw Results
Format Result
Xojo.core.Date.FormatStyles.Long 2017-11-05
Xojo.core.Date.FormatStyles.Medium 2017-11-05
Xojo.core.Date.FormatStyles.Short 2017-11-05
Xojo.core.Date.FormatStyles.None 2017-11-05

So given these results it’s impossible in the new framework to get just SQLDate as the FormatStyles.None is ignored.  <feedback://showreport?report_id=50242>  Until this fixed, to do this on your own you would have to split the Text on the space and use the first half of it.

The only reason why anyone should ever use Xojo.Core.Locale.Current is to display the date/time to a user.  Xojo.Core.Locale.Raw should be used for everything else.  The distinction between these variations is confusing even to experienced Xojo users so I can only imagine the frustration from newcomers.

Ultimately, the New Xojo framework is not very discoverable and this leads to frustration.  While writing this article, to figure out the parameters in the Xojo.Core.Date.ToText function, I had to look in the freaking documentation.  Yes, there is the tips area but it’s not very helpful while you’re typing.  To see what the tip is you have to stop and hover your mouse over the method.  And that only works if it’s not an overloaded method.

This leads to some users complaining that Xojo isn’t as much ‘fun’.  At first I pooh-poohed the idea but the more I think about it, it’s true.  The new Xojo framework is verbose and hard to discover and therefore not as much fun.  I work in this language every day and while calling it ‘fun’ might be a bit of a stretch I can tell you that using the new framework isn’t fun.  The two client iOS projects I’ve done in Xojo have been painful for a number of reasons and not being fun is a valid but minor point.  I don’t find the documentation to be nearly as easy to read and discover related topics, and frankly the new framework seems to make things harder than necessary.  Certainly there is a ‘this is the way I like it’ factor you’d get from someone with nearly twenty years using a language but I do feel that the new framework is needlessly nit-picky.

My first blog post https://www.bkeeneybriefs.com/2014/12/xojo-core-date/ on the Xojo.Core.Date class was in December of 2014.  It’s nearly three years later and we’re still dealing with bugs and idiosyncrasies and it’s not widely used despite clearly being ‘better’.  It’s no wonder why people don’t really want to use the new framework and I wonder if any parts of the IDE are using the new framework.

What are your thoughts on the Xojo framework?