Ignoring Encoding

When working with Strings that come from (or are sent) outside your app, you always need to consider the encoding of the text. These days, UTF8 is the most common encoding for text and probably the one you should use most of the time. But if you’re getting text from a database or a web service or just another file that you don’t control, then you’ll want to use the DefineEncoding method to set the correct encoding of the incoming text or use ConvertEncoding to cover the encoding to something you’d rather be using, such as UTF8.

Kem Tekinay is doing a session on called Decoding Text Encodings at XDC 2019 that you won’t want to miss.

Avoiding Exception Handling

Some classes raise exceptions when something unexpected happens. If your code ignores these exceptions then this causes your app to display an error message to the user which forces them to quit the app. That’s not the best experience.

At the very least you should have some code in the App.UnhandledException event for your desktop/web/iOS app so that you will know when these occur. The code do something as simple as log the error to the system log or a file so that you’ll have it to investigate.

Then you can pinpoint the part of the code where it occurred and add the appropriate Try…Catch code to deal with it appropriately and gracefully.

As an example, if you call XMLDocument.LoadXML and supply invalid XML, then an XMLException is raised. By catching this exception you can display a message to the user telling them the XML file they selected is invalid and asking them to choose another.

Skipping Database Error Checking

Whenever you run a database command it is possible that there was a database error that happened. But you won’t know about it unless you check the if Database.Error is True. Always do this and then display or log the Database.ErrorCode and Database.ErrorMessage.

This can really help with catching subtle problems, such as a typo in a SELECT statement.

Ignoring Memory Leaks

A memory leak in your app is when it keeps reserving memory but never gives it back. Oftentimes this is not noticeable as the increased memory usage is minimal and does not typically affect 64-bit apps. In addition the memory is released when your app quits. But if you have a significant memory leak you should look into figuring out how to eliminate it.

You can determine if your app has a memory leak by checking (using the OS Task Manager or Activity Monitor) if its memory usage increases significantly as the app is used even while you are closing windows or documents that are no longer used.

It is possible you have some objects that are never going Nil and thus not releasing their memory. Normally you don’t have to worry about setting objects to Nil manually as Xojo uses automatic reference counting (ARC) to clean up memory. But there is a situation, called a circular reference, that can lead to objects not being set to Nil.

A circular reference means that ObjectA refers to ObjectB and ObjectB refers to ObjectA. Since neither ever has its reference count get to zero, then they cannot be released from memory.

You can either manually set things to Nil to ensure that memory is released or you can make use of the WeakRef class to help manage it.

Fuzzy Graphics in HiDPI

If you used pictures in older projects then they’ll only have a single size. When you enabled HiDPI for your project (Shared Build Settings -> Supports HiDPI) then this picture is treated as a 1x size and is scaled in HiDPI screens. This can result in a fuzzy or blurry picture.

Instead you want to start using Image Sets. When you create an Image Set you have three “slots” for 1x, 2x and 3x image sizes. Supplying at least 1x and 2x images will limit unnecessary scaling and cause your images to appear much sharper and clearer. Image Sets are created by default in current versions of Xojo when you add a picture or image to your project. Right click on existing pictures in the project and choose “Convert to Image” to convert them to an image so you can add additional sizes.

Not Updating to 64-bit

For macOS, you should definitely be updating your projects so they build 64-bit apps. It’s likely that the version of macOS that is released later this year will no longer support 32-bit apps at all and you’ll want to be prepared. For many projects you just have to change the Build Architecture setting for the OS from “x86 32-bit” to “x86 64-bit”. Some projects may require updates to Declares that call OS libraries to ensure they can call the 64-bit version of the library.

It’s less of a rush on Windows as 64-bit versions of Windows still fully support 32-bit apps. However, on a 64-bit version of Windows, which are becoming increasingly common, you will get better overall performance as the OS does not have to load 32-bit compatibility layers which use up memory and CPU.

On Linux, 64-bit distributions are becoming more and more common and many do not include any built-in support for 32-bit apps. So you’ll want to be able to distribute a 64-bit app if at all possible.

Not Checking the Docs

We are working to consolidate all the documentation into one place and that place is: https://documentation.xojo.com

As part of this process, the docs have been cleaned up, updated and we’ve improved the categorization to make it easier to find things. This is an ongoing process, of course. But sometimes it will be faster to look up something in the docs than it is to post a question in the forum and wait for replies.

I hope you find some of these tips helpful. At XDC 2019, I’ll be covering additional tips in my two sessions: Avoid Troubleshooting Troubles: Effective Debugging Techniques and Virtuous Code Optimization.