Xojo 2018 Release 2

Xojo 2018 Release 2 is now available.  This release is heavy on fixes with some for the IDE, for Windows, Linux, and some new features for iOS.  

In iOS, the iOSTable now supports Pull-To-Refresh.  iOSTable now does a better job with variable height rows by setting the UseDynamicHeight property and lets the row height be determined by the content of the cell.  The inserting and removing of rows and sections is now animated if they are in the visible section of the table.  The IOSHTMLViewer is now using WKWebView instead of UIWebView.  A fix to the AutoLayout editor now tries to keep you from making constraints that could cause crashes.

Windows received a ton of love in this release but the biggest change is related to drawing.  Xojo 2018 R1 introduced a new way of drawing in Windows that effectively eliminated flicker but it also severely limited the speed of drawing.  R2 appears to have mostly fixed this issue by calling additional Paint events rather than caching pictures.  As always you should test the Windows versions of your apps to see if the drawing speed is acceptable for you.  Many of the old ways to eliminate flicker actually make drawing really slow now so test, test, test!

Besides the drawing issues there were plenty of other Windows changes as well.  Printing in no longer limited to 96 DPI.  BevelButton, HTMLViewer, Listbox, Xojo.IO.TextOutputStream/BinaryStream, Xojo.Net.HTTPSocket, Sliders, Object2D, OpenGLSurface, ContainerControls, and TabPanels were all touched in this release.

Linux and Raspberry Pi wasn’t ignored in this release either.  BevelButton, Listbox, HTMLViewer, and GroupBox received updates to fix various bugs.  Of note, the HTMLViewer on the Pi no longer hard crashes the application.

A change that could affect some people is that Graphics API now takes Doubles instead of Integers for better precision.  It probably won’t be a big deal for many developers but you will definitely want to try your drawing in non-HiDPI and HiDPI modes to see if anything has changed.  I did a quick test with Shorts, Formatted Text Control, and Tab Control and didn’t notice any drawing glitches so it’s possible that the average developer will be unaffected by it.  

Another graphics change is a new AntiAliasMode property that controls the quality level when drawing scaled pictures.  There are three modes:  Low, Default, and HighQuality.  Default Quality, I think, is simply what we have now.  The documentation (AntiAliasMode is missing from the built-in documentation but is online) is unclear as to how Default compares to Low and High Quality.  Testing should reveal this.  Also unclear from the documentation is how this affects speed but one can presume that High Quality will be a little slower but I have not tested this.

There are two new functions added to the SpecialFolder class.  The new Resources function returns the appropriate platform specific resources directory if it exists.  The new GetResource takes the passed in name and returns the file (if found).  Neither of these new functions are found in either the built-in or online documentation.

As always please review the Release Notes to see if anything affects you or interests you.

Documentation and examples are one of those things that no one likes to do.  But given the audience that Xojo caters to (the Citizen Developer) I am always amazed that things that are added to the framework often don’t have an example project.  I might be wrong (because I didn’t check every single example) but the new IOSTableRefresh and new animations don’t have an example project.  Nor is there anything for the new AntiAliasMode.  

The new SharedFolder.Resources and GetResource methods aren’t in any of the available documentation (other than release notes) but at least Resources is used in the SpecialFolderPaths project.  However, that example isn’t listed in the Release Notes as being changed.

The documentation not being available at release is simply unacceptable.  Each new feature should have an easy to find example project demonstrating its use (preferably available during the beta period too).  I also recommend having a folder for each version that has shortcuts to all of the examples that are new or modified for the current release.  Every release this list changes so the examples list doesn’t get loaded up with folders from old releases.  Regardless, I’m very disappointed the documentation in this release.  Xojo needs to do better.

Anything in this release that you’re happy, or unhappy, about?

Xojo and the Rapid Release Model

If I could change one thing about Xojo what would it be?  My answer is, without a doubt, the Rapid Release Model.  Here’s why.

The idea of the Rapid Release Model isn’t a bad one.  In the not too distant past many applications had major yearly updates.  Many still do.  In fact, Xojo (when it was called Real Studio) did this with varying degrees of quality.

