Xojo Workers

Xojo 2020 R2 introduced the Worker class.  The Worker is Xojo’s way to use more cores and process data faster.  This is important because the Xojo thread class is cooperative meaning that it runs on the main thread, the same one as your application, and thus shares processor time of a single core.

Why do we use threads in the first place?  Generally it’s to do a lengthy process and you don’t want the user interface to lock up.  There’s nothing more irritating from a user perspective than to have your app do nothing for a few minutes as it chugs through something.  Threads prevent this but there’s a tradeoff using them because it means the overall time it takes to do the processing is longer.  So while the app remains responsive to the user it takes longer for the processing to complete.

So the Worker class is Xojo’s attempt at multi-processing.  The Worker class actually creates a console application that is placed in the application bundle/package and handles all the work of spawning the process and passing information back and forth.

I spent some time this week banging on the two Xojo Worker examples in both Mac and Windows and found some mixed and complex results.  My quick and dirty response about Workers and how good they are is: ‘it depends’.  Let’s start talking about the examples.

My first attempt was taking the Xojo example project PictureResizer and taking it through its paces.  I tested a folder with 1071 png and jpg files.  In all tests I used compiled applications because attempting this in debug results in the Workers using threads (more on this later).  For my workers I allowed 4 cores and up to 90% core usage to stress it out.  I used my 2015 MacBookPro that’s been BootCamped to use the exact same hardware.  MacOS side is using Catalina and Windows is using Windows 10 64-bit.

My initial results were this:

Mac:  274 seconds

Win:  115 seconds

My first question was why Windows was so much faster.  So instead of using Picture.Open I switched to reading the file in via BinaryStream and then using Picture.FromData.

Mac:  182 seconds

Win:  106 seconds

Better but still quite a bit different.  I suspect that Mac console apps are using a much slower Picture library than desktop.  So I then created a thread (using default settings) and found the following:

Threads:

Mac Picture.Open:  196 seconds

Mac Binary Stream:  200 seconds

Win Picture.Open:  124 seconds

Win Binary Stream:  205 seconds

I find it surprising that Picture.Open is considerably faster on Windows than Mac.  But I was still not satisfied with this result as it seems like Workers aren’t working as expected (pun intended).  So I created a new version and passed in 20 files at a time to the Worker.

Mac Picture.Open:  196 seconds

Mac Binary Stream:  176 seconds

Win Picture.Open:  115 seconds (no difference)

Win Binary Stream:  106 seconds (no difference)

So this says to me that the example is flawed.  Only processing one picture at a time isn’t very efficient.  There is some overhead to start a Xojo console application and it seems that on macOS it’s significant enough to barely make it better than using a thread.

For test two I took the WordCount example and modified it to be able to do the same processing from a thread as well as the Worker.  I also decided to test this without using any background process just for comparison sake.  I used 1320 Text files of random length.  Test results:

Mac

Worker: 13.41 seconds

Thread:  35.53 seconds

No Thread:  34.85 seconds

Windows

Worker: 19.09 seconds

Thread:  20.04 seconds

No Thread:  25.79 seconds

I think this example is a bit better since there is a ton of string processing that obviously takes a while.  On macOS you can see that the Worker is clearly better than the Thread and even the no thread.  In Windows there is not much difference and I’m not sure how to explain this difference other than that maybe starting new processes in Windows is slow but still it’s obvious that Workers are better than no thread and slightly better than using the Thread.  With something that requires even more work I would expect this to be more pronounced.

One of the beefs I have with Workers is that you literally cannot test them in the debug environment.  When you test in the debugger you’re really working in a thread.  One of the strengths of Xojo is that working in the debugger is mostly the same as working in the real thing and Workers break that paradigm.  It’s a shame but maybe Xojo can fix this in a future release.

My other take away from using Workers is that it’s not a panacea for everything just like using Threads is not perfect.  Workers are Xojo console applications and there is overhead to starting them.  Xojo does make them easy to use by handling the inter application communications but with only string processing available you might be better off using IPCSocket communication but that’s not without its tradeoffs too.

Using Workers will take some work on your part to make sure you’re doing it as efficiently as possible.  Is it better to process a number of things in the Worker or do them one at a time?  And of course if you decide on Workers you’ll have more ‘joy’ in testing them.  Overall, ‘it depends’ on your needs to know if Workers are useful for your application.

Xojo 2020 Release 2.1

