Xojo 2019 R2: API 2.0 is Here

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?

Edit: Fixed some typo’s.

Notarizing Your Xojo Apps

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.

xcrun iTMSTransporter -m provider -u <AppleID>  -p <ApplicationSpecificPassword> 

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?

MarkdownKit Review

Markdown is a popular text formatting syntax in use all over the web. Markdown was designed to be human readable in plain text, and formatting parsers are available for many different formats.

There are a few different parsers for Xojo, available in both add-on and plugin format. Garry Pettet provided MarkdownKit for us to look at and review. MarkdownKit is written entirely in Xojo code, is fully CommonMark compliant, and generates HTML.

MarkdownKit is implemented with both String and Text versions, and is designed for both Desktop and iOS projects. MarkdownKit is provided as full source code, and includes documentation as well as examples.

With everything provided, MarkdownKit is very easy to use. It really is as simple as one line. dim sHTML as String = MarkdownKit.ToHTML(SomeMarkdownString) The output can then be passed into an HTMLViewer and displayed. This can all be done so fast you get near live rendering.

The way MarkdownKit renders the input is impressive. A MarkdownKit document is parsed into a syntax tree so that an implementation of the rendering interface can walk the document. What we get from all that is a fast and accurate Markdown renderer. And wow is it fast. The demo application really illustrates the speed of MarkdownKit.

Overall MarkdownKit has proven to be speedy, well documented, easy to use, expandable, and CommonMark compliant. MarkdownKit is a great Markdown renderer written entirely in Xojo code. If you don’t yet have a Markdown renderer in your toolkit, MarkdownKit is a solid option.

More information about MarkdownKit, pricing, and the demo downloads are available at the MarkdownKit Webpage: https://garrypettet.com/xojo-addons/markdownkit

Test Data

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?

Happy Coding!

Exception Handling

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.

If you want to play around with this example, please download it from https://www.dropbox.com/s/3uxyqvjf4wvjrpg/Exception%20Handler%201.0.zip?dl=0.  Feel free to use in your own code however it is provided as-is with no warranty.  We cannot provide support.

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?

BKeeney Celebrates Bikini Day!

Happy fourth! Happy fifth! Happy holidays! July 5th is National BKeeney… er Bikini Day. We like to celebrate the holiday with a discount on our products! Save 20% with the coupon BKINI-DAY

Use these handy links to apply the discount automatically:

ARGen – Create ActiveRecord classes and UI for database driven applications made fast.

BKS Shorts – Create and render reports in your Xojo Desktop and Web applications. Renders to screen, printer, HTML, CSV, and PDF formats.

BKS Tab Control – A classic “tabs control” for Xojo Desktop applications.

BKS WebSplitter – Splitter Control for Xojo Web Apps

Formatted Text Control – A TextArea replacement that allows inline pictures, hyperlinks, and much more.

Task Timer 6 – If you aren’t tracking your time you’re missing out on a key metric on how well you estimate and where you spend more of your time.

Xojo Trainer (Download Only) – Learn Xojo (offline) from Xojo professionals with over 15 years of Xojo development experience.

Don’t Overuse Variants

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.

Enterprise Code Signing for iOS in Xojo

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.
  • Download iReSign project from https://github.com/maciekish/iReSign (see note below)
  • Run the ReSign app
  • 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”

Don’t Use GoTo

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.

Don’t use GoTo – ever.  GoTo is a holdover from the old BASIC days where code was unstructured and you needed to manage flow-of-control.  Old BASIC programs used a ton of GoTo statements because, well, you just had to.  It was the only way to get anything done.  Xojo uses a modern BASIC syntax but it’s fully object-oriented code and still has GoTo as a reserved keyword and it still functions.

Xojo has many ways of doing flow control.  There are multiple ways of doing loops with While’s, Do-Loop’s, For-Next’s, and we control those loops with keywords such as Continue, Exit, Return.  Since we have methods and functions too we can exit those by calling Return at any point in the method and the code resumes execution at that point.  GoTo just isn’t needed any more.

And yet GoTo still exists.  I recently ran across this code in a project we’re updating for a client.

As you can see we are in a fairly typical For-Next loop iterating through a ListBox.  The first line into the loop we check if we’re closing the window and if we are we call GoTo bale which takes us to where bail: is.  Bail is at the bottom of the method and we’re doing nothing afterwards (the last two lines are Exception handling in this method and aren’t called).

This is such a poor example of Xojo coding.  We can use Exit to accomplish the same thing since Exit will immediately exit the loop and since there would be nothing after the loop it would simply leave the method entirely by simply calling Return.  There’s no penalty for using either Exit or Return.

Honestly, I have no idea why the original developer did this.  I think they came from VB6 where code like this was pretty common, but even in that language there were much better ways to do the same thing.  So I will call this lazy coding because the developer didn’t use the best way in Xojo.

Using GoTo like this is potentially risky too.  Feedback case 24710 shows that using GoTo may cause a memory leak because the compiler may skip cleanup code.  I think the above code is safe but I could see if we loaded oNote before the GoTo exiting the loop it would be dangerous.  But even still, if GoTo is outdated, not recommend, and dangerous on top of all that why use it?  I can think of at least three ways to make this code safer and better.

At the end of the day, If you’re using GoTo – don’t.  Refactor your code so it makes use of the modern Xojo calls. It’s safer and the right way to code in Xojo.  Your future self will thank you.

(243)