Some of the complaints about the yearly, monolithic, release of Xojo (back when it was Real Studio) was that it wasn’t a very stable release and it took several dot releases to get it right.  This was the impetus that led me into the Beta Program so I could test out new features before it was released.  I was tired of new features not being usable due to an obvious lack of real world testing.

In theory, the Rapid Release Model introduces smaller changes and a few new features each release.  Releases are roughly every quarter but in recent years this timeframe has not been as consistent.  I believe this change happened, in large part, to address some of the complaints of the Rapid Release Model.  One of the complaints being that the constant drive to get new features in every release gives the software a perpetual beta feeling.  I would argue that the recent changes to the Windows drawing system certainly justifies that feeling to many current Xojo developers.  

From a developer standpoint, I can only imagine the pressure on Xojo’s small development team to constantly add new features every 90 days.  It means that developers are always pushed to get things done rather then get them right the first time.  Again, I would point to the plethora of changes to the Windows drawing system that have spanned many releases as proof.

I believe that marketing is entirely behind this new-features-every-release mantra so they can get buzz about something in every release.  I get it:  for a small company they need to create as much buzz as possible.  Buzz creates some sales and renewals.  But I think the Rapid Release Model is actually hurting them with many developers who value stability over new features.

More evidence that the Rapid Release Model is hurting Xojo is their recent change of telling customers their development plans.  No longer will they tell us the target date of when a feature is released and instead they’re simply saying if it’s a ‘priority’ or ‘important’.  Prior to this, Xojo CEO Geoff Perlman said that Interops and Android would ship by the end of 2017 and not only did they not deliver, but it seems highly unlikely they’ll get it out by the end of 2018 in anything other than an alpha release (purely a guess on my part and I’d love to be wrong).  

Being poor at estimating isn’t just a Xojo problem.  Chrono-Optimism is a human condition and I believe the old adage that 80% of the work takes 20% of the time and the final 20% takes 80% of the time.  Estimating is an arcane art form and at times software development is pure magic that takes time.  Forcing releases into this 90 day window makes the problem worse by having incomplete solutions and incomplete testing.

When all is said and done, I believe Xojo would be better off ditching the Rapid Release Model and going back to monolithic releases with regular dot releases that does nothing but fix bugs.  Perhaps this means that there are only two major releases a year.  Sometimes only one.

The Rapid Release Model is not without some merit.  We currently know that every release will fix a large number of bugs and we know roughly when that release is going to come out.  Not all bugs are created equal but for many developers we can’t wait six months to a year to get a release that fixes some bugs.  So any replacement to the Rapid Release Model must take into account that Xojo developers need a regular, perhaps monthly, bug fix releases for critical and important bugs.

I think changing to a hybrid model between the monolithic release and Rapid Release Model fits the small Xojo team better.  First, it lets the new features gestate in internal testing longer before we ever see them without being rushed out the door.  Second, the regular release of bug fix builds is simply that – bug fixes – and lets the developers continue to work on the next big thing without the pressure of having to add new things in each release.

To say that the Rapid Release Model is a failure is hyperbole.  To say that the model makes the product beta quality is also a stretch.  The truth is somewhere in the middle and I think this is an important discussion for the future of Xojo and their customer base.  What do you think?

Chasing Xojo

The most important thing for developers is to have a reliable IDE.  The Xojo IDE has been stable for a couple of years and while I don’t find it as useful as the old REAL Studio IDE it doesn’t hinder me as much as it used to either.

Another vital aspect of a solid development tool is the stability of the compiled application.  This is where Xojo isn’t doing as well.  MacOS has been stable since the transition to 64-bit Cocoa was complete.  The transition for Linux and Windows has been less successful and this has to change.  If they don’t get better, many of us will be forced to look elsewhere for a new development tool.

This post is part rant and part wish list.  I want – no need – Xojo to be better than it currently is.  Part of my frustration is the plethora of older projects that are stuck on an older version of Xojo because of issues with newer versions.

Linux is a particularly difficult platform to work on: The number of distributions and slight variations ensures that there will always be some challenges to stability.  These differences make it difficult for Xojo to create builds for all distributions that work evenly.  The new GTK 3 drawing system has been less than ideal for us.