Xojo released a dot release this week that contains some important bug fixes.  Arm64 and iOS targets as well as the new Worker class received a number of important fixes.  Let’s get into some of the details.

The new Worker class will now use the Error event if the main app tries to start a worker without the required Helpers folder instead of throwing a Nil Object Exception.  The Error event no longer fires when the Worker quits normally.

ARM builds for macOS has added complexity for Build Steps.  We now can specify architecture for CopoyFilesSteps.  Resizing an array of structures no longer crashes on macOS ARM builds.

The ODBC database plugin no longer fails to connect.

ParseJSON no longer raises a failed assertion when passed an empty string.

The new DateTimePicker uses the standard border width and the control height was changed for Windows.  The DateSelected returns a valid DateTime object in Windows.  On the Mac side the control now honors the Top value when displayed in Text mode and you can now set the SelectedDate property regardless of the Regional settings of the user.

TabPanel.RemovePanelAt no longer throws an Out of Bounds Exception if the tab exists.

iOS has a number of changes.  Global.Speak is now System.Speak, Graphics.Font returns a Font object instead of iOSFont.  UDPSocket usage no longer causes the app to terminate after unlocking the phone.  The Runtime module methods are now accessible.  Graphics FontSize, Bold, Italic are removed in favor of the equivalent Font class properties.  

All users should update to Release 2.1 because of these important bug fixes.

The Advantages of a Job versus Consulting

For the past 20 years readers have heard me talk about consulting and the joys and challenges therein.  Those blog posts aren’t wrong but for the past nine months I’ve had a full time job and my perspective has changed.  Here are some things I’ve learned.

I’ve told friends that I have a ‘real job’ now.  In reality, it’s way easier than consulting.  While I was consulting I was always worried about where the next consulting project was going to come from.  I didn’t realize how much pressure and anxiety that introduced.  As my youngest child (now a junior in college) will tell you we talked about work (i.e. consulting) ALL the time because it was an all-consuming thing.  We either talked about the current jobs, the jobs we were bidding on, or whatever hassles we were dealing with in regards to employees, insurance, cash-flow, etc.

With a full time job I don’t have to worry about the next gig.  Now I just worry about the next project my bosses give me.  Well, it’s not worry, really, since we have an awesome team of developers but it’s more intrigue and wondering how deep of a rabbit hole I’m going to go down since we deal with some pretty arcane stuff.  Not worrying about the future is a huge relief (as much as anyone can feel safe during a global pandemic).

Along with the full time job I have all the benefits that is tough with your own business.  A steady income is an incredibly good thing since as a consultant you’re either rolling in dough (figuratively) or have none.  Having a 401k is a big relief as I go into the later part of my career.  Paid time off is another huge benefit since as a consultant you don’t make any money if you’re not working.  I don’t have to worry about health insurance now either and as a small business you get totally screwed over when it comes to health insurance in the United States.  As a business it was our number one expense after payroll and it was a nightmare to deal with since practically every year there was a 20% (or more) increase in premiums unless you switch plans which is a huge pain in the ass since you worry about is the new plan the same or worse than the old one and how will it affect you and your employees.

I’ve always been thankful that Carol was wiling and able to do the HR, payroll, accounting, and contract side of the business as well as being an awesome project manager and data goddess (DBA) on top of all that.  Without that help there’s no way I would have lasted 20 years.  Me as a developer will always tell the client that ‘sure we can do that’ but it’s helpful to have the project manager say, ‘yeah, and this is how much extra it will cost.’  Someone has to be the bad guy with the client and it’s nice when it’s not you.

Consulting is very much a ‘drinking from the firehose’ type business.  You either have too much work or not enough.  There is no such thing as the perfect amount of business.  As a solo developer there’s only so many hours you can work so then you start thinking of having employees.  We were extremely lucky to have found the employees we had since most lasted five or more years and were exceptionally productive.  But dealing with employees is hard when it comes to hiring and firing (we had a handful that didn’t last 90 days for one reason or another).  They all had their strengths and weaknesses and some you can put in front of a client and others are less than ideal. Some are great at debugging and others are not. Some are great a developing new code and others are not.

I always felt that our employees were an asset to us.  I always tried to hire people that were smarter than I am (some would say this is a very low bar, I know) and some competitors were aghast that I would ‘train my future competitors’.  Having a good consulting employee is not the same as creating a future competitor.  If they were going to have their own business they’d have had one already.  I guess that’s always been one of my beefs is that people think that having a business is the same as having a job and they are far from the same (see all the arguments above).

