There’s been a feedback report (47975) for several years asking for the ability to use enterprise code signing certificates for building our Xojo iOS applications. So far nothing from Xojo but there is a way to create enterprise code signed iOS app for Xojo – it just takes some extra work.
Here are my steps to building an iOS enterprise app:
Build your app in Xojo with the Build for App Store switch turned off.
Build the built app into a folder named “Payload”
Compress that folder. Change the name from Payload.zip to “yourappname.ipa”.
In your favorite text editor paste the following code. Replace App_ID_Prefix and App_ID with the valid information for your app from the Apple Developer website:
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>application-identifier</key>
<string>App_ID_Prefix.App_ID</string>
<key>keychain-access-groups</key>
<array>
<string>App_ID_Prefix.App_ID</string>
</array>
</dict>
</plist>
Save this file as Entitlements.plist
Go to the Apple developer website and download your enterprise developer provisioning profile.
Drag unsigned .ipa file to the top box, or use the brown button.
Drag your mobileprovision file you downloaded from Apple to the second box, or use the browse button.
Drag your Entitlements.plist file you created earlier into the 3rd box, or use the browse button.
Select your name from Keychain Access List. For example it might be, “iPhone Developer: Firstname Lastanme (XXXXXXX) from the dropdown.
Click ReSign! and with. The resigned filed will be in the same folder as the original with (Resigned) in the name.
Voila! Move that resigned file into the appropriate place and remove the Resigned so it’s back to the yourappname.ipa” name.
Now you can deploy your enterprise code signed app to any iOS device.
Each iOS device may have to trust the certificate. Go to Settings -> General -> Device Management.
For it to work properly in MacOS Sierra (and above) I had to recompile the ReSign app in Xcode (no code changes).
It seems like a lot of steps but once you get it working it’s not hard after that. One thing we learned the hard way is that enterprise certificates expire in a year so plan renewing the certificate and getting a new version out before it expires.
Hopefully someone will find this useful.
[Update]: My iOS Build settings for Team are set to “None”
BKeeney Software has released version 3.2.1 of the Formatted Text Control, a canvas based word processing control for Xojo Mac OS X and Windows applications. The FTC is an alternative to the built-in TextArea control and allows for in-line graphics, hyperlinks, custom components, better RTF support and much more. The demo project has quite a few examples, including a Masked Text Field, XojoScript example, Embedded FTC (in your own canvas), as well as a word processor with page view.
The Formatted Text Control costs $150 and is 100% unencrypted Xojo code. Version 3 and above requires the use of the Text Input Canvas plugin (included in package) to allow for proper text handling in Cocoa builds.
This version has a number of bug fixes reported by users since release. It is recommended for all users. Registered users should be receiving an email from our automated distribution system.
Bug Fixes:
Fixed issue where all StyleRuns after a hyperlink will also be marked as hyperlink
Issue #4074: RTF clipboard ignores hyperlinks with umlauts and cuts them
Issue #4087: missing RTF space after “\kerning0” keyword
Issue #4130: FTXojoScriptField: Left part of the text is hidden by the section of the line number.
Issue #4135: Migrating texts from a TextArea to the FTC (Ich migrieren Texte aus einer TextArea in das FTC)
At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’). These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal. This will be an on-going series since I had well over 50 slides and left about 150 out. So when I get bored I’ll bring these topics up.
Variants are a very powerful datatype in Xojo. It allows you do set it to anything including null. It’s a wonderful thing to use in ListBox row, column, and cell tags where the you, the developer, could be anything into it.
Variants are evil too if you use them in ways you shouldn’t. Take the example below:
This is truly a made up example but it shows how subtle Variants can stab you in the back. Just adding the three Variants together where one is a string, the other an integer, and the other a double, can change depending on the order they’re used. Frankly, I don’t care how the compiler came up with the value because in both cases it’s ‘wrong’. Wrong in the sense that it depends on order and no programmer should have to depend on order.
How did we get here? Variants have implicit conversion. So if you try to add a variant to an integer it attempts to convert it to an integer. If you try to add it to a string it converts it to a string. What happens if you have a number inside the string and it really should be a string? The answer is that it depends.
That’s just a poor use of the language, in my opinion. Xojo is a strongly typed language and I like that it won’t let me willingly add an integer to a string. I like that I have to explicitly convert from one datatype to another. Variants break that rule in that they’ll implicitly convert from one to the other and the compiler will never tell you.
The variant datatype allows the Xojo developer to query what it is. For example you can use the Type method to see what variable type is it. You can see if it’s an array using the IsArray method. You can see if it’s a Numeric value using IsNumeric but you get into the same problem where assigning an integer 8 and a string “8” will both return true from IsNumeric. So it’s a bit of a problem because it could be either. We should rename it Schrödinger’s datatype because it could either either value until the compiler asks for it.
Auto was introduced in the Xojo framework (deprecated now?) to replace Variant. It didn’t do any implicit conversion for you. In fact, it wouldn’t even tell you what datatype was in it and the only way to do was to use Introspection. It certainly solved the problem of implicit data conversion but replaced it with a harder to use datatype. For what it’s worth I didn’t think it was hard to come up with your own “what is your type” methods using the extends keyword but it was something that many Xojo developers weren’t comfortable doing and frankly seemed silly to rely on Introspection to do that work.
I turned down a project many years ago because the original developer had used Variants for everything. Didn’t matter what (local, object, global), they used variants and they wanted me to tell them why their project wasn’t working right. When I told them I wouldn’t do it and asked why they had used variants for everything they simply said, “Because they could be anything. Why not use them?”
I know that many languages are not as strictly typed as Xojo and perhaps that’s where they came up with that mentality. I find some comfort in knowing that if I try to put a string into a numeric value the compiler won’t let me unless I explicitly convert it. I like the certainty of knowing that my data can’t change on my unless I tell it too.
Variants are good for storing things temporarily. Stashing values and objects in a Tag for use later is convenient and useful and a good use for them. For everything else it makes sense to use a datatype. If you finding yourself using a lot variants you should rethink what you’re doing because they can subtly make your calculations change in ways you don’t expect.
Long-time Xojo user Kem Tekinay created a wonderful post today on the Xojo Forums on WeakRef and where and how you would use them. Highly recommended reading at https://forum.xojo.com/54352-about-weakrefs/
At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’). These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal. This will be an on-going series since I had well over 50 slides and left about 150 out. So when I get bored I’ll bring these topics up.
Xojo has evolved over the years. Many of the global framework (the classic framework) classes set an error bit or error code when an error occurred and the developer has to check to see if there is an error and deal with it accordingly. Many developers don’t check – mainly out of ignorance, and that’s a problem.
The newer (but soon to be deprecated) Xojo framework (and we’ve been told the API 2.0 framework as well) throws Runtime Exceptions to report errors. The exceptions definitely get your attention because, well, an exception happened. The problem is that many Xojo developers don’t catch exceptions anywhere in their application. This results in dialogs like this:
Users hate seeing this and it’s unhelpful to the developer because it tells them NOTHING about the cause of the error. And, their application quits making the user really unhappy.
The Application object in every Xojo project has an UnhandledException event made to catch any exceptions not caught anywhere else. It’s declaration is this:
By returning True you can keep the application from quitting. Just returning true is just as bad, perhaps worse, than the first dialog because the app had an exception and the app might now be in an unknown state and the user has no idea that it happened. At this point what happens is anyone’s guess. Silent errors are a bad thing. Never do this.
A better way is to use the App.UnhandledException event to report that something happened so the user can decide what to do. Ideally, you’d like to get some information from them so the developer can get an idea of what’s caused the exception. What were they doing when the exception happened? What is the stack trace?
If you are are unaware of what the Stack Trace is this is the call stack your app is current in when the exception occurred. Maybe you called the Pushbutton1.Action that called ClassA.Method1 which called Global.MethodB which called Global.MethodC. This information (although not as neatly) is in the stack trace. It is sometimes invaluable in helping find and fix bugs.
BKeeney Software created a generic error reporting system years ago that when put in the App.UnhandledException shows the user a dialog like this when an exception occurs. You can tailor the message to suit your needs.
We generally don’t quit apps when exceptions are raised, but it is something that some clients want. The Report Error button then takes them to another dialog asking for more information. The user can easily bypass this section by pressing OK. Hopefully your users are nice and they’ll report the error.
If they select the E-Mail Bug Report or Save Text File button without putting anything in the TextField we present a dialog begging them for more information. Sometimes this works but not always.
Regardless, the next step in the process creates an email or text file. Sending an email requires the use of the computers built-in email client and we find this has advantages in that we get the users email address. A sample email goes something like this:
In our email we get the type of exception, the time, the method location, basic system information, the user description (hopefully), and the stack trace. A vast majority of the time that’s enough to find a bug. Sometimes it’s not but at least you can email them back. The text file still requires them to send it to us via email so we helpfully include the support email address.
You need to implement something similar to this exception handling strategy. It will help your customers provide feedback to you so you can fix bugs. This seems like the least you should do. With the upcoming API 2.0 with API’s that throw exceptions rather than setting error codes this will be more important than ever. I’m sure I’ll talk more about Exception handling strategies once API 2.0 is released.
What other types of things do you do for error reporting?
At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’). These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal. This will be an on-going series since I had well over 50 slides and left 150 out. So when I get bored I’ll bring these topics up.
Nearly all of our consulting projects are database driven applications. It’s why we’ve created the tools to help with these projects like ARGen, which simplifies our interactions with the database, and BKS Shorts, which is our own reporting tool. These tools are invaluable in getting our work done in a timely matter.
In a database application it’s typical to have a List of something. A common example of this is a Customers list. In that list the client typically wants the ability to Create, Read, Update, and Delete (or CRUD) a customer with varying degrees of rules behind it (like do they have permissions to add or delete a customer?).
During development we get the List form going, add the controls to be able to add a new record. Then we create the Add/Edit form that allows us to test those capabilities. We create a few, update a few, delete a few customers and then move on. Maybe the client wants search capabilities so we add that to the List window and when we’ve tested it against our half dozen or so records we move on to the next task.
There is nothing wrong with this process. It works and it’s fairly efficient as far as it does. However, there’s one thing we’ve skipped that’s really important but also difficult to achieve.
So far we’ve test with *maybe* a dozen records. What happens when the client adds 10,000, or 100,000 Customer records? Does the list form take a long time to load? Does the search function take a long time? What about the Customer popup menu’s that you’ve scattered throughout the project – are those now slow, unwieldy, and unusable?
Unfortunately, with the way we implemented the project we don’t know how any of this works since we only have a dozen records. So it’s really important to have adequate amounts of test data. Creating 10,000 new customers using your new interface would take a long time. So what can you do?
There are tools out there that will help generate data sets. These tools allow you to create thousands, even millions of rows of realistic data. Randomized male and female first names along with a last names is a great way to generate customer names. Many tools allow you to add random dates in a range, random IP addresses, random values from a list you provide and so on. The sky is the limit when it comes to what sort of data developers need.
Now, when you do your testing you see how your application reacts with a lot of data. I almost guarantee that it will act different. Do you need to switch to a data-on-demand listbox? Do you need to put an index on a common searchable field to speed up indexing? Do you need to implement Full Text Search in your database? Having a huge amount of data will answer these questions for you.
I once worked on an accounting application in VB6 where the original database designer using an Access database and did an account balance on the fly iterating through bills, checks, journal entries, etc. With a few thousand rows of data in each table this process took a second or two for all balances on a local machine. When this database was accessed over the network it took 5 to 7 seconds. When we converted our first client database it took 30 to 40 seconds for EACH account! Obviously this was not acceptable performance from an accounting application meant to be used daily by general contractors with hundreds of employees and tens of thousands of customers. The solution was to have a current balance value that was stored and then updated when a transaction occurred. We could have saved ourselves hundreds of hours of rushed development time (and much stress and heartache) if we had tested with large amounts of data much earlier in the process.
I mentioned adding an Index to a field earlier. One word of caution on this: it’s tempting to add an index to every field you’re searching on. Don’t do this! Only added indexes to the most important fields in a table. For a customer maybe the two most important fields are phone number and name even though you search on City and things like that. Indexing is extra work for the database so performance can take a signifiant hit with indexing a field.
Since the toolI’ve been using to create test data is no longer being sold I’m curious what you’d recommend. Do you have a favorite tool? Or is this a tool that would be of use to the community?
The release of macOS 10.15 Catalina is fast approaching. One of the new things that Apple has done in this release is increase the security even more. No longer is simply code signing your app good enough. Apple is now notarizing applications meaning that applications and disk images are submitted to Apple for their seal-of-approval that ideally have some minimum level of scrutiny that the item is not malware. Presumably this means they can identify bad actors even faster by seeing patterns. Good for consumers but it’s a pain for developers.
For those developers using Xcode it’s no big deal as it’s part of the built-in process. For Xojo developers the process is not nearly so simple. You still have to code sign your application and your disk image. We use AppWrapper from Ohanaware to code sign and notarize our apps. We also use DMG Canvas from Araelium Group to create disk images. AppWrapper can notarize disk images as well.
The process of Notarization is not as automated as one would hope. After you’ve code signed your application you have to click the Notarize button to send the application to Apple. This isn’t exactly clear but once you realize this it’s no big deal.
Notarizing requires some information for Apple. The first is your AppleID and since you’ve already code signed your application that should be a no brainer. The second is the application specific password. You can get this by logging in at AppleID account page at https://appleid.apple.com/#!&page=signin and then creating an app-specific password by choosing that option from the Security section.
The third bit of information that may be required is your short name ASC Provider. This information is not immediately obvious and your app may fail if you don’t have it. Note that the ASC Provider information is considered optional – until the process fails. Fun stuff. I had to look in the log created by AppWrapper to see this information:
Error: Your Apple ID account is attached to other iTunes providers. You will need to specify which provider you intend to submit content to by using the -itc_provider command. Please contact us if you have questions or need help. (1627)
To get your short name open Terminal and do the command shown here (this assumed Xcode 11). is your login username and is the password you created specifically for this application.
This will provide you a listing of the long and short names of all of your providers. If you’re part of multiple Apple developer groups you’ll get all of them.
Voila! Once you have the short name and input into the ASC Provider section of AppWrapper and DMG Canvas my upload completed and Apple Notarized my application and disk image that works perfect in Catalina.
Hopefully this is helpful. Any other gotcha’s that you’ve seen from Catalina?
Xojo 2019 Release 2 arrived this week, and to say that this is a massive release would be an understatement. Among a large number of bug fixes and IDE enhancements is the first release of API 2.0. With every release I say that you should test your projects thoroughly, but in this case it needs to be mandatory.
API 2.0
API 2.0 is Xojo’s latest attempt to make the framework consistent across all the classes and should be easier to learn and use than the old framework. The properties, methods, and event names of practically every single class have changed. Some have changed in subtle ways, and others in a bash you over the head fashion. What might be even more important is that classes that used to set an error bit or error code will now throw an exception.
Some of the most basic things in Xojo have changed. Declaring a variable has changed from using the Dim keyword to the new Var keyword. Declaring an array is the same but resizing it is now accomplished like this:
//Declare the array
var arNames() as string
//Set it to a new size
arNames.ResizeTo(SomeIntegerValue)
//Clear the Array
arNames.ResizeTo(-1)
In various conversations Xojo has claimed that many users new to Xojo are confused about declaring variables.I don’t claim to know a lot of other languages, but the few that I’ve looked up don’t appear to be any more helpful. Looking at JavaScript and Swift, neither requires the data type when declaring a variable. With no functionality enhancement this seems like a change for the sake of change.
Every Window and Control that comes with Xojo 2019 R2 has new events. Open, which admittedly can be confusing, is now replaced with the equally confusing Opening event. Close is Closing and so on. I have yet to find any direct mapping document of old events to new events and that’s a crime.
A complex control like the Listbox has dozens of events, properties, and methods and nearly all of them are renamed. Some make sense. ListBox.ListCount is now ListBox.RowCount. But ListBox.EditCell is now ListBox.EditCellAt. To append a row to a Listbox you still use ListBox.AddRow, but to insert a Row you substitute ListBox.InsertRow with ListBox.AddRowAt. I simply don’t see why AddRowAt is easier to remember than Insert (I could argue that InsertRow makes more sense).
Some changes I strongly disagree with. For example, Arrays in the old framework were simple enough to add items to:
dim arMyArray() as integer
arMyArray.Append 1000
arMyArray.Insert 0, 2000
With API 2.0 the Append and Insert methods are replaced with AddRow and AddRowAt. Again, one can argue that removing Insert and replacing with AddRowAt is simply a poor use of the English language.
Pre-API 2.0 Projects
The good news is that existing pre-API 2.0 projects will work with only a few modifications. In our projects (Task Timer, Shorts, ARGen) there were little to no changes required to get them to compile in R2. And the good news is that you can continue to use the old API in R2. The Code Editor AutoComplete will show you the old API and the new API with the old API call in Red and show you the new API 2.0 method or property.
Starting a new project in R2 will only show you the new API and events. Certainly one of the drawbacks is that Xojo projects created in R2 are not backwards compatible. Xojo has never really guaranteed that newer versions would be compatible and this is one of those cases where it’s simply not possible (theoretically if you never implement any events it will work).
My advice: Treat R2 with kid gloves and make backups of your project files before you play with it.
Events
Let’s talk about events for a bit. I’ve already hit on the Open event that is replaced with Opening and Close that is now Closing. I find nothing wrong with the new event names, per se, but anyone with an older project, or someone taking an older class and putting it into R2 must be extremely careful. The old Open and Close (and other) events will fire as expected – until someone implements the new API 2.0 event like Opening. Once you do that the old event no longer works. This has the potential of really messing with legacy products that use the old Events and new users not knowing the difference and implementing new events and crushing functionality.
Frankly I find events to the most problematic part of API 2.0 since I, as a provider of 3rd party code, can’t enforce that a Xojo developer use the new or old events. It’s going to be a nightmare for the next couple of years (maybe forever?) as new people find old classes and implement them in their new R2 projects. Events cannot be coded out with #if statements. There is simply no way to control which events to use in a mixed environment.
If you’ve created your own control subclasses with custom events let’s hope you don’t have naming conflicts with the new event names. The only way to solve this is to change your Event definitions in a pre-API 2.0 version of Xojo.
String Classes
Despite being a great idea, the Text datatype from the Xojo framework never really caught on. As part of API 2.0 many of the Text methods have been brought to the String datatype. As with all the other classes nearly every method and property name has changed in some way, shape, or form.
The biggest change, and perhaps the most problematic, is that the string functions are now zero-based. The first character of a string is zero and no longer one. The InStr method has been replaced with IndexOf (bad name in my opinion) and instead of returning a zero if the search string is not contained it will return a -1. Don’t get me wrong, this is a good change in the long run, but when developers are converting their projects from pre-API 2.0 things like this are going to bite a lot of developers as it’s not a direct replacement. You can’t just simply use IndexOf to replace InStr because it will break your code. Expect some grumbling about this from the greater community.
Date and DateTime Classes
Xojo has deprecated (not removed) the existing Date class and has created a new DateTime class. This is mostly a rehash of the Xojo.Core.Date class but it uses Strings. The new DateTime class is not a direct replacement for Date since the DateTime class is immutable. In effect if you’re doing any sort of date math you’ll need to use the new DateInterval class. The DateTime class also does not have TotalSeconds but instead has a SecondsFrom1970 property. To get a New DateTime you use the Now shared method instead of creating a new instance of it.
FolderItem Changes
The FolderItem class was significantly updated on macOS and uses Apple’s more modern API’s. This should make file operations significantly faster on newer versions of macOS. FolderItem.AbsolutePath has been removed (it’s been deprecated for a while now).
Because of these changes you really need to be careful with URL Paths with query parameters. The behavior between R2 and earlier versions of Xojo has changed significantly.
Database Changes
The database classes have some welcome changes that have huge implications. Besides new classes, methods, and properties for everything to do with the database, any interaction with the database has the potential of throwing an exception. In the old API you had to explicitly check for the Error property. Now it will throw an exception that you have to capture and handle. This is both good and bad.
With ActiveRecord and ARGen we’ve been throwing exceptions for years when we found the database error property to be true. So not a big change for us, but for anyone that’s ever checked to see if a RecordSet is nil will be surprised when the exception is thrown. This is guaranteed to get your attention (many people never checked for the db error anyway!) but it will be a pain for many developers. Database code will need to be in a Try-Catch block, and doing this in a proper Transaction will cause some structural changes to your code.
RecordSets are deprecated. Long live the RowSet! RowSets are returned from Database.SelectSQL and instructions are passed through Database.ExecuteSQL. This is in contrast to the old SQLSelect and SQLExecute methods respectively. I can guarantee that I will mix the old and new versions up for many years to come.
PreparedStatements are no longer needed as they are built-in to the SelectSQL and ExecuteSQL statements. You no longer have to Bind the DataType and Value as the class does it for you. This is similar to what iOSSQLiteDatabase has done for years and hopefully this gives everyone more incentive to use them. PreparedStatements were a pain to use and this new method is considerably more streamlined.
One word of caution to anyone that uses the MBS SQL plugin: You must update to the 19.4 version as the database class changes required the plugin to be updated. Older versions of the plugin will fail silently and may cause other plugins to not load properly.
Other Things
URLConnection received some updates. In Windows 7 and 8 it picks up proxy settings. It also no longer hangs a Windows application when downloading large files or content. In Linux a ResponseHeader that no longer exists doesn’t crash the application. They also made the ResponseHeaders an iterable function allowing the use of For-Each loops.
They (finally) added BeginTransaction to the Database class. It’s silly that this hasn’t been part of the framework for the past decade.
The Code Editor received some interesting changes. Pressing Shift-Return on an existing If-Then or If-Then-Else will now break the statement into multiple lines. On a comment line holding the shift key and pressing Return automatically adds another line of comment.
The Layout Editor has some changes too. It now has a control to switch between Light and Dark modes.
There is now a number of new Refactoring Tools available and they fixed a number of bugs in the refactoring tools. They added a new code assistant for wrapping the selected code in an #if XojoVersion block (handy with all the new API 2.0 changes). The Add Event dialog has been updated to allow adding deprecated events when a checkbox is selected (deprecated events are in red). In the same light you can right-click on an event in the Navigator and choose to convert it to the newer API 2.0 event.
The FileTypes editor and Associated File Types editor have been combined into a single editor. File Type Roles have been renamed to None, View, Edit, and Execute. For MacOS you can set if the File Type is unique to the application.
Catalina may force many developers to upgrade sooner rather than later. The SelectColor function was updated in R2 to no longer use an outdated API function. Using SelectColor with an app built before R2 will reliably crash on Catalina. The only solution is to build with R2 or use NSColorPanel yourself with declares or the MBS plugin.
Documentation
Maybe I’m just an old school person and a curmudgeon but I find the lack of Old to New documentation extremely disappointing. Xojo has a Deprecated list at https://docs.xojo.com/Category:Deprecated but I find it worthless. I’d like to look at a single class at a time and have all of the events, properties, and methods showing the old name and then the new name along with any comments. I realize this is a lot of work but I’m surprised that Xojo didn’t create this documentation BEFORE doing any coding to use as their coding bible.
Any old example, sample project, old forum post, Google search result is now obsolete. BKeeney Software’s 65+ hours of Xojo training video that covers a good chunk of the Xojo framework is now practically worthless. I will be shutting the doors of the training site because it’s not worth my time (at this point) to redo over 200 videos. Xojo needs to convince me otherwise.
Deprecation Items That Have a Replacement
The Xojo IDE tries to be helpful in converting your projects to API 2.0. There will probably be a handful of things that will flag compiler errors in your pre-API 2.0 projects. If you Check your project you will get a rather large list of items that are deprecated that have a replacement. This list can be overwhelming and I recommend NOT doing global search and replace on these items because the code is sometimes quite a bit different. Good luck!
My Advice
If you have an existing project I would be very carefully with R2. Sure, try it out on a *copy* of your project, but don’t expect to use R2 right away. I’m almost sure that there will be changes to fix bugs and strong community objections to certain things. We already know that Reporting and XML was NOT done for R2 and I’m sure we’ll find other things along the way too.
For developers using R2, please be patient. Get used to the question: What version of Xojo did you start with? The community is going to struggle with the changes for a while and we have no idea that his means.
All in all I think there are some good changes to Xojo 2019 R2 but I also think that there was a lot of change merely for the sake of change. I’m not convinced that all the changes were for the better. But really, only time will tell.
The Good
IDE received quite a few tweaks
Lots of bug fixes and enhancements
API 2.0 is mostly consistent with naming (with some oddities for sure)
Lots of bug fixes and enhancements
Exceptions now thrown instead of having to check for error codes
FolderItem significantly upgraded for macOS
DateTime added as a replacement for Date class
The Bad
API 2.0 is not entirely done yet with more changes to come
Change for the sake of change in some cases
Exceptions for common and expected errors is not ideal
New String methods are not drop-in replacements because they are zero-based
The Ugly
API 2.0 event handling prevents API 1.0 events from being raised
Documentation woefully incomplete
All existing documentation, examples, videos are obsolete
What topics would you like for me to talk about with API 2.0? What do you like and dislike about API 2.0?
I’ve not been blogging very much lately. This summer was very busy with a lot of traveling including a trip to France to join my son who was studying in Lyon. We camped at several music festivals in Michigan and Kansas. In August I started coaching a rookie FIRST FTC robotics team and that’s been challenging. (They are smart kids!). Work-wise we’ve been pretty busy with a big consulting project that’s starting to wind down.
All of that aside, I’m just not excited about Xojo at the present time. 2019 R2 was a very good release until they added API 2.0 into it. I can’t talk about beta program specifics, so I’ll leave it at that since it has a ton of IDE bug fixes and enhancements. I was doing active development with the R2 alphas it was that good.
Unfortunately API 2.0 was added and despite months worth of beta testing and dozens of builds, it feels half-baked, buggy, and not ready for prime time. It feels like it could have used another couple of months to gestate and be fully thought out before it was released to the masses.
The new events don’t really solve much of anything and in most cases just make life incredibly difficult for existing Xojo developers. If the goal was clarity I’m not sure that going from Open to Opening, to name one case, really solves anything. If anything, I could argue that Preparing or PreparingToOpen is more appropriate for what it really means. To be sure, I’m arguing semantics but the semantics of an API are important.
The new events make it practically impossible to use R2 and still use older versions of Xojo. I’m already getting support questions on when are we going to support API 2.0 for ARGen and Shorts. The answer is I don’t know because it’s non-trivial to update their code bases to API 2.0 and still support API 1.0. I feel like I’m caught between a rock and a hard place and I know I’m not the only 3rd party Xojo developer caught in this bind.
I also think that’s part of my problem. I feel like Xojo has willfully ignored professional developers in favor of citizen developers. API 2.0 does nothing for me and with the way events were changed (it seems like change for the sake of change), it actually harms my business.
The upcoming Android platform does nothing for my business. Sure, it’s a shiny new target and I’d love to kick the tires on it, but iOS is still using the now deprecated Xojo framework. I know the goal is to have a single mobile project and have different build targets (like desktop does right now) but at this point I have no idea when that will happen. Based on what was reported at the MBS conference last week, there is still significant work to be done on Android yet. Then we still have to wait on an iOS update to get it to API 2.0. Could that even happen by the end of 2020? I’m not so sure. Maybe. But what gets put on hold during that time that I could use now?
Speaking of iOS it seems to be languishing on its own. It’s been out for years and to do some pretty common iOS tasks you have to go through declares. That’s not exactly a RAD environment. I’ve done a commercial project with iOS and it was great to use my favorite language, but I was literally 15 minutes away from giving up on Xojo iOS. It was only with some Herculean help from several forum members that I was able to get THE key feature to work at all.
Raspberry Pi is another target that’s been fun to play with. I did an electric kiln controller with it and again it took going back and forth on the forums for several weeks to finally nail down some of the problems. To be fair I had a bad thermocouple converter, but the fact that there were only a few people using it made it that much tougher. The Do It Yourself (DIY) and Maker movement is huge and yet Xojo is barely making a dent in it (I’m basing this on the lack of traffic in the Raspberry Pi sub forum).
What I could use today is Web 2.0. What I could use today is a desktop grid control, and a simple built-in Date picker. What I know others need today is built-in PDF export and viewing. It’s almost criminal how old the RegEx and XML libraries are. I’m sure we could list dozens of things we could use today rather than six to twelve months from now.
Xojo built its business on being a really good cross-platform environment. I still think it’s a really good desktop development tool – I could even argue it’s still the best cross-platform development tool out there. Adding half-baked targets with such a small development staff helps neither the targets nor the development staff because despite what the company line is (on being adequately staff), each target *does* take time away from other projects.
I feel abused at worst, or at least unappreciated by Xojo. I’ve devoted countless hours talking about the product, trying to get people excited about it, only to feel like I’ve been ignored by the company. If I write a good review of a release they quickly spread the news, but if I’m remotely critical of a release it’s only silence. Look for this one to not get promoted either.
Besides this blog, I only have one other way to get their attention – I can refuse to upgrade until they listen to what I *need* to run my business. If they don’t give me what I need I will look for alternatives and switch to that product. There are only a handful of Xojo old-timers around – and that should speak volumes. Xojo is a development tool that you want to love but it’s hard to be ignored and still love the product.
I took the time out of my schedule to reach out to Xojo this week to discuss the issues I have with API 2.0 and other topics. It was a fruitful, if somewhat disappointing, conversation with Geoff. Like Anthony from Graffiti Suite I am cautiously optimistic that some of the worst issues third party developers have with API 2.0 might be alleviated. Really we won’t know until we see their solution
One of the topics that I brought up was that these issues (the new Event names and marking anything from API 1.0 Deprecated – even though they’ll be around for a many years to come) were brought up early and often in the beta program. I said that honestly, it made us feel that our input is not valued. Geoff’s response is that the beta testers that brought these issues up is a small subset of the overall beta program and what they (Xojo) didn’t realize was those beta testers have other Xojo developers behind them (other Xojo developers) that aren’t in the beta program. They assumed that most of our users were using the most recent version of Xojo.
So, in other words, the biggest, most active users of their development tool, that are in the beta program because they want to be and need Xojo to work because of THEIR clients, their concerns could be ignored. It means the professional Xojo users aren’t considered a part of their target audience.
Wow. That is stunning to tell someone that has been in the beta program for (probably) over fifteen years that their input doesn’t matter. The three pro licenses that I’ve been purchasing year after year for over a dozen years doesn’t matter. The many years of blog posts promoting the product don’t matter. The thousands of hours of streaming video training about the product don’t matter.
I’ve been going to Xojo Developers Conference (XDC) for years. I’ve spoken at all of them since 2004. The conferences are expensive enough to attend that really it’s only the professional users that attend. There are some citizen developers that attend but mostly it is people that make a living off of using Xojo in some way. Maybe this is why XDC is now being marketed as Xojo.Connect? Targeted for citizen developers? I don’t know but it’s not any less expensive.
I asked Geoff if they’ve ever asked why long-term users stopped renewing. The answer was no. They did it years ago with people that signed up to download Xojo but never purchased. They couldn’t find a pattern which I totally get. Heck, I’ve downloaded and discarded dozens of development tools over the years just to kick their tires. But not knowing why someone stopped paying you $700 year after year? Seems like it would be an important thing to know.
I’ve been around a long time and have remained friends with some of those former Xojo developers. Some leave because of long-term bugs. It is disheartening to report a bug that affects your app that gets ignored for years on end. Granted not all bugs are equal but a show-stopper bug is just that. When your bug is ignored it’s pretty easy to check out.
Some leave because Xojo isn’t as RAD (Rapid Application Development) as it is billed as. Database driven applications (which I would say is what most businesses need) is pretty bad (hence why we’ve had our own library forever). Why use Xojo if it’s not RAD?
Some leave because there is a lack of capabilities in the product. iOS (but also true for all targets) is painfully lacking in capabilities that force you into learning complex declares. There are no built-in controls for Date, Time, Timestamp, or numbers only Text Fields, exporting to PDF, no ability for applications to have a report editor, a good grid, etc. Some of this is because Xojo is the lowest common denominator between Mac, Windows, and Linux (for desktop) and doing these things cross-platform is really hard.
Some leave because of the lack of options. Xojo has a tiny 3rd party add-on market. You only have a few options (if any) for some things or you make them yourself. Users hate reinventing the wheel. Xojo itself doesn’t do much to promote or help the 3rd party market. Other development tools have significantly more options to choose from.
Regardless, there are probably a ton of reasons why people leave. I suspect that most come down to some variation of the above. These are also the same reasons why new users will walk away too.
Citizen developers can walk away from Xojo with hardly a second thought. They’ve invested practically nothing in the tool. When you’ve been in the Xojo ecosystem for many years apparently we’re taken for granted because the cost of moving is so high. But who are the cheerleaders for the product? Who helps new users in the forums? The less active the community the harder it’s going to be to get those new citizen developer sales. I see this as a negative feedback loop.
I’ve been a Xojo consultant for over over sixteen years. I guess I’m not their target audience. Is anyone?
I took some time this week to really work with API 2.0. I took a generic ActiveRecord project and converted it to the new API. It wasn’t long before I found a showstopper bug with DateTime and Introspection (it has since been fixed in a beta). There were only a thousand or so “Deprecations with Replacement” message so that was just a few hours of work. Many were duplicates of the same bug (since I use a lot of arrays in ActiveRecord the Append method needs to change to AddRow). Fairly easy to change if not repetitious. No big deal, right?
Shorts, our reporting tool, has thousands of immediate ‘deprecations with replacements’ warnings. And then I got into things like Recordset turning into RowSets and string functions changing. After 5 hours of working on it I’m still at over 3,000 deprecation warnings. At this point I just don’t see the point of trying to convert Shorts. Obviously at some point I will have to but there is no immediate need to do so.
And that’s the problem with flagging all the old API warnings as Deprecations. It’s kind of silly because there is no immediate need to do so. It’s just an item marked as deprecated but will be around forever. So I think it’s silly to call them deprecated in the first place.
Another issue I have with the list is that it’s not grouped in any functional way. They appear in the list as they’re found by the compiler. In my ideal world I’d like to work with all the Dates I’m converting to DateTime all at the same time. Same with RecordSets to RowSets and so on. The Check Project just doesn’t help when it has thousands and thousands of warnings in random order.
Some changes you can use global search and replace. The caveat being that if you’ve added a similar method to your class you might kill your project accidentally (i.e. see Shorts above). The other thing that really makes life hard is string manipulation. In the old framework strings were 1-based. In API 2.0 they are 0-based so if you were using String.Inst and checking for zero you now are using String.IndexOf and checking negative one. There is simply no way you can do a global search and replace for that. The other one that’s been biting me is the use of Recordset.IDXField that was 1-based. The replacement is RowSet.ColumnAt is 0-based so that’s another thing you can’t just use global search and replace.
The 2019 R2 IDE added the ability to quickly create a #if block to separate pre-2019 R2 code with new API 2.0 code. That works well but for large projects that might be a lot of work. Too much work on any project of any reasonable size.
In API 2.0 there are a lot of replacement properties and methods. For the most part these are not a big deal. However they don’t always make sense. For example, the TextField and TextArea Text property have been changed to Value. How does that make using TextFields and TextAreas any ‘easier’ to understand? TextField1.Text = SomeVariable is perfectly understandable whereas TextField1.Value = SomeVariable is less understandable because now I need to know that I’m talking about a TextField or that SomeVariable is a string. If you are enforcing your control naming conventions and variable naming conventions it’s not so bad, but still this seems like an unnecessary change. It makes reading code LESS clear in my opinion.
Since the value type didn’t change (string in this case), I don’t see why this change happened. I guess one could argue that it makes it more consistent with things like CheckBox.Value but I’d argue that CheckBox.State is the better ‘value’ property since a Checkbox can have three states. Inconsistencies like that make API 2.0 harder to use in my opinion.
The new Event names in API 2.0 is a big deal. Nearly every control event has new event names. But then some like MouseMove, MouseDown, MouseUp didn’t change. Seriously, if you are going to change the event names for practically everything why not go all out and change everything? Which begs the question why were some changed and not others? I digress.
Some changes like Button.Action changing to Button.Pressed actually make some sense. There was actually confusion from new users on what event to implement. I can’t tell you how many times I saw a new Xojo user implement the MouseDown event because it looked more promising than Action.
But some new event names are just stupid. Timer.Action event is replaced with Timer.Run. WTF was this for? The Timer has one event and I could argue that “Run” is not an accurate description of what that event means. The timer isn’t ‘running’, it’s finished running. Maybe a more appropriate event name would have been “DoYourOneJobNow”. This begs the question I’ve been saying for years that why do I have to implement the timer event at all? Rarely have I ever used with without the event.
And sharing code between versions of Xojo is totally borked. Say, I have a class written with API 1.0 and I implement the Open event and then give it to you. You’re in 2019 R2, create a subclass of my control, and implement the Opening event (because that’s what you want to use because you don’t want those silly deprecation warnings). However, when you do this you’ve now kept my Open event from being called. Thus whatever I had in the Open event is no longer run. To me this is the most egregious bit about API 2.0. Me, as a 3rd party Xojo developer can’t control what you’ve implemented.
There are several solutions (probably more) to the events issue. First, the compiler, in 2019 R2 and above must produce an error if both the old and new events are implemented. It would require a compiler engineer to move up the chain and see if both old and new events are implemented in the object and then spit out a compiler error that is understandable. Who on staff could do this?
Another solution is to alias the events so that if someone implements the Opening event it automatically calls the Open event. One question that’s not answered yet is: Do we know if API 2.0 events fire in a different order than the old API 1.0 events?
Another solution that I’m pretty sure Xojo will not do is revert the events back to pre-API 2.0 status. This solves all of the backwards compatibility issues that the Xojo 3rd party developers have with API 2.0. We can deal with new methods using the #if XojoVersion technique but I don’t see how anything else is going to work and keep everyone happy. The new API 2.0 properties in pre R2 projects could be hard to deal with so I’m not sure the best way of dealing with those since any flags put in for R2 won’t work in pre-R2.
In general, I think API 2.0 is a hot mess. You don’t HAVE to upgrade your project to API 2.0 and I highly recommend that you do NOT for the foreseeable future. I have not migrated any existing clients to R2 and have told clients that do their own development to not upgrade as well. The API 2.0 saga is not finished by a long shot and it will take a while resolve itself (hopefully).
I’ve been doing consulting work for over sixteen years and a vast majority of it using Xojo. During my time with my own clients I’ve tried real hard to keep them happy because I’ve always known that happy customers come back. Finding new clients takes a lot of effort.
I know I’m not the least expensive Xojo consultant out there and I’m certainly not the most expensive either. Our billing rates reflect what we feel is a good value. If our rates are too high for a prospective client I’m okay with not getting their business because it’s not worth it to me to compromise on that (and I’ve pointed them to other developers that I believe could help them). Sometimes they come back later and sometimes they don’t.
The post I linked to talks about getting ‘Customers For Life’. I’m happy to say that we’ve had some of the same consulting clients for well over ten years. I try to make them feel appreciated and that we listen to their concerns. When things go wrong we try to make it right. Some clients have left and I hope they’re happy with the new developer they decided to use. But a lot of them stayed and that makes me very happy.
As the post said it’s not all that hard to keep a customer. All you have to show is that you have their best interests at heart. As Maya Angelou said, “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.”
How does this all relate to the general theme of my blog? Well, it’s no secret that I’ve been unhappy with Xojo recently. I’ve felt for many years that Xojo doesn’t court people like me (consultants and 3rd party developers) with much fervor. I’ve generally been okay with that because the product works well for what I do for my customers and if they’re happy I’m happy.
The whole fiasco with API 2.0 has left me feeling rung out and unappreciated. Many of the beta testers gave their opinion and concerns about API 2.0 very early in the R2 beta and those concerns were either ignored or dismissed. Those concerns have since been confirmed by the 3rd party developers.
If you had asked me a year ago would I be this mad at Xojo? I’d say, not a chance. After all I’ve been their customer for a long time. I’d hate to add up all the money I’ve paid them for licenses, consulting leads, and conferences over that period not to mention the number of blog posts, the many hours to create training videos, and in general promoting their product. Obviously helping them has helped my business. I’d like to think my work has helped them too.
So what happens when they lose a customer for life? We’re going to find out, I guess. I’m not going away any time soon since I’m not going to abandon my consulting clients but rather than renewing annually like I’ve done for many years I believe I’ll wait until I’m forced to upgrade for whatever reason, or they release a version I can use.
I’ll still blog about the product because that’s what I do and I’ll continue to update our Xojo products because we use them too (converting to API 2.0 is still up in the air for now). Will I start looking at alternatives to Xojo? Yes because they’ve made me feel like I’m unimportant to them. They don’t want customers for life they only seem to want new Xojo developers.
Finding an alternative to Xojo won’t be easy. Despite its warts it’s still a pretty unique product. There are lots of alternatives that don’t do something that Xojo already does, but the flip side is that there are products that do some things way better than Xojo.
Over the upcoming months I’ll start letting you know what I’ve been looking at and why. It might be illuminating and it might just end up being that I stick with Xojo because I just don’t find an alternative (I doubt this but it’s a possibility). I’m looking at the overall package from the IDE, to the language, to the 3rd party market, to the consulting market. It’s a big task.
Could Xojo win me back? Anything’s a possibility. Heck, I want to be excited about the product again. I need it to succeed for my clients to succeed. But for now, I’m satisfied with 2019 R1 and looking for alternatives.
In my search for Xojo alternatives I was pointed to Lazarus https://www.lazarus-ide.org which is a cross-platform IDE that uses a Delphi-compatible language (i.e. object Pascal). I was pretty happy to see that it has a Mac version of the IDE and I will freely admit that I prefer to work on MacOS for a variety of reasons. Among them is usually ease of installation and Lazarus completely fails on this count in my opinion.
Let’s start with installation. The Lazarus website takes you to a SourceForge repository that has three downloads. fpc is the compiler, command line tools and non-visual components. fpcsrc is the sources of fpc and its packages and you need that for code browsing. And then finally there is the lazarus IDE itself with visual components and help files.
First issue is that none of the Package files are code signed which means you automatically have to work around Apple’s security. Not hard but still it doesn’t give you warm fuzzies right off the bat. I forget which step made me do this but I had to upgrade to the latest version of Xcode and install the Xcode command line tools.
Then there was the issue that the Lazarus downloads doesn’t included a Mac version that will run on newer Mac systems. So you end up going to the Free Pascal Compiler repo on SourceForge to get it to install.
Finally, you get to the point where the Lazarus IDE installs and then you get to the configuration screen. As you can the FPC sources can’t be found. But wait, wasn’t that part of the big three downloads I did to begin with?
In the long run no amount of reinstalling or internet searching could solve this problem. There does happen to be an entry in the ComboBox at /usr/local/share/fpcsrc and when you use that option a dialog warning you “Without the proper FPC source code browsing and completion will be very limited.” But it lets you ignore it and actually open the IDE. For now we’ll ignore that the debugger doesn’t appear to exist either.
A blank project appears including a blank form (Form1). The component library window is spread across the top of the window with 15 tabs to break it up. In the Standard tab double click on the TLabel adds it to the form. From there you can drag the control to the location of your choice.
Things go very downhill from here. The label is selected and the eight handles appear and the mouse cursor changes when hovering over them. One would think that you can simply grab the handle to resize the control. Alas, I could not with the label even though I could with the other controls. I couldn’t even change its width from the properties list.
The properties list is pretty standard. All of the properties are listed in alphabetical order which I can live with but I definitely appreciate the grouping that Xojo does (although I still prefer the older Real Studio properties list to the Xojo Inspector). Logical groupings make life easier in a properties list.
A tab control on the properties list also shows the available events for the control. If you click on the right side of the event I immediately get an error “Error: include file not found ‘typshrdh.inc'”. Um…sure. Anyway, at this point I can’t do much more without getting these setup properly.
After spending a couple of hours over the course of three days I’ve given up. My Google-Foo is pretty strong but I keep getting nowhere. The directions I’ve found are pretty minimal and I’ve done what they say I should be doing to no avail.
All of this tells me several things. The lack of documentation, particularly for MacOS, tells me that that it’s not well maintained for MacOS and I don’t think it’s used by Mac developers very much. And this is long before I get into evaluating the language and libraries that are available for it.
For ease of installation and getting that first Hello World application up and running Xojo is by far the clear winner. Look, I don’t expect an open-source project to be as easy to setup as a commercial tool so perhaps it’s not a fair evaluation. But it is one of my criteria because I have clients that take over development of their projects after we do the initial work. So if I’m having these types of problems I can’t imagine a less skilled developer having any less.
If you’re using Lazarus on the Mac I’d love here from you. Drop me a line at support@bkeeney.com and perhaps we can get me past this hurdle so I can do a real evaluation of the tool.
Xojo 2019 Release 2.1 hit the web today. If you are using R2 and any of API 2.0 this dot release is a must for you. I almost would have almost preferred this release to be called R3. The biggest change in Release 2.1 is that the API 2.0 events have been dropped from API 2.0 entirely. There are also quite a few other changes and bug fixes that might impact your projects too.
Removal of the API 2.0 events was a concession to the 3rd party Xojo market (myself included). There really was just no tenable way for Xojo developers to support both the old and new events simultaneously and after much lobbying and teeth gnashing they were removed.
If you had implemented the new Events the R2.1 IDE will rename them back to the old events. This is a good feature, but I’m always leery of the IDE changing code on me without my knowledge. I recommend making a backup of your project before using this release.
Not everything is perfect with API 2.0 as it’s still hard to provide backwards compatibility with versions of Xojo prior to R2.1. All of the new API 2.0 Properties and class Methods are significantly different and permanently change your source code that is not compatible with pre-API 2.0 versions of Xojo. To help with this Xojo has added a new compatibility flag under the Gear icon in the Inspector that works with classes and properties. You can check if the Object, Method, or Property is API 1 or API 2 compatible.
Really, these flags should be titled XojoVersion < 2019.021 and XojoVersion >=2019.02.1 to make it more clear. But in reality this means that a Xojo developer must be using Xojo 2019 R2.1 or better to take advantage of these flags. To be honest I’m still unclear on how these flags really work and the documentation regarding them is sparse.
Another change is a new menu option called Analysis Warnings under the Project Menu. This dialog lets you pick and choose which warnings to see when you Analyze your project. If you set “Item X is deprecated. You should use Item Y instead,” to false you will no longer receive the API 2.0 deprecation warnings. This is set to false by default so you won’t receive the deprecation warning unless you go looking for it.
The FolderItem class has new methods: CreateFolder, CopyTo, MoveTo, and Open that now raise exceptions.
Window.Controls is now Iterable and you can use them in a For Each Loop to iterate through all controls on a window.
The DateTime class now has an optional parameter that lets you specify the TimeZone.
There are ton of bug fixes. Here are some of the highlights:
The IDE no longer crashes on macOS 10.15 (Catalina) when clicking on a color swatch in the Inspector and then navigating to another control before closing the color picker.
RemoveAllRows no longer crashes the application under certain circumstances.
The Database Editor no longer throws exceptions when dropping table columns.
They fixed a number of memory leaks. This includes (but probably not limited to) ODBCDatabase when binding parameters to prepared statements, MSSQLServerDatabase when using Prepared statements. When database objects go out of scope or are set to nil.
There are numerous examples of Deprecations with Replacement warnings now working properly with various classes. Constants have been replaced with more enums and so on. There’s just a boatload things working better with API 2.0.
In general if you are already using R2 then you MUST upgrade to R2.1. If you’re not using R2 then I still suggest waiting for at least another cycle since more bugs will be found and probably a few more things tweaked.
If you feel like you’ve wasted your time with R2 I feel your pain. The whole R2 cycle was really long yet API 2.0 was rushed through without much thought about the existing Xojo community and ecosystem despite attempts at communicating this information. I just don’t see the benefits of disrupting the entire user base, 3rd party ecosystem, not to mention 20 years of documentation, internet search engine results and so on, for what, in my opinion, are arbitrary and meaningless name changes. Some of the name changes make little sense but that’s a different argument that I’ve made before.
Personally, I would have appreciated the approach that they took with the URLConnection class that replaced HTTPSocket. It was a new class and you didn’t have to use it. It is using the new style exceptions rather than relying on error codes and it is a complete break from the old class. They did this with DateTime and RowSet and I’m fine with those. But having FolderItem (and other classes) now doing double duty depending on *how* you create them is a long-term support disaster.
So there you go Xojo coders. Xojo 2019 R2.1 is out and it’s better than R2 and has major changes that make our lives a little easier. What are your thoughts about Xojo 2019 R2.1?
[Edit] Apparently the Analysis Warnings dialog is NOT new. I’ve just never noticed it and, until now, I guess I’ve never needed to care.
In my quest to find a Xojo alternative I came across RAD Studio https://www.embarcadero.com/products/rad-studio that is owned by Embarcadero. RAD Studio can work with C++ or Delphi (object Pascal) and build for Windows 32 and 64-bit, MacOS 32 and 64-bit, Linux, Android, and iOS depending up on the license. They also have a Community Edition that can build for Windows, macOS, Android, and iOS but is free until company revenue reaches $5,000 or you get to 5 developers.
The RAD Studio IDE is Windows only even though it will allow live debugging into the other target environments. For my testing I was running the IDE using Parallels 15 in Coherence Mode running Windows 10 64-bit. The VM resides on an external SSD via Thunderbolt 2. I found the environment to be responsive despite being in the VM environment.
During installation it asks if you want C++ or Delphi for MacOS, Windows 32 bit Windows 64 bit, Linux, Android and iOS. I selected Win32 and MacOS. It took a good 15 minutes to install. You definitely need a large VM to do this. I ran out of space on my VM and had to start over again after clearing up some space.
To start testing, I created a New Multi-Device application. Doing a Hello World was simple enough. Double click on the on the label in the Palette, or drag and drop onto the form. Scroll down in the Object Inspector and change the Text property to “Hello World”.
At this point I’m ready to rock and hoping for the best. Pressing the Run button runs the app and voila a Windows app with a window saying “Hello World” pops up. Passes the first easy test. But what about getting the Mac version going?
To set up for the Mac (or iOS, Android, Linux or even another Windows computer) you’ll have to install the Platform Assistant Server (paserver for short). Paserver is a command-line application that you install on Windows, macOS, and Linux so that RAD Studio can connect and do its thing.
I had to read through the help file to figure out how to do this. PAServer20.0.pkg is located in C:\Program Files (x86)\Embarcadero\Studio\20.0\PAServer and you copy it to the Mac side to install it. The PAServer installer is using a code signing certificate that’s expired but it’s easy enough to work around. The installer puts two applications in your Applications folder: PAServer-20.0 and PAServerManager. But for now we’re only concerned with the PAServer-20.0 application. Go ahead and double-click to start it.
This opens the Terminal and the first thing it asks you for is a Connection Profile password. I set it to blank for ease of setup. It automatically opens port 64211 and a Mac security prompt immediately pops up asking if I want to allow incoming connections.
Going back into RAD Studio if I go to the project listing that shows my targets and I select Properties from macOS 64-bit I can setup my paserver now. Select which SDK to use (Mac 64-bit), then input the TCP address of the Mac. Test the connection and then select OK. A bunch of files get copied over to the Mac side.
Trying to debug run the application on the Mac side generates an error. Module not found: dccosx64260.dll After contacting the sales rep for help it appears that I had version 10.3 Update 2 and the fix for this problem was in Update 3. Maybe I just missed something in the myriad of menu’s but I never did find an “Update” in the application. I had to go to their website and search for updates and download an updater. The updater then proceeded to uninstall the previous version and then proceeded to give me the default settings (not what I’m looking for). It seems that the installer is pretty stupid. But it installs.
This is really where my review should end. After spending a number of hours trying to get this working I was unable to actually see a Mac app running. Despite updating the entire RAD Studio (twice) and update paserver I could never get any of the demo apps to run on the Mac. I know this works since I saw an Embarcardaro engineer do it. I’m sure it’s something I’ve done wrong but I figure if I can’t figure it out in a couple of days of messing with it then it’s not a trivial issue. It was very frustrating.
Initial thoughts on the IDE: This is a very typical 90’s looking MDI Windows application with one big overall window with various smaller windows inside of it. I find it to be very busy but not awful. I can live with it. I have to remind myself that I’m a spoiled Mac user and I expect ‘pretty’ and functional UI from every application.
The Projects list shows all of the available targets and seems pretty straightforward. This window disappeared on me once and the only way I found to get back to it once reopen the project. I’m sure there’s some menu command to get it back – I just couldn’t find it.
The Object Inspector is listed alphabetically and not grouped into functional groups. It has two tabs, Properties that shows the properties and Events which shows the available events. Double clicking on a control, like a Button, automatically drops you into the Code Editor and into the Action event. All code for a form or library is available as a complete text file rather than the way Xojo presents it to the user in a singular fashion (i.e. you get to see one method, property, or event at a time regardless of your coding skill level.
Here’s where things got really confusing for me. A multi-device project has one library (FMX) whereas a Windows-only project could use that one or one called VCL. Then there’s the choice of what language to use C++ versus Delphi. I was really confused on how to even figure out how to do a simple message box on the click event. I don’t see this as a huge problem as it’s common with learning any new framework so it’s just a matter of finding the right documentation and doing some reading. But it is a little concerning that I wasn’t able to find this readily. It was frustrating.
Code signing is built-in for all target types. For Mac deployment (assuming you can get it working) has built-in Notarization but it should be noted that you have to have a Mac and use paserver application to do code signing and notarization.
Another interesting thing is that you can have Windows, Mac, Linux targets all in one project file. That’s not too much different than Xojo but what’s also interesting is that you can have Android and iOS targets as well. The form editor gives you a simulation of what the UI looks like native to that platform. I’ll be honest, it’s not a great simulation but it’s enough for you to get the gist of how it will look. Of course, it’s convenient that you can reuse code amongst all of the targets in the same project.
During a demo with a sales rep and engineer I asked if the Mac controls were native. They said they were but I can say with 100% certainty that the standard tab control in RAD Studio is not using the standard Mac tab control (that looks like segmented buttons centered on the page). So I wonder about the veracity of this claim. I could never verify this as i was unable to get a Mac app running on my machine.
RAD Studio has considerably more built-in controls than Xojo. It really puts Xojo’s control library to shame. It has everything to get going without having to jump to the 3rd party market. However, when you do need something not provided (or that needs more features) there is a window to find them. Simply go to the Tools->GetIt Package Manager menu option and use the search field to find what you need. Additional filters allow you to see all, free, already purchased items and so on. Need a PDF viewer, reporting tool, or advanced grid? It’s in the list along with details about it and it has a convenient Install button right there.
RAD Studio is more expensive than Xojo but it does things that Xojo cannot currently do (Android for example). To create macOS, Windows, Android, and iOS applications it costs $2540 for the first year and that includes all major updates, hot fixes and ongoing maintenance of previous releases, and 3 developer support incidents. The Enterprise license allows you to do client/server databases, build for Linux, and build REST API applications for $4217.
In many ways, RAD Studio is what I wish Xojo was striving for. It has a definite “we’re serious” feel to it. The 3rd party integration is really nice. The documentation is very expansive and relatively easy to find things although as I noted above I had issues figuring out how to do a simple message box. It is nice to see that they have hot fixes available rather than having to wait for a major update.
For a company that touts its cross-platform development capabilities I find it kind of funny that they don’t have a Linux or Mac version of their IDE. If they did I think they’d learn a few things about making Mac applications in making their IDE truly cross-platform.
The fact that I’ve struggled to find answers to installation issues says that it’s not an easy language and IDE to learn. I suspect that having dual languages (C++ and Delphi) along with multiple UI libraries makes getting started much tougher than it needs to be. Getting the cross-platform applications working seems to be finicky and while I’m sure it works I threw my hands up in frustration.
Yes, I’m spoiled because the Xojo IDE (mostly) works the same on Mac, Windows, and Linux and compiles for the other platforms without needing to run a special app on the target platform (iOS requires a Mac but that’s an Apple restriction). While it’s true that there have been hiccups with API 2.0 the language is still undeniably Xojo and the Language Reference is decent with working code examples. Where Xojo is deficient is in default controls (like Date, Time, Calendar) and there is zero 3rd party controls/libraries discoverability in the Xojo IDE.
If you have a different experience with RAD Studio I’d love to hear from you. Are you doing macOS and iOS development with it? Did I do a fair review (keep in mind I’m coming from a Xojo)?
Xojo 2019 Release 3 hit the internet today. It’s only been three weeks since R2 was released and while this release has a number of bug fixes that are important this release is mostly about iOS.
R3 introduces a new ColorGroup class that will eventually come to all targets but for now it’s only available for iOS. The ColorGroup has its own editor and allows the developer to set or choose colors they want to use. You can choose Single, Dual, or Named colors. I’m not entirely sure the point of the Single color, but Dual allows you to change a single color based on Light or Dark mode, and then there is the Named option.
I feel that the Named option is the more valuable of the settings as it allows you to select what type of ‘color’ you’re using and allow to use, or modify the default colors in Light or Dark Mode. For example, if I simply wanted to use the default colors of an iOSLabel I can select the ColorGroup from a new popup in the Inspector. The control then will automatically use the Label color. But if I want to override the defaults I can do so here for both Light and Dark modes.
This has the promise to help Xojo developers that are supporting Light and Dark Modes in their applications. Since it’s currently for iOS only and I’m not actively working on an iOS project I can’t speak to its effectiveness and usefulness in coding. I feel that the ColorGroup editor was slow to respond to color picker changes. If you have some firsthand knowledge of the ColorGroup in action please leave a comment below.
The iOSTextArea control has a new Border Style and Border Color properties that allow you to create rectangle and rounded borders. SF Symbols can be retrieved by the iOS framework using the iOSImage.SystemImage shared method. The iOSRectangle now supports Blue effects.
After iOS there are number of new additions and changes that are part of the API 2.0 work. If you are interested please read the release notes. I am not actively using API 2.0 in any projects so these changes don’t mean anything to me yet.
Some Windows bug fixes: The Draw Caution/Note/Stop icons are updated to the newer look for Windows Vista and later. The app now terminates when the system sends a shutdown message (like when an installer is trying to update the app). The GroupBox no longer draws funny when the caption font size is different than the default.
Some Linux bug fixes: Changing the Label Text Color no longer leaks memory. Clipping the listbox graphics in the CelLTextPaint or CellBackgroundPaint now works as expected.
With iOS Dark Mode out of the way, hopefully this means that 2020 R1 will have the long awaited Web 2.0. My gut feeling is that Web 2.0 won’t be released until Xojo.Connect at the end of March and even then it might be only in beta form. Web 2.0 is a complete rewrite from the ground up that’s been underway for a while. Maybe I’m wrong but experience says they’ll want something big and flashy to show off. Of course I also expect more from Android but I still expect that to be in alpha and nowhere near ready for release.
R3 is mainly an iOS release for Dark Mode and some changes for API 2.0 and then mostly bug fixes. As always, before using you should read the release notes and then thoroughly test your application before issuing any releases.
I’ve been on the search, recently, for alternatives to Xojo. I’ve done some basic research into Lazarus and RAD Studio and both came up short in a variety of ways that you can read about in past posts. So what am I looking for in cross-platform development tool? I’ll spend the rest of this post talking about some of my requirements.
Desktop Targets
Most of our consulting work is macOS and Windows with the occasional Linux or Raspberry Pi project thrown in for good measure. Whatever development tool I choose it needs to be able to build for Mac and Windows at a minimum and anything it can do with Linux is an added bonus. Rarely do we get a project that is just Windows or just MacOS. Being able to desktop and consoles apps is a must on each target platforms.
Native Controls
Maybe it’s my Mac background but I’d like my controls to be as native as possible. This means that when Apple, Microsoft, or Linux distribution changes their UI (again) the application will just work without requiring an update from the vendor. I’ll be honest that this is a want-to-have option as even Xojo isn’t completely 100% native (Listbox I’m looking at you). Accessibility is a big concern for some clients so I’m willing to forego native if it’s ‘close enough’ and works.
Mac IDE
I’m a Mac user so I’d like to stick to my platform of choice if I can. This means that the IDE must have the features that I come to expect on the Mac (keyboard shortcuts, standard Mac text editor features, Finder integration, and so on). Can I live with working in Windows? Sure, but remember I’m searching for unicorns so it’s not my first choice. Plus, having a Mac IDE is a good indication how good of a cross-platform development tool it is. I find it laughable, really, that some companies create cross-platform applications but yet don’t have a Mac IDE. Um…so do you *really* do Mac applications or is this a marketing checkbox?
RAD Environment
I’ve been doing Rapid Application Development using Xojo for nearly 20 years and while you could argue that parts of Xojo are not very RAD (database development I’m looking at you) it is very easy and simple to get simple applications developed in practically no time. Just last week I was able to get a simple Mac/Win desktop application developed for a client in four hours and that included preferences, full menubar, a simple text editor, talking to a web API, all with code signing, notarization, and installers. Some of that is experience and the kit that I’ve developed over twenty years but some of that is simply Xojo. Xojo makes it easy to create a MenuBar and quickly create menu handlers at either the application or window level. The integrated Layout Editor makes it easy to add events for the window and controls and automatically drops into the integrated Code Editor. I really want the next development tool I choose to be as easy to use as Xojo so I can get work done quickly and efficiently.
As a bonus I’d like my IDE to have integrated git and/or subversion integration. I’d also like built-in code signing and notarization if possible too. I realize this last part might require some remote magic since only a Mac can code sign and notarize Mac applications. Neither of these options are available in Xojo at this point and require command like voodoo or a third party utility.
Double-Clickable, Compiled Executables
I really need my apps to be double-clickable in the Finder and Windows Explorer and just run. I should never have to start up an application with the command line nor should I have to have a runtime installed to run the application. Xojo applications are packaged to run independently and on the Mac they are in a bundle and even in Windows and Linux they are self-contained builds not requiring anything special from the operating system (as in no runtime necessary).
Community Size and Friendliness
I’d like my new development community to large and friendly. When I have those inevitable questions regarding my new language and IDE I want a lot of options and where the community isn’t full of jerks. For all of its issues this is where Xojo really shines because it’s one of the most helpful and friendliest communities I’ve ever been part of. I’ve seen the vitriol spewed in other communities when newbies ask a question that should probably be obvious. Hey, mistakes happen, and what’s obvious to one person may not be obvious to another.
Consulting Community
I’ve spent the last two decades as a consultant so why would I stop now? Whatever community I go to I’d like there to be a decent consulting community where an up and coming developer could make a name for themselves. I have no problem becoming ‘certified’ (whatever that means) to get listed and to get prospective clients.
Large 3rd Party Ecosystem
One complaint I’ve had about Xojo over the years is the lack of 3rd party options for controls and libraries. If you want reporting options, a better grid, PDF creation and viewing, database ORM options, and a whole host of other controls and libraries your options are extremely limited. My new development tool should have a vibrant 3rd party community so I don’t have to reinvent the wheel in many projects. I’m okay paying money for a quality controls and libraries but what I really want are options because each one is different.
Good Documentation and Examples
This seems pretty self explanatory. The documentation should be sufficient to learn the language. In an ideal world it would be fully fleshed out so you can get a feel for the gotchas. As far as examples go they should just work without having to futz around fixing stuff.
Bonus Things
It can do web apps.
It can do iOS and Android mobile apps (with some of the same caveats above).
The company/community behind it has a roadmap and what they want the language and IDE to be in the long run.
A standards organization behind the language.
A large enough company behind it, or a large enough community, to ensure future new features and timely bug fixes.
The things that I’m NOT concerned (much) about
Pricing – if it works then the price is (almost) irrelevant.
Licensing – if the language, IDE, and controls and libraries let me create commercial applications then I don’t care if it’s an MIT, GPL, LGPL, or Commercial license.
So that’s my unicorn list. If Xojo is not going to be my long-term development tool these are the things I’m looking for. Is this an impossible list? I don’t think so but as someone coming FROM Xojo these are the things I’m looking for. I you have some suggestions, I’d like to hear them and please let me know what the tool does NOT have from my list above. I know it’s highly subjective but I think it’s important to acknowledge the limitations of the language and tool you work with every day. Like Xojo, no development tool is perfect.
Last week we asked the question “How Did You Find Xojo?” A vast majority (60%) of the responses said web search of some kind was how they found out about Xojo (or REALbasic or Real Studio). Some found Xojo via software discovery CD’s that were bundled with Mac specific magazines over a decade ago (that seems wrong to write it like that).
More than a few users had comments that they had been using Visual Basic (VB) and wanted something like it for the Mac. Some even said that they searched for “VB for the Mac” and Xojo was one of the results.
I get it. I spent quite a few years working on a big accounting application written in VB6. It was big enough where we had to refactor the project because we couldn’t add any more modules or class objects to it. It used many third party controls that helped in development (think text field formatting, fancy grids that could hold any other control, and multiple reporting tools).
The project was only ever going to be on Windows so there was zero thought about a Mac version. But that didn’t stop me from thinking about it. Every now and then I’d try to do something in Xojo to prove that I could do it. With the exception of the fancy grid there were few things I couldn’t get working in Xojo.
Even though VB6 and Xojo are BASIC languages there isn’t much similarity between them. VB6 compiled applications that required the VB6 runtime while Xojo applications are compiled into self-contained packages. On the Mac everything required by the application is in the bundle whereas on Windows and Linux libraries needed by the app are put into a folder right next to the executable. Xojo Windows apps don’t need to use an installer but since Windows users expect an installer it’s easy enough to use.
VB6 is over fifteen years old. It didn’t have much in the way of modern language features such as object inheritance. You spent a lot of time and effort manipulating controls to do what we’d consider ‘normal’ things (I seem to remember ListBoxes being this way). In Xojo you can extend and subclass practically everything. Is Xojo a perfect language? Oh heck no, but it’s light years ahead of the fifteen year old VB6 and it’s still evolving and improving.
Xojo doesn’t make perfect Windows, Mac, or Linux applications. It’s often a compromise for something that works ‘well enough’ on Mac, Windows, and Linux applications. So the fancy grid’s that you could purchase for VB6 don’t really exist for Mac and Linux and Xojo reflects that. But you can certainly design a really good application that doesn’t need the fancy grids. MacOS users tend to like ‘elegant’ solutions and, to be honest, the fancy grids aren’t an elegant solution but they certainly work (especially for accounting applications).
The third party community for Xojo isn’t nearly as big as the VB6 world. Generally there are fewer options but the options are considerably less expensive. We’d spend a couple of grand each year per developer on licensing for third party tools. As a Xojo consultant we spend about that much for the entire staff each year.
We don’t get many requests for VB6 to Xojo conversions any more. We used to get ten to twelve a year but it has definitely slowed down the past couple of years. I suspect that any remaining VB6 applications are in maintenance mode and their owners don’t want to invest in a rewrite. If they did, they would have already moved to a new development environment.
VB6 applications still work in Windows 10 and if memory serves Microsoft has said they’ll support the VB6 runtime for another ten years. This means that there must be a LOT of VB6 applications still around. Support for the VB6 IDE has disappeared and the last time I tried I couldn’t get it to install properly in Windows 10 so I just went back to my Windows 7 VM. But now that Windows 7 support has expired it seems that those old VB6 applications might be on life support.
Many of us came in to the community looking for VB for the Mac. We’ve been using it for nearly 20 years and have a stable of clients that are happy with a single code base for their commercial Mac and Windows (and occasionally Linux) applications. I’d say Xojo has been more than good enough.
Now that API 2.0 is more or less been through two releases (2019 R2.1 and 2019 R3) many Xojo developers are starting to poke around with API 2.0 in their database applications. There are many things to like about the changes to the database classes and our own ActiveRecord class does many of these things. Things like throwing exceptions when there are errors definitely get your attention whereas in API 1.0 unless you check for the error you may not know anything bad happened. The built-in Prepared Statements are a super nice change too.
Despite all the good things with the db classes in API 2.0 I recommend holding off until one, very important bug, is fixed. Feedback case 58739 is such a huge risk that you simply cannot use the new API 2.0 classes in your Xojo projects yet.
The essential detail of that case is that Xojo is not releasing objects as it should. Norman did a test case and showed that when using API 1.0 his test project had 24 objects at the end of the test run. Doing the same thing in API 2.0 had over 43 million still unreleased objects! This means there is a huge use of memory in the application and in 32-bit applications it will simply crash once it consumes 4 GB of RAM. 64-bit applications will last longer but still bring your computer to its proverbial knees.
The Feedback case talks about SQLite and in-memory databases but other reports are that it’s in other databases as well including ODBC and MS SQL Server (case 57978). The good news is that 58739 is marked as fixed as of January 7th, 2020 (57978 has not been updated). But unless Xojo issues a point release to 2019 R3 we won’t see this fix until 2020 R1 is released and there is zero evidence of that happening any time soon.
Several people have contacted us about an updated ARGen that generates API 2.0 code. We are holding off until we feel API 2.0 is rock solid. So until this is fixed we are not using or advocating for API 2.0.
Have you found anything else in API 2.0 that should discourage Xojo developers from using it?
Xojo announced today the creation of the Most Valuable Professionals (MVPs) advisory board. More information here: https://www.xojo.com/mvp/
Having ‘known’ these five Xojo developers for many years (mostly online and a few in person) I think they are an excellent group to advise Xojo. Most of these developers have many years of Xojo experience ranging from being 3rd party control and library developers to consultants to commercial application developers.
It makes me happy that every single one of the developers on the Advisory Board is what I would call part of the ‘professional’ developers of Xojo. It is surprising, however, that there are no ‘citizen’ developers on the board. So I call this a mixed signal to who Xojo is trying to appeal to (obviously it’s everybody but I think you get my point).
The Association of REALbasic Professionals (ARBP) tried to do this ten years ago with no success. The groups mission was to help inform Xojo (then Real Software) on what the professionals wanted out of the tool. If I recall correctly the only thing that was ever implemented out of our top 5 list was reporting. Grids, PDF support, and more basic controls never materialized. Sadly, we all still want those options.
It’s not being said but I believe the MVPs Advisory Board is a direct response to the virulently negative (and vocal) reaction by some Xojo developers had with the rollout of API 2.0. I am one of those developers and it is no big surprise that I was not invited to be on this board and, if I’m being honest, I’m not sure I would have accepted anyway.
We don’t know how the advisory board works, or even if it will significantly change how Xojo approaches future changes. Even if they do have significant input I’m not sure we’d know unless Xojo specifically tells us.
Good luck to this group and Xojo: There are some relationships to mend.