We have several cross-platform commercial applications that have macOS, Windows, and Linux targets.  When Xojo made the transition to GTK 3 it really messed up how these applications work in Linux.  Add in some 3rd party control compatibility issues and we’re stuck at Xojo 2017 R1.1 (before the GTK 3 switch occurred).

More recently, and more importantly, we’ve had a number of projects that were last built using Xojo 2016 R3 and the client recently wanted 64-bit builds for macOS.  This wasn’t a hard transition with only a few 64-bit specific changes required.  The Windows builds (still at 32-bit) in Xojo 2018 R1.1 proved to be impossible simply because the Windows drawing system has steadily changed in (what seems like) every release since 2016 R4.  

I’m not sure what the drawing system change was in 2016 R4 but drawing doesn’t work the same way as in 2016 R3.  Then there was the change to Direct2D from GDI and that had significant bugs for several releases.  The recent 2018 R1 release introduced even more significant changes to the Windows drawing system to reduce flickering.  The caveat is that drawing is much slower depending on settings and how you’ve layered your controls.

From my experience and from what I’ve gathered from the Xojo forums is that the new ‘flicker-free’ system is causing a lot of heartache among developers building for Windows.  Sure, flicker is gone but drawing is so slow as to be unusable in some cases.  Even developers that could live with the flicker are unhappy with the speed hit.

My client eventually told me to give up because he didn’t want to foot the cost of converting to a new drawing system that wasn’t causing him issues to begin with.  So, this means I’m creating macOS builds with Xojo 2018 R1.1 and Windows builds with 2016 R3 (with the code base from that era).  That is nuts and unacceptable.

I get that Xojo will always be playing catchup with changes to the target operating systems.  When Apple or Microsoft or a specific Linux distribution changes things it has to react to the change.  Hardly ever does Xojo have advance notice of the change (remember when Apple deprecated QuickTime and stopped accepting Mac App Store submissions with QuickTime just a few months later?  Or when Apple decided that iOS apps were going to be 64-bit only?)  I think that what we have in Xojo is nothing short of miraculous.

But, in regards to the drawing systems for Linux and Windows they’ve made a conscience decision to change a critical and important system.  This makes it tough to upgrade from one Xojo version to another without a great deal of work.  Clients don’t want to hear the term ‘lot of work’ because it means it will cost them.  So we’re stuck with older, and inferior, versions of Xojo.

I guess this is the price of advancement.  Any NEW projects will have the new Linux and Windows drawing system in place and we’ll think nothing of it a year from now.  But heaven help anyone trying to upgrade from an older version of Xojo to a newer one because it will cause a lot of work.

It’s probably not possible, but it would be great to have the option to use the older drawing system and have it marked as deprecated, or perhaps we even have to force the switch to use an older Graphics object.  In the not so distant past we had the switch in Windows to allow GDI or to use the slightly different GDI+.  I would really like that option in Windows (instead of the flicker free version) and for the older drawing for Linux.

I love Xojo.  What it does is nothing short of magic.  Develop on the platform of your choice and write for the other platforms.  That’s some high level wizard stuff there.  I just wish the transitions of major subsystems were planned out better beforehand, more stable when introduced, and not in need of major work to upgrade to use, or at least have a way to use the older system version for a period while still getting to use the new version of Xojo.

I can also argue that the constant cycle of adding new features and changing things every release is detrimental to the product.  Every now and then I want a release that is comprised ONLY of bug fixes.  Marketing be damned – I just want stable and reliable releases so I don’t have to juggle Xojo versions and plugins.

There are a lot of bugs that should be fixed that have been around for years.  I understand that not all bugs are created equal but some are very serious when you encounter them and are impossible to work around.  Again, having only a couple of releases every year that do nothing but clear the backlog would be awesome.

Instead, we already know we’re going to get Web 2.0, API 2.0, Interops, and Android in the near-ish future.  Those are all major NEW features.  Can we just get a few stable releases before those things are added so we don’t have to chase Xojo versions depending on bugs?

The old way of doing releases was to do one major release a year and then issue a number of ‘dot’ releases.  It usually meant that the first release of new features wasn’t a great one because of bugs but usually pretty good after the first or second update.  With the constant race for new features every release we get to chase versions based on what bugs we can and can’t live with.  