Do I have as much time flexibility in my job as I did consulting?  It’s really hard to say during a pandemic since all of the robotics programs I’ve been a part of are on (hopefully) temporary hiatus, the music festivals we usually go to were cancelled, and we aren’t meeting in-person with the groups we usually do, and travel was restricted for most of 2020.  The company I’m with has people scattered across four timezones so there is a lot of flexibility in when people start and end work and we’re all remote anyway.  As long as the work gets done no one minds much when you start and stop or if you work weekends (I have quite a few coworkers that are being their kids teacher at this point and keeping them going via Zoom with their school teachers – honestly I have no idea how they do it).  But honestly, as a consultant I worked most weekends and did a fair amount of work at night too so I think I’m working a more reasonable and balanced workload now than when I was a consultant.

Consulting was fun and rewarding.  It has perks that are amazing if you have a good accountant and follow the rules and have multiple people that can help split the work load and responsibilities and you’re willing to put in the work (like writing blogs and developing products!).  The pain of consulting is oftentimes not worth the hassle.  Before you leave your full time job for consulting think long and hard about doing it and maybe think about all the negatives.  Maybe give me a shout to try and talk you out of it.

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!

Xojo Can’t Math

Pop on over to Thom McGrath’s blog post about the ongoing saga of a 12 year old bug in the Xojo compiler. It’s an interesting, long, and complex issue that could affect your code if you use unsigned integers in your code. Admittedly, this bug may only affect a very small percentage of applications but it’s still a bug.

I think this saga exposes several things about Xojo. First, the way they use Feedback is fundamentally broken. For this particular bug they say it doesn’t affect many people because it has no points but because they’ve closed it the item won’t accumulate points. Voila! Nothing done about it in 12 years. Circular logic at its best.

Secondly, I truly believe that since they do not have a compiler engineer this bug won’t get fixed. Heck, most likely can’t get fixed because of lack of experienced personnel. Compilers are not simple things. I don’t buy for a second that Xojo has enough developers for the product they have.

The thread on the Xojo forums was long and contentious, and I don’t think Xojo did themselves any favors by arguing. While I appreciate Geoff talking to us in the forum it does kind of amplify the perception (reality?) that’s he’s not really listening.

I think I can say this with near 100% surety: We want Xojo to succeed. Many of us need Xojo to succeed for our careers and business.

Anyway, happy coding everyone!

Wanted: Xojo ‘Snow Leopard’ Release

Ever since Xojo adopted the Rapid Release Model (RRM) there have been critics. The critics said that it was leading to a perpetual state of beta software. I’ve always felt that the assessment was a little too harsh but I have definitely come around to that thinking.

In my many years of Xojo consulting I played the “what version of Xojo do I dare use for this client?” For a few years the Windows drawing issues meant that one of the early Xojo 2017 releases was my gold standard. And then finally Xojo 2019 R1.1 was my gold standard for all projects. I haven’t fully tested it but I’m really hoping (and frankly needing) that Xojo 2020 R1.1 eventually becomes my new gold standard.

The shear number of new things between 2019 R1.1 and 2020 R1.1 is staggering. People are still finding bugs in API 2.0 that haven’t been addressed. And yet Xojo is on their way to major updates to iOS and adding Android, adding Helpers and who knows what else.

Feedback is broken for intents and purposes. The top 20 list is all feature requests with the exception of two items that are most definitely bug reports. One is a Web 1.0 WebListbox issue that might as well be closed now and the other is a Xojo framework issue with ParseJSON and that might as well be closed now too with API 2.0 out. Everything else on that list would be freaking awesome, but only if the rest of Xojo was more stable and less buggy.

Monday a Feedback Report 61895 titled “Do a Xojo ‘Snow Leopard’ version that focuses solely on bug fixes and performance improvements. For those that don’t know the reference, Apple released a version of Mac OS X named Snow Leopard that did very little in the way of new features but worked on stability, speed, and bug fixes. It’s still considered one of the better OS’s that Apple ever made. I think in large part because they kept their promise of fixing stuff and not adding major new features.