Please, Xojo, be better before I have to go in search of a new tool.

Xojo 2018 Release 1.1

Xojo announced the availability of Xojo 2018 Release 1.1.  This ‘dot’ release fixes a couple of glaring bugs that were introduced in 2018 Release 1.  Some of the more important fixes:

  • A NilObjectException caused by an undo in the IDE has been fixed.
  • A regression in the debugger kept some 32-bit breakpoints from working reliably.  The debugger now stops at breakpoints correctly in 64-bit and ARM targets now too.
  • In Windows, if you have a global variable it can now be viewed in the variables pane.
  • The Printer graphics.clip method now works as expected.  If you printed a Shorts document in Windows you would have run across this bug.
  • A host of Windows framework bugs were fixed.  TabPanels now draw properly with proper backgrounds.  TabPanels that contain sliders and scrollbars that caused the tabs to scroll off the TabPanel is now fixed.  The Canvas control now properly refreshes after Scroll is called.
  • iOS projects now compile when it has a launch screen with an image that has no actual pictures in the image.

If you are experiencing any of the issues listed in the release notes you should update to R1.1 immediately.  It’s a shame that it took Xojo nearly a month to get this release out the door.  I realize that XDC causes a huge disruption to their development schedule but the wait for this dot release was too long.

For those of you doing a lot of Windows development, are you still experiencing drawing/speed issues?  Or, have you determined the secrets behind making things better/faster?

Chrono-Optimism

At the XDC Keynote a few weeks ago Geoff Perlman said they’d no longer give target dates for new features.  Instead they’re going to say what’s a ‘priority’ and what’s ‘important’.  Software projects are often big and complex and it’s very hard to estimate the amount of work involved with a new feature.  “Happiness is all about having expectations met,” said Geoff and I think it’s fair to say that Xojo has typically been overly optimistic on when a feature is going to ship (much less when it’s going to be usable).  So instead they’re going to stop predicting when a feature will be released.

If you hear them say it’s ‘Important’, it’s something they’re seriously looking into.  It will be in the product in the not too distant future.  A ‘priority’ means it’s either in active development or will be shortly.  The Rapid Release Model is still in play which means we will still get releases three or four times a year.

In one sense I’m disappointed that they’re not going to give us any timeframe for new features.  I really want to know when Web 2.0 is going to ready for testing as we have a number of projects in development or about ready to start development that it would be really nice to know if it’s a 90 day, 120 day, or longer window.  Android is a nice to have feature, but since I’m not doing much mobile development it’s not that important to us, but I can see how for some it is a huge need.

In another sense I understand why they’re not going to give us target dates any more.  They’ve missed every projected release date that I can think of and I’m going back a lot of years.  It was about a year ago this week, in Berlin, that Geoff said that Android would be out by the end of 2017 when the reality is that we’ll be lucky if we see it by the end of 2018 (that’s just a guess on my part and having having been around a long time).  I would love to be wrong on that guess but it’s a new target that involves a ton of compiler, framework, and IDE work not to mention the need for Interops (a dependency) to work well.

Estimating a project is not a science.  You’re asking software developers to take a wild guess at how long a big feature is going to take.  When you make that initial guess you don’t know that replacing this small piece of code will affect this much larger piece of code over here.  Or cause this other piece to not work right thus forcing you to redo that other piece too.

In some respects creating a new project is considerably easier than replacing code.  In new projects you’re touching everything anyway but subconsciously you’re holding most, if not all, of the work in your mind and you shape it as you go.  Big, existing projects, or OPC (Other Peoples Code) projects, are considerably harder since not only do you have to read the code but also figure out the intent of the code and second guess what the original developer was attempting – not always an easy task.  I’ve never seen the code for the IDE but I’d imagine dozens of people have worked on it over the years with varying degrees of competency and coding styles.  So whatever work you do you have to read, interpret, change, and test to make sure it doesn’t break something somewhere else.  Tack on multiple environments and targets and it’s a herculean task.

I’ve spent the last four years working with my son’s FRC robotics team (team 1982) as the programming mentor.  They have six weeks to design and build a robot to a very demanding set of specifications before they crate it for competition.  These 120 pound robots are relatively complex and I’ve seen it time and time again where the kids have ‘Chrono-Optimism’ in what they believe they can get done in after-school meetings (some with mentors present and some without) and on Saturdays.  Granted, they spend a LOT of time working on the robot, but they’re just kids and most of them have never done anything like this before.  They don’t know what they don’t know and most years they’re scrambling just to get a working robot.

This year, the group of seniors really thought about what they wanted to do.  They knew it would be challenging, but they decided to change their build process and use a more modular hardware design which meant new gear boxes, wheels, framing, etc.  They also decided to build two robots which, for a team that’s never done that before, was …ambitious.  Then they decided that they wanted to go two regional tournaments.  Again, ambitious for a team that’s never done that.  From previous years they also learned something else:  they were attempting to design too much on the robot.  If there were three major tasks that a robot had to accomplish they couldn’t do all three with the resources and experience they had.  They couldn’t change the amount of time to build the robot so they changed the one thing they could – the scope of work – and made the robot simple and sturdy.

The Universe works in mysterious ways and has ways of throwing a monkey wrench into the best of plans.  The last day of build season this year happened to be a day off so the plan was to have a twelve hour work day to finish the robot and test.  Instead, Kansas City had a snow storm which cancelled all school activities.  The robot was not mechanically complete and not functional programming-wise.  The kids were devastated.  But there is a silver lining to their story.

The robot was crated away and couldn’t be worked on for weeks, but the second robot allowed them to work on the programming and driver training.  The modular design allowed them to plan the work they needed to do at the tournament before it started.  The simplicity of the robot meant that the work could actually get done in a short amount of time before taking to the field.

To conclude this story (because I’m bragging now), the team won their first tournament which qualified them for World Championships.  They were the eight seed alliance captain in their second tournament.  At the world championships, they finished 42nd of 67 teams, but were picked as part of the 6th seed alliance.  They won in the quarter finals and ended up getting to the semi-finals where they were defeated by the alliance that went on to be third in the overall tournament (out of 400 teams).  All because they examined their past behavior and decided to change it.  They knew they were bad at estimating and changed their expectations.

I will give credit to Xojo for realizing that, like most of us, they are Chrono-Optimistic in their estimates, and decided to change how they communicate to their customers.  As Geoff said, part of their job is setting expectations and they’ve been really bad at it.  It’s clear that they said ‘estimate’ and we heard it as a ‘promise’ which is partially on us.  So now we have what’s a ‘Priority’ and what’s ‘Important’.  I don’t know if this will help them, or us, in the long run but it will be different and I’m willing to play along for now.

What do you think about this change?  Negative, positive, or neutral about it?

Xojo 2018 R1

Xojo 2018 R1 was released today.  It’s been over four months since Xojo 2017 R3 was released in December of 2017.  By any stretch of the imagination that’s a long time between updates.  Let’s start with the big ticket items that you’ll be relatively happy about.  2018 R1 has a ton of bug fixes, enhancements, and new features.  

Windows users will find things to be happy about as Xojo has gone way out their way to reduce flickering issues in the Xojo IDE and in our own built apps.  The magic behind the scenes is not that Xojo is using double buffered windows (or anything like it) but they are now freezing drawing in the window while it’s doing things in the background.  Thus the flicker is gone but at the price of speed.

If you’ve spent a lot of time working around the limitations of control flickering in Xojo, your upgrade to 2018 R1 won’t be a walk in the park.  A number of forum users have done considerable work figuring out the best way to get things to work well together.  The basic premise is that everywhere there is a Transparent, DoubleBuffer, or EraseBackground property you should turn them off.  I’m sure in the upcoming days a more thorough explanation of the best practices will turn up on the Xojo forums.

One thing that might really turn developers off is Feedback Case #51337 where Labels look ‘fuzzy’ and not acceptable to many end users.  This appears to be caused by the difference between the Direct2D drawing engine and the old GDI engine.  Before jumping into 2018 R1 you might want to do some testing to see if this is acceptable to you.

Printing in Windows appears to be better now as you can now print with higher resolution than 96 DPI.