Anyway, back to our Feedback Report. Within hours it had climbed to number 13 on the top 20 list and then was closed by Geoff as “Not Actionable’. This seems intentionally obtuse on his part because I know several long-term developers that have advocated for such a release for a long time. I even wrote about it in June of 2018 https://www.bkeeneybriefs.com/2018/06/xojo-and-the-rapid-release-model/. So this is not a new idea.

Look, I’m a developer, too. Working on bugs is no fun (especially for obscure ones) so I get, from a developers perspective, that new features are way more fun and exciting. But just once I’d love to get a Xojo that didn’t have a bunch of new classes, API, targets, etc. just so that the existing things we have becomes better, more stable, less error prone, and an IDE that is faster and more efficient.

Is this idea perfect? Oh heck no. I realize that bug fix releases might not attract new users. But it does make people like me happier and a happier Xojo developer is a good thing. I think marketing should be able to make hay with the sunshine that results from a better product.

Is that too much to ask?

What About Bob?

A number of recent forum threads and blog posts have invoked my name.  I mostly didn’t respond to those individual posts and decided to write one big post.

I’m still in the community:  Sort of.  I took a full-time job just before the pandemic hit the US and I’m so thankful that I’m able to provide for my family in a stable and hopefully long-term position.  Xojo consulting wasn’t keeping me very active and that’s even after it was just me doing the Xojo consulting.  You can chalk this up to a variety of issues that all revolve around Xojo.

Consulting leads just don’t show up like they used to:  At the height of BKS we had 4 full-time developers and a DBA/Project manager.  That means we picked up at least two big projects a year and a ton of smaller filler projects.  Those just don’t show up any more.  Do cross-platform apps now use a different language?  Is it because of Xojo quality issues?  Is it because of bad press?  Is it because I expressed my displeasure with Xojo?  A global pandemic that greatly accelerated a looming recession? Sure.  All of the above probably.  But I know other consultants that are in the same boat though a select few have flourished during this period too.  So maybe it’s an ebb and flow thing.

The whole API 2 fiasco:  API 2 is of dubious quality for existing projects.  If you have a couple hundred thousands of lines of code in classic API code you simply do not have the time or resources to convert.  What’s worse, is that I have several Windows apps that crash (as in poof!  No crash log or catchable exception) in any version of Xojo that uses API 2.  This one thing keeps me using 2019 R1.1.  (Update, this was resolved in one app that used WebKit for the HTMLViewer renderer and is marked as fixed for 2020 R1.1).

If you want proof of this statement ask anyone at Xojo when the entire IDE is going to be converted to API 2.  That alone is a multi-year project and I don’t care what Geoff says – they are NOT eating their own dog food when it comes to API 2.  They decided that it wasn’t worth converting to API 2 for existing work.  That says volumes if you ask me.

More targets less engineers:  Xojo used to have only desktop targets which meant that everyone on the development team focused on desktop.  Since then they’ve lost/fired engineers and created more targets.  How much time and effort has gone into iOS, and now Android development?  You simply cannot tell me that they are adequately staffed to handle all of these targets.  Web has been a multi-year project as has Android.  In the meantime they touched every single class in Xojo for API 2.0 and given the results I’m not sure the platform as a whole is better for it.  As far as I know they have no *dedicated* compiler engineer and that seems to be an issue with 64-bit debugging.

Locking of threads and banning of users on the forums:  It’s their sandbox and their tools so they can do whatever they want with their forum.  But it sure seems like a lot of threads get locked (by non-Xojo employees!) and posts get deleted rather quickly.  Look, I get it, they want to present a consistent look to the world but the almost fanatical control of the forum feels…desperate. Banning of users should be the very last resort.

The comical stance that professional developers are not the core users of Xojo:  Xojo will deny this, of course, but I’ve been around for 20 years in this community.  I’ve seen a lot of developers come and go.  There’s the hey, this product is very cool phase.  Then there’s the now I’m going to do something hard with this tool phase.  Some get through it.  Many don’t.  With the many dealings with former Xojo users not once have I heard of Xojo contacting them on why they left.  

Hell, maybe the users that know Xojo the best are the hardest ones to please.  Maybe it *is* easier to find new buyers than to appease existing customers for renewals.  But it’s the existing users that are the best marketing tool of the company in my opinion.  How many times have I promoted Xojo over the past 20 years?  Many people accused me of working for Xojo and being a shill.

Trust is Earned:  One of the things that we, as developers, need is trust in our tool of choice.  For many developers that have been around a long time that trust was earned a decade ago.  The API 2 fiasco and the many new targets has eroded and downright sheared off the goodwill for many of Xojo’s most ardent supporters.  I don’t know how the company recovers from those hits without being brutally honest with users and themselves.  They simply cannot be everything to everybody.  With Swift getting ported to Windows and .NET Maui on the horizon, in addition to other tools that are making big strides in cross-platform development Xojo needs to be laser focused on quality releases or they might find themselves in the dustbin of history.  Earn back our trust and I think they’ll be rewarded.  Keep mucking around with the above issues and the future doesn’t look bright.  Again, in my opinion.

Where I’m at:  I’m still doing Xojo programming for a living.  I am not doing much consulting because I don’t desire to.  I’ve always tried to do the best for my clients and, frankly, Xojo is not living up to my expectations for my clients.  I think they’ve forgotten where they came from and what developers LOVED about the product.  I’m sure there are some people that find Xojo because of web apps or iOS but I can’t imagine it’s a lot of new users.  I could be wrong on that but I’ve wondered for many years who is Xojo’s audience.

My products, the ones I’m still selling, are getting minimal to no effort on my part simply because I’m not doing much consulting.  These products were things I used on a regular basis and with no consulting there’s no usage and no need to update.  I’m looking for homes for them because they deserve to have a developer that cares about them.  Some in the community have suggested open sourcing them and I can tell you right now there is no freaking way that’s going to happen.  No argument in the world is going to convince me otherwise so just stop sending me that recommendation.  I’m not asking for much (in my opinion) to get these products but perhaps that’s also indicative of how poor the Xojo 3rd party market is right now and an overall indicator of the health of Xojo.

I wish nothing but the best for Xojo.  This last year and half has soured my outlook to the point where I just can’t recommend it to anyone that’s serious about a commercial desktop applications.  I haven’t done a web project in well over a year and it’s been many years since I’ve done an iOS project in Xojo.  Without outstanding desktop support I’m left in limbo and wondering why the hell I keep renewing a license.

I know I’m not the only one with these thoughts and ideas.  Feel free to add comments below.  Please try to be respectful towards Xojo employees and each other.

Xojo 2020 Release 1

Xojo 2020 R1 was released today.  The last major release of Xojo came nearly 9 months ago.  This much anticipated release has a completely rewritten from the ground up Web API that takes Xojo web applications to a whole new level in terms of look and feel with themes, new controls, and new functionality.  This release also brings a ton of new and improved functionality to desktop applications too.  Let’s dive into it!

Web 2.0

The elephant in the room in this release is Web 2.0.  Web 2.0 is a complete reimagining of what Xojo web applications look like.  

Controls galore.  Web 2.0 comes with all of the web 1.0 control (see exception below) and a host of new controls that look and feel really nice.  Among the new controls:  Audio Player, Breadcrumb, Chart, Date Picker, Pagination, Search Field, and a host of specific TextField types like email, number, password, and telephone.

Every standard control (buttons, text fields, etc) have a wide variety of new options that I think will make developers happy.  The new WebListbox has monster changes and I really can’t do it justice in this review.  Among some of the big additions is the ability to load data dynamically using the WebDataSource.  If you’ve used iOS in Xojo it acts pretty much the same way and allows you to have practically unlimited numbers of rows of data and it will load the data as the user scrolls.  This means you don’t have to page your data (though you can if you want by loading the data manually in combination with the new Pagination control).

Even more interesting are the new WebListbox Cell Renderer classes.  In this release there are four built-in with DateTimeRenderer, ImageRenderer, StyleRenderer, and TextRenderer (the default renderer that doesn’t need any special action on your part).  The DateTimeRenderer lets you specify the Date and Time format styles but also a Relative Style (like “Today” and “Yesterday” values with time) and it also localizes the data to the users locale.  The ImageRenderer is pretty straightforward to view images, the Style lets you set the style of an individual listbox cell and, of course, the TextRenderer is the default.  The WebSDK example comes with a Button Cell and Color Cell renderer too so it should be exciting to see what developers do with for this.

While Web 1.0 had WebStyles they really were hard to use. Web 2.0 uses Bootstrap and that gives you an incredible amount of variety available in your Xojo web applications.  While there’s a default bootstrap theme there is no theme editor in this initial release but it’s not so hard to change the theme on your own.  One way to change the theme is to go to https://pikock.github.io/bootstrap-magic/, save the css file to your computer, rename the file to boostrap.min.css and add to your project.  Users can download pre-made bootstrap 4 themes from bootswatch.com.  Unfortunately the IDE doesn’t render these themes very well but it works at runtime.