The other big Windows feature to make it into 2018 R1 is the ability Debug and Remote Debug 64-bit Windows applications.  This is a big deal and required that Xojo upgrade the compiler to LLVM version 6.

In late beta testing I had issues with the Remote Debugger (from MacOS to Windows) not dropping down into the debugger and AutoComplete sometimes not working but those appear to be fixed just before the final release.  If you run into issues with either please report them as soon as possible!

The EraseBackground property is now gone for Canvas and Container Controls.  Container Controls have a new DoubleBuffer property that composites the control on Windows and allows for moving/scrolling controls with less flicker.

The Currency datatype is working properly again in 64-bit builds.  In previous builds the Currency comparisons didn’t always work and precision was lost when dividing Currency values.

A host of Windows framework bugs were fixed in the Listbox. The Val function in 64-bit Windows builds now returns appropriate values.  BevelButton captions and menu arrows now work properly when the DPI scale factor is greater then 100%.  Graphics TextUnit.Pixel is no longer treated as Point sizes when the DPI scale factor greater than 100%.  Please see the Release Notes for a complete list of Windows framework changes.

The Web framework received some love too.  The WebFileUploader control works with files greater than 2 GB in size and works with files with ampersands and apostrophes in their name.  It also supports drag and drop and now has a new UploadProgress event.  It also supports file multi-select to allow users to select more than one at a time.  It also has a CancelUpload method and a new UploadTimeout property.

The WebMoviePlayer now uses a native HTML5 video player on supported browsers (I believe this means all of them) and now has a separate Stop method.  Internet Explorer 9 support was removed.  WebMapViewer only calls into the Google Map API once per browser session.

The SQLite library was updated to version 3.22.  One of the big changes is that errors when creating SQLitePreparedStatments now get a more meaningful error messages versus the unhelpful ”unable to prepare” message.  SQLiteDatabase now supports AES-256 encryption.  The SQLiteDatabase now yields to other threads when it’s busy performing a long operation and using the ThreadYieldInterval property.

For many users the upgrade to 2018R1 will be a no brainer.  However, those that have a complex UI should do some testing in Windows to ensure that drawing speed is still acceptable.  Some beta testers found that the tradeoff of being flicker free was not worth the slower rendering speeds.

The Debugging of Windows 64-bit applications is a much needed and welcome feature.  Without much time to see it working (properly) I can’t give much of an opinion of it.  The compiling speed of 64-bit apps is very slow and it appears that incremental compiling is off.  I would expect the entire process to get better over time.

With this major milestone out of the way I hope we see considerable progress on Interops, creating plugins from within Xojo, Android, and Web 2.0 in the next couple of releases.  I’m sure we’ll find out more next week at XDC.

What excites you in 2018 R1 and what gives you some concerns?

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?

Does Xojo Crash On You? Try Clearing the Plugin Cache

Several people on the Xojo forums have complained about Xojo crashing on them multiple times per day.  I rarely, if ever, have that issue but I do occasionally get an issue where a compiled application will do something that’s batsh*t crazy and nonsensical.  

For example, I had some database code that was doing a simple database query where the error bit was returning true (or at least the compiled application was saying so).  I spent hours trying to figure out why it was returning an error.  I replaced the database file (SQLite) with a fresh file, ran the query in external editors, I did practically everything and finally I gave up.  I shutdown Xojo and restarted my iMac.  The issue persisted.

Finally I did my fixit option of last choice:  I cleared my plugin cache.  I restarted Xojo and voila!  The problem went away.

This happens once or twice a year for me.  We use a lot of plugins from Monkeybread and Einhugur (and others too) and switch versions of Xojo quite a bit so I’m never really surprised that this happens.  Usually when I clear the cache there are a LOT of versions listed.

The Xojo IDE has plugins that it has to compile and use so those that don’t use third-party plugins may also experience this issue.  And of course the project cache is true for everyone as well.

For those using third-party plugins, it’s ALWAYS a good idea to keep up to date.  I know Monkeybread Software has done a LOT of work recently getting ready for 64-bit for Windows and Einhugur has done a lot of work recently to support Gtk3 in Linux and 64-bit Windows. I know I’m still waiting on the Einhugur Treeview plugin so I can move a Linux project from 2017 R1.1 to something newer.  Before complaining to Xojo do your due diligence and check for newer versions!

So my advice is when things are acting weird, empty the plugin and project caches.  On macSO this is in ~user/Library/Caches/Xojo.  In Windows this at C:\Users\YOUR USERNAME\AppData\Local\Temp\ with two folders, XojoIDEPlugins, and Xojo scratch XXXX folder with XXXX being some specific number (build number?).  I have no idea for Linux (sorry).

This might not be a perfect solution but it might keep you from going crazy(er).

RAD Still Means You Have to Learn the Language

Xojo is a great development tool that is a Rapid Application Development (RAD) environment.  That’s marketing speak for you can get stuff done quickly.  The marketing speak isn’t wrong but for many people they think this means that Xojo is ‘easy’ and the learning curve is next to nothing.  I hate to break it to those developers, but it just isn’t true.  Xojo, like any development language has a learning curve.  It might be a lot less than others but there is definitely one.

The truth is that Xojo is RAD once you learn how it works.  This means you have to learn the basics of the IDE, the language, and the debugger.  And only after understanding the basics of Xojo can you start taking advantage of the RAD part.

There are parts of Xojo that aren’t so RAD.  One of those, in my opinion, is database coding.  You still need to know SQL, and use the basic database classes to read and write data into your application.  In fact, it’s so low level that the IDE does not help you, in any way, which may lead to database errors.  The IDE will happily let you try to put a string into a numeric field in the database.  What worse is that depending upon which database is used (looking at you, SQLite) it won’t complain when you do so (thankfully this is not true of all databases).

Putting data into a database using the database classes is a two step process.  One, you have to query the database knowing what the field names and datatypes are as there is no autocomplete for them.  Xojo will happily let you (try at least) put a date value into an integer at design time.  It’s not until you try all this at runtime that things fall apart.  The same is true for updating and inserting data.  These are the reasons why we came up with ActiveRecord – our database classes for Xojo.

ActiveRecord is our way of making the Xojo compiler a little bit smarter.  It maps each table to a class and the properties in that class map to the database fields.  ActiveRecord checks to make sure that all of the fields in the table are represented in the class.  If not it flags the developer.  (It does way more but this post isn’t really about ActiveRecord.)

From our experience, jumping straight into ActiveRecord isn’t all that helpful for new Xojo users.  It’s a shortcut and you’re depending on our code without understanding it and I strongly discourage it until you’ve gone through the pain and tedium of using the standard Xojo classes.  In fact, when we train new developers we ALWAYS have them do a small project using the standard Xojo database classes.

Then we train them in how to use ActiveRecord.  The setup is a bit more involved and it’s not a perfect system, but once they start using the Table/Field autocomplete and having the compiler warn about mismatched datatypes they start to understand how much faster they can code database applications.  We are consultants, after all, and time is money.

Rapid Application Development systems do NOT mean quick to learn and being able to create an application with no experience.  RAD means that AFTER you’ve learned how it works it can be incredibly fast.  Once you learn Xojo is *can* be very fast to develop applications.

Anyone disagree with this?  What is the best method of learning Xojo?  Online documents?  Webinars?  Videos?

Updates

One of my goals for 2018 is to write more.  So here’s an update on stuff.

We hired a new developer who comes on board in a few weeks.  I’m really excited about his Xojo experience and what he brings to the company.

The planets and stars aligned and I will be going to XDC in Denver next month.  This makes me very happy as XDC is one of my favorite events!  I get to immerse myself in Xojo for a week and see all my friends and meet new ones.  I’m not presenting so that makes life a little easier too.

The week of XDC is going to be hectic as the weekend before as the FRC robotics team my son is on will be attending the World Championships in Houston.  Last weekend they won the Heartland Regional Tournament in Kansas City.  After a pretty disastrous first day where a lot of mechanical issues arose they had a solid last day, got picked by the 3rd seeded alliance, and eventually won the tournament (an alliance is composed of three teams) and advanced, automatically, to the championship tournament in Houston.

If you are geeky and interested in what these kids build, here is the final match where they won the tournament.  https://www.thebluealliance.com/match/2018mokc2_f1m2