Web 2.0 projects compile only to standalone now so you no longer have the option of using a cgi version.  Xojo Cloud users automatically get load balancers for your applications and you get the same number of application instances as you number of cores on your server plan.

While most of Web 2.0 is very exciting and enticing those that have an existing Web 1.0 project will most likely not be very happy.  The conversion process is a one way process and not everything converts.  WebAnimator does not have a Web 2 counterpart and WebStyles are completely reimagined so while the compiler won’t complain if your code uses an old WebStyle it’s pretty much ignored.  I would even say that the conversion to Web 2 is broken to the point where it would be easier to rewrite your project into Web 2 than it is to try and convert it.  Default control heights in Web 2.0 (38 pixels tall but depends on the theme) are considerably bigger than Web 1 (22 pixels) so I find it hard to imagine that most layouts wouldn’t need considerable work to get correct for Web 2.0.  It sucks, but that’s the reality of it.

There are some missing parts in the IDE that are disappointing as well.  The WebToolbar and WebStyle editors are missing in Web 2.0 but the good thing is that both can be created in code.  Web 2.0 does not have control sets implemented at this point.

It’s also disappointing that not all of the Web 2.0 examples are working properly or are so simple as to be useless in learning how to use Web 2.0 (I’m looking at the WebListBox examples).  The documentation for Web 2.0 isn’t as clear cut as I’d like too and I disagree with some of the property groupings for the Inspector.  For example in a WebLabel and WebLink there are Font properties to set the font properties but a WebTextArea does not have this and you have to manually set them via the Style property.  Why does one control have it exposed and another one does not?  Xojo has one shot to impress developers with this release and inconsistency is a bad look in my opinion.

Everything Non-Web 2.0

While Web 2.0 is by far the biggest part of 2020 Release 1 but it is not the only important change.  Here are some of the highlights.

Desktop Changes

Listbox Header drawing events.  New in R1 is ListBox.HeaderBackgroundPaint and HeaderContentPaint.  This allows the developer to have total control over the drawing of the headers.  Want to draw an image, or change the background color, or even change the sort indicators?  No problem now with these two events.

TextArea now has a UnicodeMode that allows you to change the way the control treats characters.  The default is Native and that doesn’t change anything.  The Characters setting counts by the single character regardless of the byes used and the Codepoints setting counts by number of Unicode Codepoints (bytes) it requires.  The Codepoints way is what you’d have to use for an emoji.  This is a nice addition from the the old Xojo Framework.  They also now have a String.Characters iterator.

For years Xojo developers have had to rely on third party plugins to create PDF documents in Xojo applications.  New in 2020 R1 is the PDFDocument class that allows you to create a PDF document fairly easily using simple graphics object commands.  PDFDocument does not support transparency so you’ll have to consider the order that you’re drawing items and you might find it hard to create some forms of documents.  All in all this is a great addition to the product that many people will like.  PDFDocument is available in all targets excepts iOS. It’s not perfect but for many users it will be good enough and hopefully they’ll add some features to it in future releases.

Linux applications now have a Normalize Control Sizes build option.  It normalizes the controls widths/heights, removing theme specific padding and adjustments to make controls on any Linux distribution look similar.

XojoScript’s can now be saved in their compiled form into a MemoryBlock and that means you can read and write them to a file.  This should allow XojoScripts to be considerably faster since they may not have to be recompiled every time they’re used.  If you use XojoScript I think you will really like this feature.

HTMLViewer has a new event called JavaScript request that gets raised when using the ExecuteJavaScript and ExecuteJavaScriptSync methods.  This should eliminate the need to use third-party code to do the same thing.

Project loading and compiling of desktop applications is considerably improved.  In my testing it’s about the same speed as Xojo 2019 R1.1. Gone is the slow down users experienced after they did a check project.

There are dozens of other bug fixes and changes that I could tell you about but I’ll leave the joy of reading the release notes to you.  Why should I have all that fun?

Overall Impression

Xojo 2020 R1 is a huge release that’s been in the making for long time (if we’re being honest the wait was too long).  Web 2.0 has a lot of exciting new features, controls, theming options that should excite developers.  Converting projects is very hard and I think learning the new controls is harder than it needs to be with incomplete documentation and examples that are either not working or weak.  I really don’t have a real good feel for how stable Web 2 is simply because I’m not working on any web projects currently.  I suspect that there are bugs to be found as more people start stress testing it.  But it’s a good start and I look forward to the missing pieces being filled in as time goes on.

Obviously Web 2.0 is the big star of this release but the PDFDocument class is a great addition that users have been asking for years.  The other bug fixes and changes are also big and even if you aren’t a Xojo web developer this is a big and important release. I’ve been using R1 for desktop apps (Mac and Windows only) and I’ve found it to be stable and I have no complaints (other than no being able to turn off API 2 items).

What say you Xojo developers?  Is Web 2.0 worth the wait?  Is is stable?  What do you think it’s lacking?  What do you think about the desktop changes?

Whither Xojo 2020 Release 1

The Xojo drought we’re experiencing in 2020 is starting to become ridiculous.  The last release, Xojo 2019 R 3.1, was released January 23rd, 2020.  As of today we’re at 152 days.  

The longest previous delay between releases was 143 days between Xojo 2012 R2.1 (January 12, 2013) and 2013 R1 (June 4, 2013).  If I recall correctly this was the transition from Real Studio to Xojo and was when the IDE went through a massive redesign (and ironically I was accused of causing a 6 month delay due to a blog post).

Come on Xojo.  There are plenty of bugs and enhancements that should be shipped NOW.  Is the Rapid Release Model being replaced with once a year monolithic releases?

May We Live in Interesting Times

I’ve been a Xojo consultant for nearly 20 years.  BKeeney Software has worked on dozens of commercial applications and untold numbers of private projects during that time period.  Consulting is both an extremely rewarding and terrifying business since income can be so variable.  We’ve had multiple employees for years and providing health insurance costs is an expense that’s ever growing.  Having your own business is hard in the best of times.

Over the past twelve months we’ve had two employees leave on their own volition to pursue other employment opportunities.  During that same period the amount of new projects slowed to a trickle and even existing clients haven’t brought in as much new work as they have in the past.  Where once we routinely acquired new projects it just didn’t happen as much in 2019.

Consulting is a weird business where every client wants their project done last week for as little money as possible and then get yelled at when you tell them version 2 is going to cost a lot more money.  As a consultant I’ve had to compromise with what’s best for a project with what the client is wiling to pay for.  It’s a constant struggle and one that I can’t imagine going away as a consultant.  

Earlier this year I was presented with the opportunity to take a full-time job as a senior developer for a company that uses Xojo along with other programming technologies.  I have accepted that position and started with them in a full-time capacity a few weeks ago.

BKeeney Software will continue to support existing clients to the best of our ability.  We will not be taking on new clients and we will have to be very selective in taking on additional work.  We hope the transition is as painless as possible.  When we cannot do the work we will give clients a list of Xojo consultants to contact and we will coordinate with them as best we can. If you’d like to be on that list let me know. Send me an email with your qualifications, types of projects that are in your wheelhouse, and maybe even a client reference I can contact.

Several Xojo developers that know me socially (and knew about the new job) have asked about our products, mainly ARGen, Shorts, and Formatted Text Control.  At this point in time we will continue to offer support just like we always have.  However, we are hoping to find new homes for them and have already reached out to various developers that we feel will treat them and our existing customers right.  Our products were mostly driven by consulting and if we are not consulting we have no need for the products.  Since we know a lot of developers use these products we’d love for them to stay in the community and stay actively developed.  If you are interested in acquiring the rights to any of the products, please contact us.  

I love the Xojo community and its users.  I’ve never found a community that is as passionate about a product as the readers of this blog.  I’m not leaving the community – but transitioning into another form.  My new job uses Xojo. It’s a very large project and is certainly bigger than anything I’ve ever worked on before.

I’m looking forward to working on a set of products with a team of dedicated developers that are working on products that matter while providing a stable work environment for my family.  Certainly the events currently happening in the world do not make consulting any more stable so the timing of this opportunity was exceptionally favorable.

I still plan on doing some blogging about Xojo but it will certainly slow down.  As Web 2.0 and Android hits I will kick the tires and give my opinions of them because…well…I always have an opinion.  🙂

Stay safe and I look forward to seeing you all again at a Xojo event! Happy Xojo coding!