Specifically, the following properties can be used there:

• Graphics.FontName
• Graphics.FontSize
• Graphics.FontAscent

These properties are known from other Xojo targets (e.g. Desktop), but are not part of the official mobile API and are not shown in Autocomplete. They cannot be used outside of this event.

In contrast, the mobile API property Graphics.Font cannot be used within the DrawControlInLayoutEditor event. The usage is strictly limited to the DrawControlInLayoutEditor event. Using these properties in runtime code will result in errors.

These properties allow for more accurate text rendering in the layout editor, for example in custom controls where font metrics need to be considered.

Although these properties are not part of the mobile API, they can be used selectively within the layout editor context.

This code will work fine in your mobile control’s DrawControlInLayoutEditor event:

Var s As String = "Happy coding!"
Var x As Double = g.Width / 2 - g.TextWidth(s) / 2
Var y As Double = g.Height / 2 - g.TextHeight / 2 + g.FontAscent

g.DrawingColor = Color.Red
g.DrawOval(0, 0, g.Width, g.Height)

g.DrawingColor = TextColor
g.Bold = True
g.FontName = "Times New Roman"
g.FontSize = 16
g.DrawText(s, x, y)

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In total, more than 60 new declares have been added for MobileSlider, allowing you to control virtually every UI parameter of the control—whether it’s the shape of the thumb, its color, the track colors (both for the active/left and inactive/right portions), and much more. You can also set the step size, similar to what you’re used to on the desktop.

Just take a look at the updated Android Design Extensions demo app and try it out.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library. I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

First, I’m going to create a headless desktop application. A console application would work, but shows a command box.

In the Xojo IDE, create a new desktop project and delete Window1 and MainMenuBar. Then add the Opening Event Handler to App and add this code:

Self.AllowAutoQuit = True

This will allow the application to quit when done.

Add the DocumentOpened Event Handler to App and add this code:

If item _ ' Using item
 .NativePath _ ' property NativePath
 .NthField(":", 1) <> "AlertDemo" Then ' Compare the value left of the ":"
 Return ' If invalid return (quit)
End If
Var alert As String ' Define the variable
alert = item _ ' Using Item
 .NativePath _ ' property NativePath
 .NthField(":", 2) ' Extract the contents to the right of the ":"

alert = DecodeURLComponent(alert) ' Convert the content to plain text
MessageBox(alert) ' Show the alert
' The app will now quit

To test you can select Shared in Build Settings.

And enter a value into Command Line Arguments:

Running the app in debug mode will show:

Now build the project and create an installer using Inno Setup.

[Setup]
AppId={{B4D9ABDA-9F58-4FE0-A5F3-3E39C28EAB59}
AppName=Alert Demo
AppVersion=1.0
DefaultDirName={commonpf64}\Axis Direct Ltd\Alert Demo
DefaultGroupName=Axis Direct
OutputDir=C:\Xojo Projects\Alert Demo\Installer
OutputBaseFilename=AlertDemoInstaller
Compression=lzma
SolidCompression=yes
ChangesEnvironment=yes
[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"
[Tasks]
[Dirs]
Name: "{app}\Alert Demo Libs"
[Files]
Source: "C:\Xojo Projects\Alert Demo\Project\Builds - Alert
Demo\Windows 64 bit\Alert Demo*"; DestDir: "{app}"; Flags:
ignoreversion
Source: "C:\Xojo Projects\Alert Demo\Project\Builds - Alert
Demo\Windows 64 bit\Alert Demo\Alert Demo Libs*"; DestDir:
"{app}\Alert Demo Libs"; Flags: ignoreversion
[Icons]
[Run]
[Registry]
Root: HKCR; Subkey: "AlertDemo"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo"; ValueType: "String";
ValueData: "URL:AlertDemo Protocol"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo"; ValueName: "URL Protocol";
ValueType: "String"; ValueData: ""; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open"; Flags:
uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open\command"; Flags:
uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open\command";
ValueType: String; ValueData: "{app}\Alert Demo.exe %1";
Flags: uninsdeletekey

The registry section creates the registry entries per William’s blog post.

Now that the application Is installed, we’ll look at the Web Application. For the sake of testing, I’m just adding a Button to a WebPage and adding the following code into the pressed event.

Var s As String = "Hello World"
Var Alert As String
Alert = EncodeURLComponent(s) ' Make the string URL safe
GoToURL("AlertDemo:" + Alert, True) ' Launch the app in a new tab

And that is it!

For printing a docket, I would pass a unique identifier for the transaction using this method then access the data using URLConnection & HandleURL.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What Is Conditional Compilation?

Conditional compilation allows you to include or completely exclude sections of code from the final application based on a condition. Unlike an If statement at runtime, this decision is made at compile time. Code excluded through conditional compilation simply does not exist in the compiled application.

#If False – Completely Excluding Code

#If False
  MessageBox("This line will never be compiled")
  Var result As Integer = DoSomething()
#EndIf

When the condition is False, the entire block is ignored by the compiler. It is not compiled, not included in the application, and not even checked for syntax errors. The code is effectively invisible to the compiler.

Why Not Just Comment It Out?

At first glance, #If False seems to do the same thing as a comment. But there are key differences:

1. Nested Comments Are No Problem

If a code block already contains comments, commenting out the entire block quickly becomes messy:

' Var x As Integer = 42 ' Default value
' Var y As Integer = x * 2 ' double it
' ' This is already a comment

With #If False, everything stays clean:

#If False
  Var x As Integer = 42 ' Default value
  Var y As Integer = x * 2 ' double it
  ' This is already a comment
#EndIf

2. Incomplete or Broken Code

Sometimes you want to keep an unfinished code draft without it preventing the build. Since the compiler completely skips the contents of an #If False block, the code inside may even contain syntax errors:

#If False
  ' Experimental approach – not finished yet
  Var data As  = LoadFromServer(
  ProcessResult(data
#EndIf

This code would be useless as a comment because you’d have to comment out each line individually. With #If False, it’s safely stored away.

3. Quickly Disabling Large Code Blocks

For larger sections, #If False / #EndIf is far more practical than prefixing every line with '. Plus, the block can be reactivated instantly by simply changing False to True.

#If True – Always Including Code

#If True
  MessageBox("This line will always be compiled")
#EndIf

An #If True block is always compiled — it behaves identically to regular code. This might sound useless at first, but it does have practical applications.

When Is #If True Useful?

1. Quick Toggling During Development

Imagine you’re working on a feature and want to quickly enable or disable certain code sections:

#If True ' <- Set to False to disable the new feature
  ' New feature
  Var service As New CloudSyncService
  service.SyncNow()
#EndIf

By simply changing True to False, you can disable the feature without deleting or commenting out any code.

2. Placeholder for Future Conditions

Sometimes you already know that a code section will later be tied to a condition — such as a platform or build type. With #If True, you can prepare the structure in advance:

#If True ' TODO: Change to TargetMacOS once Windows alternative is ready
  Var folderPath As String = SpecialFolder.Applications.NativePath
#EndIf

3. Visual Code Grouping

In longer methods, #If True can serve as a visual structural block to highlight related code:

#If True ' --- Initialization ---
  Var db As New SQLiteDatabase
  db.DatabaseFile = dbFile
  db.Connect
#EndIf

#If True ' --- Load data ---
  Var rs As RowSet = db.SelectSQL("SELECT * FROM users")
#EndIf

Defining Custom Compiler Constants

Xojo also allows you to define your own constants for conditional compilation.

#If kEnableLogging
  WriteToLog("Application started")
#EndIf

This lets you control features or debug functionality centrally through a constant without having to modify the code itself.

Best Practices

1. #If False instead of mass comments: For larger code blocks that need to be temporarily disabled, #If False is the cleaner solution.
2. Add a comment: Always document why a block is disabled:

#If False ' Disabled until bug #1234 is fixed
  ProcessCriticalData()
 #EndIf

3. Don’t use permanently: #If False blocks should not remain in the code indefinitely. If the code is no longer needed, remove it. If it is needed, activate it.
4. Prefer platform directives: When dealing with platform-specific code, use the specific constants (TargetMacOS, TargetWindows, etc.) instead of #If True or #If False.
5. Avoid deep nesting: While nested #If blocks are possible, use them sparingly as they quickly reduce readability.

Conclusion

#If False and #If True are simple yet powerful tools for everyday Xojo development. They offer a cleaner alternative to commenting out large code blocks, enable quick feature toggling during development, and lay the groundwork for a structured, cross-platform codebase. Used thoughtfully, they save time and help you stay organized — even in larger projects.

If you want to automatically convert a selection into a #If/#EndIf block, you can do so via the context menu: “Wrap In > #If / #EndIf”

Happy coding.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

I wanted something better. Not a generic chatbot that happens to know some Xojo, but a tool that could actually see what I was working on. That’s why I built Zotto (with Xojo!).

What Is Zotto?

Zotto is a cross-platform macOS and Windows app that acts as an AI pair programmer specifically for Xojo developers. It connects directly to the Xojo IDE, reads the project you’re working on, and gives the AI real context about your code such as classes, method signatures, properties. Essentially the whole project’s structure.

The Problem It Solves

The core issue with using general-purpose AI tools for Xojo development is context. When you ask Claude or ChatGPT a question about your project, the AI has no idea what your codebase looks like. You become the middleman, manually feeding it snippets and hoping it has enough information to give useful advice.

Zotto removes some of that friction. When connected to the IDE, the AI can explore your project on its own using built-in tools:

• ProjectOverview gives it the high-level folder structure
• ListItems lets it drill into specific folders
• GetSignatures shows method and property signatures without dumping all the code
• ReadCode pulls up full method implementations when needed
• SearchCode does grep-like pattern searches across the codebase
• SearchDocs lets it search and retrieve Xojo documentation directly

These tools are designed to be token-efficient. Instead of dumping your entire project into the context window, the AI requests only what it needs, when it needs it. A ProjectOverview call might use 300-500 tokens. A GetSignatures call on a class gives the AI the API surface without the implementation details. This layered approach means even large projects work well within context limits.

Read-Only by Design

One decision I made early on was that Zotto would be read-only. It can read your code, analyse it, suggest changes, and generate snippets — but it cannot modify your project files, create new items, or execute IDE scripts.

This is intentional. I think AI-generated code should be reviewed by a developer before it goes into a project. Zotto gives you copy-pasteable suggestions and lets you decide what to implement. You stay in control.

Bring Your Own Model

Zotto isn’t locked to a single AI provider. It supports Claude, OpenAI, Gemini, Ollama, LM Studio, and any OpenAI-compatible API (which covers services like Grok and OpenRouter). If you’re privacy-conscious or working on sensitive code, you can run it entirely offline with a local model through Ollama or LM Studio. Your code never has to leave your machine.

This also means you’re not paying for Zotto’s AI usage — you use your own API keys or local models, so you’re in full control of costs.

How It Works in Practice

A typical workflow looks like this:

1. Open your project in the Xojo IDE
2. Launch Zotto — it detects the IDE automatically
3. Select which open project to work with
4. Start chatting

From there, you might ask the AI to review a class, suggest how to refactor a method, help you understand unfamiliar code in a project you’ve inherited, or brainstorm an approach to a new feature. Because the AI can explore the project itself, the conversation feels much more natural than the copy-paste dance with a generic chatbot.

For example, you could ask: “What does the ProcessOrder method in OrderManager do?” Instead of you having to find and paste the code, Zotto’s AI will call ReadCode to look at the method itself, then maybe GetSignatures on the parent class to understand the broader context, and give you a thorough explanation.

Extending with MCP

For developers who want to go further, Zotto supports the Model Context Protocol (MCP). This lets you add custom tool servers — for file system access, Git operations, database queries, or anything else you might want the AI to have access to during a conversation. It’s the same protocol that Claude Desktop and other AI tools support, so existing MCP servers work out of the box.

Built for the Community

Zotto exists because I needed it for my own Xojo development. I was spending too much time being the translator between AI tools and my codebase. Once I had something working, it seemed like other Xojo developers would find it useful too.

There’s a free version you can try that includes full IDE integration and all the built-in tools with a single conversation. A full license is a one-time purchase of £69 — no subscription. You can learn more and download it at zotto.app.

If you have questions or feedback, I’d love to hear from you on the forum.

Garry Pettet is a Consultant Radiologist, Xojo developer and the creator of Zotto. You can find him on the Xojo forum or at zotto.app.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In 2025, guest authors shared their expertise and real-world experience on the Xojo Blog. These posts bring fresh perspectives, practical solutions and deep technical insight that help other developers learn faster, solve problems more effectively and feel more connected to the Xojo community.

Guest posts in 2025 included:

• Martin T., Xojo MVP: Hide the Tabs in an Android MobileTabPanel Using Declares
• Martin T., Xojo MVP: Xojo for Android: A Two-Year Retrospective
• Martin T., Xojo MVP: It’s here – Android Design Extensions 4.0
• Anthony Cyphers, GraffitiSuite and Xojo MVP: Handling Feature Requests
• Kem Tekinay, Xojo MVP: MemoryBlocks For Speed: A Case Study
• Kem Tekinay, Xojo MVP: The Beauty of Binary Searches
• Jürg Otter: Build a Xojo Plugin with GitHub Actions
• Ezekiel Burke, Iron Elephant Solutions: Introduction to PocketBase: A Backend Alternative for Xojo Developers

We are always looking for users in the Xojo community who want to share a problem they’ve solved, a creative solution or an interesting project. If you’re interested in contributing a guest post or have an idea you’d like to explore, send it to me at alyssa@xojo.com.

In 2024, we introduced the Spotlight On series to highlight the work Xojo users do and their experiences using Xojo. Since many Xojo users don’t fit the mold of a traditional developer role, Spotlight On offers a fun and approachable way to learn how someone got started with Xojo and how they use it today. Spotlights can focus on an individual developer, a business or a specific Xojo-based project.

Spotlight On features in 2025:

• Spotlight On: GraffitiSuite
• Spotlight On: xDev Magazine
• Spotlight On: LX Aer
• Spotlight On: EKlectic Accounting
• Spotlight On: Raximus Studios
• Spotlight On: Richard Klingler
• Spotlight On: Enrique Contreras
• Spotlight On: Offroad Portal
• Spotlight On: Tim Dietrich
• Spotlight On: Sounds In Sync
• Spotlight On: Android Design Extensions
• Spotlight On: Aaron Andrew Hunt

If you’d like to be featured in a future Spotlight On or know someone in the Xojo community whose story would be great to share, we’d love to hear from you. Reach out with suggestions to me at alyssa@xojo.com.

The Xojo Blog is at its best when it reflects the voices, experiences and creativity of the community itself. Whether through guest posts, Spotlight On posts or shared ideas, we look forward to continuing to learn from and celebrate the people who make Xojo what it is.

Alyssa has been with Xojo for over 18 years. She loves solving problems and building community. You can reach her at alyssa@xojo.com or through any of Xojo’s social media channels. If you can’t reach her she’s probably out hiking the beautiful trails through her city of Portland, Oregon, or maybe enjoying a drink with friends by the river.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

for each item as ArrayType in myArray
  if item.Matches( myValue ) then
    YesSiree( myValue )
    exit
  end if
next

That’s pretty easy, but what if the array is really big? And what if you have to do this many times?

For example, let’s say your array has 10,000 items. For each value that doesn’t match, your code will have to do 10,000 comparisons. But, if your array can be sorted, you can perform that task with, at most, 14 comparisons using a binary search.

The concept is simple: you take an ordered list and start in the middle. If what you’re trying to match is less than that point, you discard the upper half of the list, then start again at the midpoint of the rest. By continuously cutting the list in half, you will do, at most, Ceil(Log2(arrayCount)) comparisons per value.

For simplicity’s sake, let’s say you want to search an array of strings. (Yes, a Dictionary would be the better choice here, but this is just for illustration.) The code would look something like this:

myArray.Sort

var firstIndex as integer = 0
var lastIndex as integer = myArray.LastIndex

while firstIndex <= lastIndex
  var midPoint as integer = ( lastIndex - firstIndex ) \ 2 + firstIndex

  var compare as string = myArray( midPoint )

  if myValue = compare then
    YesSiree( myValue )
    exit
  end if

  if myValue < compare then
    lastIndex = midPoint - 1
  else
    firstIndex = midPoint + 1
  end if
wend

With that 10,000-item array, the first loop would look at item 5,000. If myValue is greater than that, it would next look at item 7,500. Still greater? Now it will look at item 8,750, and so on. The entire array will be processed efficiently with large chunks never needing examination at all. If you have to do this for 1,000 different values, you will end with, at most, 14,000 comparisons instead of 10 million.

Quite the savings, right?

Kem Tekinay is a Mac consultant and programmer who has been using Xojo since its first release to create custom solutions for clients. He is the author of the popular utilities TFTP Client and RegExRX (both written with Xojo) and lives in Connecticut with his wife Lisa, and their cat.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Create a new Android project with two container controls in the IDE, to which you add some controls. Then switch back to Screen1 in the Navigator and add a MobileSegmentedButton and a MobileTabPanel. In the Inspector, set the locking for the TabPanel to all four sides and assign both container controls to the TabPanel via the Inspector. Those are the basic preparations.

The MobileTabPanel is a subclass of Android’s TabLayout view (com.google.android.material.tabs.TabLayout). This consists of the tabs themselves and a so-called ViewPager that holds the containers.

First, we remove the top tab bar from the control. After that, we update the position of the area where the containers are displayed. Then we disable the swipe gesture (optional). And that’s it.

Now add the Opening event to TabPanel1. First, we add two Android-specific import Declares so that the following Declares don’t take up too much space and readability is maintained:

Declare Sub import1 Lib "android.view.*:Import"
Declare Sub import2 Lib "android.widget.*:Import"

Next, we remove the tab bar from the control:

' Removes the tab bar from the MobileTabPanel.
Declare Function RemoveTabs Lib "Kotlin" Alias "(ref as ViewGroup).apply { visibility = View.GONE }" (ref As Ptr) As Ptr
Call RemoveTabs(Me.Handle)

After that, we adjust the top position of the ViewPager by setting it to 0:

' Update control bounds.
Declare Function GetLayoutParams Lib "Object:Me:MobileTabPanel" Alias "_tabPager!!.layoutParams" As Ptr
Declare Function UpdateLayoutParams Lib "Kotlin" Alias "(ref as FrameLayout.LayoutParams).apply { topMargin = 0 }" (ref As Ptr) As Ptr
Call UpdateLayoutParams(GetLayoutParams)

Now add the Pressed event to the MobileSegmentedButton with this code, which ensures switching between the panels:

TabPanel1.SelectedPanelIndex = segmentedIndex

And that’s it – click Run to start the project.

To make the control feel even more like a PagePanel, we now want to eliminate the ability to switch between panels with swipe gestures. To do this, go back into the TabPanel1 Opening event and add this code:

' Disable swipe.
Declare Sub setUserInputEnabled Lib "Object:Me:MobileTabPanel" Alias "_tabPager!!.setUserInputEnabled" (value As Boolean) setUserInputEnabled(False)

And that’s it: the control is now a PagePanel – without tabs and within the same bounds as the TabPanel.

Here you can see the PagePanel in action.

Once you know where and what to look for in the Android API, there’s almost nothing you can’t already do with Declares in Xojo Android. But if you are looking for a native solution, you can join my feature request to implement MobilePagePanel on Android.

Happy Coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Most of the development effort over the past two years was certainly spent fixing compiler errors. In 2023 and 2024, the framework was still encountering errors during app builds. Since then, the situation has improved significantly—thanks in large part to hundreds of issues submitted by users. Example projects were particularly helpful for the Xojo team in identifying and fixing bugs. It’s always important to show Xojo how we as users work with the IDE and write our code, as our approaches often differ and expose edge cases that Xojo doesn’t cover out of the box. The past two years have therefore also helped Xojo better understand how developers actually use the product.

The initial Android beta in 2023 included a basic set of UI controls. Over time, four more were added: MobilePopupMenu, AndroidMobileUserControl, MobileMapViewer, as well as classes like Barcode, TCPSocket, and UserAuthentication. This brings the Android target closer to the iOS feature set, with the long-term goal of enabling unified mobile projects that can build for both platforms. However, some steps are still needed to reach that point. The Android framework itself has seen substantial improvements over the past two years. Several new classes were added to enhance the developer and user experience compared to other platforms: RegEx, Set, ColorGroup, structures, localization, dark mode support, and more.

I asked Paul Levebvre, the lead developer of the Android framework, what the most challenging moments over the last two years were for him: “It may have been only two years, but I feel like I’ve aged 10! I am pleased with the forward progress and it’s always great to see the amazing things that people have created with Xojo for Android. The hardest thing to get working—by a wide margin—was the debugger. Nothing else comes close. In the past two years, the most difficult things have probably been TCPSocket, Operator_Convert, ColorGroup, MapViewer, and ByRef. Right now, the plan is to continue fixing bugs and adding features to get Android to feature parity with iOS.”

The development of the Android Design Extensions began early in the public alpha phase of Xojo Android. This close integration led to numerous improvements and enhancements in the Android Declare engine. Today, there’s practically nothing you can’t implement on Android using Declares, even native controls—provided there’s no built-in Xojo support yet. Naturally, this does require some knowledge of the Android API and the Kotlin programming language. With the help of the Android Design Extensions, you can further enhance your apps, much like you might already do in your iOS projects using Jérémie Leroy’s iOS Design Extensions.

Of course, there’s still a lot of work to be done to bring Android up to the same level as iOS. For example, support for custom attributes and AttributeInfo is still missing, along with several control-specific features, the DatabaseConnection class, XML handling, PDFDocument, and more. It’s important that we test thoroughly and cover as many edge cases as possible to make Android support truly stable—and to ensure that the full Xojo language feature set works as expected. As a welcome side effect, the Xojo documentation has also improved significantly through this extensive testing. Encouraging, indeed.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

With the introduction of the new MobileMapViewer for Android, users now have the ability to customize the behavior and appearance of MobileMapViewer instances. For example, they can hide the zoom controls by using SetZoomControlsEnabledXC(False), or enable/disable certain gestures (zoom, rotation, etc.). You can also set the minimum and maximum zoom level for the control by using the SetMaxZoomPreferenceXC or SetMinZoomPreferenceXC methods.

Android 15 users now also gain access to 16 additional system colors.

Give it a try! More exciting Android features are coming soon. Stay tuned!

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Understand the Need

The first step when I tackle a feature request is to thoroughly understand what the request is really about. People rarely have the ability to articulate exactly what they need, but are great at giving you just enough details — in small bursts — to figure it out if you carefully investigate their use case.

If you’re unsure of what they’re really trying to accomplish, ask for clarification. It’s better to spend more time up-front finding out what you really need to do than it is to rewrite your changes later. If you find yourself frequently modifying new code based on additional requests shortly after writing it then you may need to work on your communication.

Slow down, ask questions, try to get it right the first time. It’s not always as simple as a specification document (assuming you have one).

Understand the Code

Now that you understand the request, it’s time to analyze the code. Let’s be real, very few people can keep their entire codebase in their mind. Read through your code. Like a book. Follow function calls, property setters, everything. Make sure you understand what you’re modifying before you proceed, and look for the areas you’ll need to modify.

Sometimes this is much easier than others depending on the complexity of the project. And take notes! This step is especially important if you’re working on Other People’s Code (OPC).

Understand the Path

Next, develop a plan. Since you’ve read through code and, presumably, developed some ideas on the best way to implement, develop your own specification for the change. Give yourself time to fully work out the new implementation — I use private notes in my support system for wrapping my head around everything, which has the benefit of giving me greater insight if I need to come back later for some reason.

Work out the path forward before you ever modify any code by noting where you’ll make changes and what those changes might entail, keeping in mind that your previous functionality should continue to work as expected. This might involve creating new code paths specifically for the new feature to ensure that you don’t break old, working code. It’s also important to note things outside the scope of the new feature that you’ll need to test afterward to be sure that you didn’t break anything.

Build the Road

After you have a plan, it’s time to start building. If your strategy has been adequately outlined and you enjoy writing code, this is probably the most fun part. Follow your plan and make changes as you’ve outlined them. Be on the lookout for edge cases or caveats that you may have missed in your specification notes, chances are that they do exist.

Test Everything

Finally, testing! Don’t just test the new feature, test the old functionality as well. It’s common that feature requests require modifying existing systems and you don’t want to push out that new release with a cool new feature only to have existing functionality break. Your work will look rushed and careless, and that’s worse than it taking a bit longer to complete.

Bonus Tip

Know when to rewrite. Over time codebases can become monolithic and overly complex based on continually adding features that were never considered when the project or features being modified were first created. If you find yourself spending more and more time trying to understand your code paths or fixing old functionality that new features break, it may be time to develop a new project specification and start from scratch. Don’t be afraid of tossing out something that causes you endless headaches to modify.

Conclusion

Whether working in a team or solo, a slow and methodical approach to feature requests will ensure that your changes last and customers are happy. Don’t rely on code reviews to catch issues or multiple requests after the fact to get everything right. You’ll make mistakes and miss things, but your work will be much better received with a little additional care.

But when you do need that extra boost, it’s an option to consider, and I recently came across a scenario where it made a huge difference.

The (One Billion Row) Challenge

This came about from a discussion of the “One Billion Row Challenge” on the Xojo Forum, where a programmer is tasked with reading a billion rows of temperature data and consolidating it into statistics for each given city. Our friend Mike D started a project to demonstrate different techniques, and I eventually started my own project. Using MemoryBlock, Ptr, and preemptive threading, I was able to process a billion rows in roughly 8 seconds.

But that’s not the point of this post.

See, in order to process the data, you must first create it, which isn’t as straightforward as it seems.

Creating The Data

Each row of the data file takes the form “City;temp”, where “temp” is single-place decimal between -99.9 and 99.9. For purpose of limits, I used, arbitrarily, 413 random cities out of a list of all cities. The original code looked something like this where “bs” represents a BinaryStream:

Var r As New Random

For i As Integer = 1 To rowCount
  Var city As String = cities(r.InRange(0, cities.LastIndex))
  Var temp As Double = r.InRange(-999, 999) / 10.0

  bs.Write city + ";" + temp.ToString("#0.0") + EndOfLine
Next

This was simple, easy, and slow. To generate the full billion rows took about 2.5 hours.

Memory-Unblocking

Upon investigation, I rediscovered what I already knew. Dealing with strings, both in conversion and concatenation, can be a bottleneck. I won’t go through all the iterations here, but nothing I tried made a significant difference. The only solution was to ditch strings entirely.

I started with creating a MemoryBlock “buffer” (“outMB”) of 1 MB with an associated Ptr (“outPtr”). (You can access the contents of a MemoryBlock through its methods, but those are function calls, which have an overhead. Ptr methods are operators that work with the bytes directly so they are faster.) The plan was to fill the buffer as much as I could, write it to the file, then start again at the top of the buffer.

Keeping a position index, I started with writing the city using outMB.StringValue since there is no equivalent Ptr method for this. Next, I plugged in the value of a semicolon with outPtr.Byte(outMBIndex) = 59.

Working with integers is faster than doubles, so I used a little math to plug in the temperature values directly using If statements and outPtr.Byte.

Finally, I used outPtr.Byte(outMBIndex) = 10 to plug in the linefeed (ASCII 10).

The final code looked something like this:

Const kEOL As Integer = 10
Const kHyphen As Integer = 45
Const kDot As Integer = 46
Const kZero As Integer = 48
Const kSemicolon As Integer = 59

Var r As New Random

Var outMB As New MemoryBlock(1000000)
Var outPtr As Ptr = outMB

Var outMBIndex As Integer = 0

For row As Integer = 1 To rows
  Var cityIndex As Integer = r.InRange(0, cities.LastIndex)
  Var city As string = cities(cityIndex)
  Var cityBytes As Integer = city.Bytes

  If (outMBIndex + cityBytes + 10) >= outMB.Size Then
    bs.Write outMB.StringValue(0, outMBIndex)
    outMBIndex = 0
  End If

  outMB.StringValue(outMBIndex, cityBytes) = city
  outMBIndex = outMBIndex + cityBytes

  outPtr.Byte(outMBIndex) = kSemicolon
  outMBIndex = outMBIndex + 1

  If r.InRange(0, 4) = 0 Then
    outPtr.Byte(outMBIndex) = kHyphen
    outMBIndex = outMBIndex + 1
  End If

  Var temp As Integer = r.InRange(0, 999)
  Var t1 As Integer = temp \ 100
  Var t2 As Integer = (temp \ 10) Mod 10
  Var t3 As Integer = temp Mod 10

  If t1 <> 0 Then
    outPtr.Byte(outMBIndex) = t1 + kZero
    outMBIndex = outMBIndex + 1
  End If

  outPtr.Byte(outMBIndex) = t2 + kZero
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = kDot
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = t3 + kZero
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = kEOL
  outMBIndex = outMBIndex + 1
next

If outMBIndex <> 0 Then
  bs.Write outMB.StringValue(0, outMBIndex)
End If

This code is far longer, harder to follow, and difficult to maintain, which goes back to my original point of why MemoryBlock should be avoided.

It also generates one billion rows of data in about a minute (as opposed to 2.5 hours).

It’s nice to have the option.

Kem Tekinay is a Mac consultant and programmer who has been using Xojo since its first release to create custom solutions for clients. He is the author of the popular utilities TFTP Client and RegExRX (both written with Xojo) and lives in Connecticut with his wife Lisa, and their cat.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Xojo plugins are add-ons that extend the functionality of the Xojo development environment, allowing developers to add additional features, integrate third-party libraries, and much more.

Write a Xojo Plugin

This article assumes familiarity with the Xojo Plugin SDK and focuses on automating plugin builds. If you’re new to plugin development, check out the resources in Xojo’s “Extras” folder, YouTube tutorials, and the Xojo Forum.

It builds on my previous blog post Xojo Github Actions and involves Docker, which has also been a part of a previous blog posts (Docker, Database Servers and Xojo, Running Xojo Web Applications in Docker). So read up there on what a GitHub Actions workflow is, what the .yaml files in the Folder .github/workflows are used for.

Build a Xojo Plugin

Since Xojo is a cross platform development environment, a Xojo plugin needs to be built for all the supported platforms (Windows, macOS, Linux) and all their architectures (Intel/ARM, 32/64Bit).

All the plugin parts (the Windows .dll‘s, .macOS .dylib‘s and Linux .so‘s) are being packaged into a .xojo_plugin file.

One of the challenges is to have an environment to build all that. At the first glance it seems that one would need a Mac, a Windows machine – as well as some Linux environment (any of which could also just be a virtual machine). And one would first think that there will be a lot of manual steps involved – building the plugin source on various machines, copying all the built plugin parts together to finally assemble the resulting .xojo_plugin.

However – all that is not required. You can build a Xojo plugin without your own machine being involved, fully automated. GitHub Actions provides all we need.

Example: CubeSQLPlugin

Let us have a look at this existing Open Source Plugin.

CubeSQLPlugin is an extension for the Xojo programming environment that allows developers to use CubeSQL, a fully featured and high performance relational database management system built on top of the SQLite database engine.

The plugin is being used in the Open Sourced Administrations Tools for CubeSQL, which are both written in Xojo: CubeSQL Web Admin and CubeSQL (Desktop) Admin.

Internally the plugin uses LibreSSL for TLS Connections of Database Clients to CubeSQL Server. This means that first the LibreSSL libs need to be built for all build targets. Only then can the plugin source be built again for all build targets. And finally, all the plugin parts need to be assembled into the Xojo plugin structure for the final .xojo_plugin.

We have automated the whole build process of the plugin using GitHub Actions by having created three workflows. You’ll find their source in the folder .github/workflows. All workflow executions you’ll find on GitHub in the tab named Actions (as long as they have not been deleted or removed).

LibreSSL
This workflow will download the LibreSSL Source, and build it for all needed build targets. It needs to be run only once, e.g. if a new LibreSSL version is available that should be included for the next plugin build. That’s why it’s a workflow that can be run manually. It asks which LibreSSL version should be built and whether the built libraries should be committed and pushed to the repository.

CubeSQLPlugin
This workflow will build the CubeSQL Xojo Plugin for all build targets using the currently committed LibreSSL libs in the repository. It will commit and push all the built .dll‘s, .dylib‘s and .so‘s to the repository.

Create Release
That one is pretty obvious, right? It builds the structure of the final .xojo_plugin and creates a new Release in the repository with the final Xojo plugin – ready to be downloaded.

Build for all Platforms and Architectures

The two workflows “LibreSSL” and “CubeSQLPlugin” are similar in their approach to building for all the supported platforms (Windows, macOS, Linux) and all their architectures (Intel/ARM, 32/64Bit).

GitHub offers hosted virtual machines to run workflows. All virtual machines contain an environment of tools, packages, and settings available for GitHub Actions workflows to use.

So our workflows can simply use these environments. The workflows consist of several steps, each of which can be executed on a different runner. Remember that I’ve written: “You can build a Xojo plugin without your own machine involved”?

In the following ScreenShot we’re seeing that the Linux-ARM64 plugin part is being created on a Ubuntu 24.04.1 ARM machine.

macOS

• Runs on a GitHub macOS virtual machine.
• Uses the preinstalled Xcode command line tools to build “Intel x86_64” and “ARM64” and combine the two to a universal binary.
• CodeSigns with credentials added as repository secrets.

Linux

• ARM32, ARM64
  • Runs on a GitHub Linux virtual ARM machine.
  • To always have exactly the same build toolset (e.g. so that it doesn’t matter if GitHub updates to a newer Ubuntu version) it leverages a Docker container (e.g. arm64v8/gcc) – and actually builds the source inside the Docker container.
• i386, x86_64
  • Runs on a GitHub Linux virtual Intel machine.
  • Also uses a gcc Docker Image to build the source.

Windows

• Runs on a GitHub Windows virtual machine.
• Uses the preinstalled Visual Studio environment to build all “win32”, “x64” and “ARM64”.

How to Build your Xojo Plugin

I’m very well aware that this article can’t help you build your plugin. Each one is individual and needs its own steps and processes.

However, should you consider automating your plugin build process. You might want to look in more detail in the open-source plugin source and the workflows which are building CubeSQLPlugin for all required targets and architectures.

How to Transition from Manual to Automated

While creating a plugin, one doesn’t think of its build process in the early stages, maybe not even for the first few released versions. 

Plugin building is usually a manual process, requiring manual execution of a lot of steps and commands on various machines. It is tedious and prone to errors. It takes time, which adds up the more you build. There’s a point when one should think about streamlining and automate the process, allowing for building new versions without too much effort.
In addition, it’s certainly a good idea to have a consistent build environment other than your own development machine as you could install and change things on there which could impact the builds. That’s why building inside a Docker container is an interesting approach – it will remain exactly the same each and every time, even if the host machine is changed (e.g. by being updated to a new operating system version).

All that used to be like that before having written the GitHub workflow.

How can you transition from a manual to an automated process for your own project? I won’t be able to provide all answers. But, I’d like to give a few ideas of possible steps, with no intention of them being complete or the best choice for your project.

• Use a version control system.
  • Git and GitHub are (for many use cases) free.
  • Using a Cloud solution serves as a backup should something happen to your machines.
  • You can additionally benefit from other services such as the GitHub Actions workflows mentioned in this article.
• Everything that is only in your head should go into some written form. Once you don’t need to do something for some time, you might forget or miss something.
  • Start with documenting all steps, commands, and actions.
• Try to get rid of manual steps. Are you copy-and-pasting several commands to a terminal each and every time?
  • Put them in a shell script, so that you only need to run one command.
  • You can use these scripts later when going to a fully-automated system.
• When initial development is finished and you’re ready to release:
  • Don’t do releases from your development machine. It might be defunct, broken, stolen, or you’re installing some new cool stuff and suddenly notice issues with other projects. Having a dedicated build machine is one idea.
  • Another is going the “GitHub Actions” way which also has its benefits.
    • Runners are virtual machines that are provisioned and “fresh” every time. It’s always the very same environment to start with for each build, no matter what you’re doing during a build.
    • You don’t need to maintain many different build machines yourself. This can even solve some security issues, as it’s probably not your main interest of keeping everything up to date. I prefer to focus on programming and not on system maintenance.
    • However, the runners might be outdated in a few years – and new runners (with newer operating systems) will be available.
      • That’s usually not a very big issue on macOS and Windows since their build tools are usually backwards compatible for quite a long time.
      • Especially for Linux we have decided not to rely on the provided host but use a Docker Image and run the builds inside a Docker container. So you can, for example, use a Docker container with an image that perfectly fits your lowest compatibility needs, while the host itself might only have (too) new libraries installed.
  • Start putting all your steps and scripts into a workflow – be it just on your dedicated build environment, or using GitHub Actions.
    • Certainly separate them per required host (macOS / Windows / Linux).
    • Split a long script into smaller parts, e.g: Download LibreSSL, Build x86_64, Build arm64, Build Universal.
      • In case of an error, it’s easier to see that “macOS: Build arm64 has failed”, compared to “Build for macOS has failed” (because it’s all in a lengthy script).
• Running the workflows manually is great and likely more than good enough.
  Once the project activity grows (e.g. you’re receiving a lot of pull request or have many developers working on it):
  • Ensure that the build and test workflows are running on each pull request, require them to complete successfully before being able to merge. That by the way has been explained in the previous blog post Xojo GitHub Actions. After all, no one wants to find out after many commits that the build is no longer working, and then have to search the history for what might have caused the problem.
• You’ll notice that once it’s all automated you no longer miss it. It causes no additional effort for you, instead bringing a lot of benefits (such as noticing early when code changes cause oddities in tests and builds).

A Fun Fact

In the early days a build of the CubeSQLPlugin often took a couple of hours – and with personal attention needed so that one couldn’t work on much else during that time.

The first iteration of the workflows reduced the entire build (LibreSSL + Plugin) to about 25 minutes. With no attention and manual interaction needed – which means more time for other work. What took the longest was the LibreSSL ARM builds – they have been run on Intel hardware with QEMU for ARM emulation.

Back to the beginning of this article and Xojo’s 2025 Year of Code initiative – in February I have improved the workflows to use the newly available GitHub Actions runners that run on ARM hardware. Which means that no more emulation is required – and the build time has now come down to about 4 minutes for LibreSSL Libs (required only once per new LibreSSL version) and 2.5 minutes for the Xojo database plugin for all its supported platforms and architectures!

That’s All Folks!

I hope this brief introduction of how to use GitHub Actions workflows and Docker to build a Xojo plugin has been helpful to some, food for thought to others.

Jürg Otter is a long term user of Xojo and working for CM Informatik AG. Their Application CMI LehrerOffice is a Xojo Design Award Winner 2018. In his leisure time Jürg provides some bits and pieces for Xojo Developers.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

When developing applications with Xojo, choosing the right backend is crucial for managing data efficiently. Traditionally, Xojo developers rely on SQL databases such as SQLite, MySQL, or PostgreSQL for their desktop, web, and mobile applications. However, there is an alternative that provides a more flexible and modern approach to backend development: PocketBase.

PocketBase is an open-source backend perfect for your multi-platform Xojo application. It offers a simple-to-use API and a built-in admin panel to manage the data from any web browser. No other tool such as MySQL, Workbench, or SQL Studio is needed. In this post, I will explain how it compares to traditional SQL databases and demonstrate how to integrate it into a Xojo project.

Why Choose PocketBase for Your Xojo App Backend?

PocketBase is a lightweight, self-hosted backend designed for simplicity and flexibility. Unlike traditional SQL databases that require a separate backend service or API layer, PocketBase is an all-in-one solution that combines the database and API.

Key Features:

Embedded Database – Powered by SQLite, eliminating the need for a separate database server.

Built-in User Authentication – Supports email/password logins, OAuth2 sign-ups, and one-time password (OTP) with minimal setup.

File Storage – Store and retrieve files locally or via S3.

Cross-Platform Compatibility – Runs on macOS, Windows, and Linux. Can communicate via URLConnection making it ideal for Xojo’s desktop, web, and mobile platforms.

Easy Deployment – A single binary file that can be self-hosted or deployed anywhere with minimal configuration.

Setting Up PocketBase for a Xojo App

To get started, I have simplified some steps below. If you get stuck or want more in-depth instructions take a look at the documentation.

• Download PocketBase
  • Visit PocketBase and download the latest release for your operating system.
  • Extract the files to your project directory.
• Run PocketBase
  • Start the PocketBase server by navigating to the extracted folder in the command prompt/terminal.
  • Run the command: ./pocketbase serve to start the server.
• Access the Admin Panel
  • Open http://127.0.0.1:8090/_/ in a web browser and set up an admin account.
• Add a User
  • In the PocketBase admin panel, create a new record in the users collection. (Collections are the equivalent of a table in SQL.)

Connect Xojo to PocketBase

Now that your PocketBase server is running, integrate authentication into your Xojo desktop app. In this example, we will handle authentication in the open event of the main window. This will demonstrate how Xojo interacts with PocketBase’s authentication API.

Implement the Login Request

Add the following code to the open event of your main window:

Var userEmail As String = "email@email.com"
Var userPassword As String = "MyPassword!"
Var loginURL As String = "http://127.0.0.1:8090" + "/api/collections/users/auth-with-password"
Var conn As New URLConnection
conn.RequestHeader("Content-Type") = "application/json"
 
Var loginPayload As New JSONItem
loginPayload.Value("identity" ) = userEmail
loginPayload.Value("password") = userPassword
conn.SetRequestContent(loginPayload.ToString, "application/json")
 
Var loginResponse As String = conn.SendSync("POST", loginURL)
Var jsonResponse As New JSONItem(loginResponse)
Var userInfo As JSONItem = jsonResponse.Lookup("record", New JSONItem)
Var userID As String = userInfo.Lookup("id", "")
Var authToken As String = jsonResponse.Lookup("token", "")
 
If authToken.Length > 0 Then
  MessageBox("Login successful! Welcome, User ID: " + userID)
Else
  MessageBox("Login failed. Please check your credentials.")
End If

Update Your Credentials and URL

Replace userEmail and userPassword with the credentials you used to create a user in PocketBase. Also, ensure the loginURL matches your PocketBase instance (without /_/ at the end).

Run The App

Launch your Xojo app. If authentication is successful, a message box will display the user’s ID. Otherwise, you will see an error message indicating that the credentials are incorrect.

Wrapping Up

In this article, you have successfully set up a PocketBase server, created a record, and integrated authentication into your Xojo app. PocketBase simplifies backend development by handling authentication and data storage—all without the need for a traditional SQL database.

With PocketBase, there is no need to set up complex user tables, hash passwords, or build a custom API. Collections can be easily managed directly from the web via the admin panel. This means you can spend less time managing infrastructure and more time focusing on bringing your app to market.

To help you get started, I’ve created a collection of example projects, which you can find here:

Xojo-Pocketbase-Examples

If you’d like to discuss how Iron Elephant Solutions has used Xojo and PocketBase in real-world applications, feel free to reach out through our website or add me on LinkedIn.

Ezekiel Burke is the founder of Iron Elephant Solutions. He focuses on building custom, scalable, and affordable software that helps businesses work smarter. With 15+ years of experience, he specializes in full-stack development, process automation and systems integration, creating solutions that simplify complex workflows.

You can now use the SetBottomAppBarMenuAlignmentModeXC extension method for MobileScreen to set the alignment of the buttons in your MobileScreen.Toolbar.

Additionally, new declares for MobileMessageBox have been added, allowing you to display an icon next to the title as well as next to individual buttons.

Give it a try! More exciting Android features are coming soon. Stay tuned!

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

My answer was, of course, “Let me have a look and get back to you.”

I went to my favourite dev tool, Xojo, and went through the process of developing a solution. The connection is a REST API, so I’ll start with a web project and use the HandleURL event. And I’ll use a URLConnection to pass on the request.  Wait … could it be that simple?

Function HandleURL(request As WebRequest, response As WebResponse) Handles HandleURL as Boolean

  // Create the outbound connection
  Var connector As New URLConnection
 
  // Copy the content of the request
  connector.SetRequestContent(request.Body, request.MIMEType)

  // Send the request
  Var result As String
  Try
    result = connector.SendSync("POST", kAddress + request.Path)
  Catch err As RuntimeException
    // Catch DNS, Certificate & Timeout errors
    response.Status = 500
    response.Write(err.Message)
    Return True
  End

  // Return the result of the request
  response.Status = connector.HTTPStatusCode
  response.Write(result)

  Return True

End Function

The answer is, “Yes!”  This is all the code in the entire project.

You will notice that there is no security, but in this instance that is fine as the virtual machine is running this is on the same network as the client server and the firewall is configured to only allow connections from that server.

After processing over 60 thousand requests, memory use is 7.3MB and never exceeded 13MB. CPU usage was at the maximum 1.5%.

Even after using Xojo for 20 years this still blows my mind.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

For more detailed information, you can refer to the official Xojo documentation on Variants.

What are Variants?

A Variant in Xojo is a data type that can store any type of data. This means that a variable of type Variant can take on different data types without needing to be explicitly converted. This can be very useful when you want to be flexible, but it can also lead to unexpected problems if not handled correctly.

Basic Example

Var dynamicValue As Variant

dynamicValue = 42                              // Integer
dynamicValue = "Hello"                         // String
dynamicValue = 3.14                            // Double
dynamicValue = True                            // Boolean
dynamicValue = Color.RGB(255, 0, 0)            // Color
dynamicValue = New Dictionary("key" : "value") // Dictionary

In the example above, you can see that dynamicValue can take on different data types without the need to explicitly change the type.

Implicit Conversions

Implicit Conversions are automatic type conversions performed by Xojo when using Variants. This means that Xojo tries to interpret the data in a Variant so that it fits the context in which it is used.

Example of an Implicit Conversion

Var dynamicValue As Variant = "123"

Var myInteger As Integer
myInteger = dynamicValue  // Implicit conversion from String to Integer

In this example, the string “123” is automatically converted to an integer when assigned to the integer variable myInteger.

Another Example with Data Types

Var dynamicValue As Variant = "3.14159"

Var myDouble As Double
myDouble = dynamicValue  // Implicit conversion from String to Double

Here, the string “3.14159” is automatically converted to a double. This demonstrates the flexibility of Variants and Xojo’s ability to handle different data types.

Conversion of Floating-Point Numbers

In Xojo, assigning a floating-point number to a Variant will always produce a Double. However, there are other floating-point data types such as Single, Currency, and CGFloat.

Var dynamicValue As Variant = 3.14

Var myDouble As Double
Var mySingle As Single
Var myCurrency As Currency
Var myCGFloat As CGFloat

myDouble = dynamicValue   // Double: 3.14
mySingle = dynamicValue   // Single 3.14 (implicitly converted)
myCurrency = dynamicValue // Currency: 3.14 (implicitly converted)
myCGFloat = dynamicValue  // CGFloat: 3.14 (implicitly converted)

In this example, you can see that assigning dynamicValue (which contains a floating-point number) to different floating-point data types always works, with the implicit conversion performed by Xojo.

Advantages of Implicit Conversions

Flexibility

The biggest advantage of Variants is their flexibility. You can write functions that can work with different data types without requiring explicit type conversion.

Example of a Flexible Function

Function AddValues(value1 As Variant, value2 As Variant) As Variant
  Return value1 + value2
End Function

// Using the function with different data types
Var result As Variant
result = AddValues(10, 20)             // Integer addition
result = AddValues("Hello", " World")  // String concatenation
result = AddValues(3.14, 2.71)         // Double addition

This function can work with integers, strings, and doubles without requiring changes to the code.

Rapid Prototyping

During rapid prototyping, Variants can be useful because they reduce the need to worry about type conversions.

Example of a Quick Prototype

Var quickData As Variant = "42"

If quickData > 10 Then
  MessageBox("Greater than 10")
End If

In this example, the string “42” is automatically converted to an integer to perform the comparison.

Disadvantages of Implicit Conversions

Debugging

It can be difficult to debug errors caused by incorrect type conversions. Since the conversion happens automatically, it is sometimes not obvious why a particular error occurs.

Performance Issues

Implicit conversions can lead to performance issues, especially when large amounts of data need to be converted.

Example of Performance Issues

Var dynamicValue As Variant = "9999999999"
Var myDouble As Double

For i As Integer = 1 To 1000000
  myDouble = dynamicValue  // Performance hit due to repeated conversions
Next

In this example, the conversion is performed during each iteration of the loop, which can impact performance.

Loss of Type Safety

Another risk is the loss of type safety, which can lead to unexpected runtime errors.

Type Property

The Type property is a useful tool to determine the data type of a Variant value. This property returns an integer that corresponds to the type of the value. This can be helpful to ensure that you are handling the correct data type.

Example of Using the Type Property

Var dynamicValue As Variant = "Hello"

Select Case dynamicValue.Type
Case Variant.TypeString
  MessageBox("The variant is a String.")
Case Variant.TypeInt32, _
     Variant.TypeInt64
  MessageBox("The variant is an Integer.")
Case Variant.TypeDouble
  MessageBox("The variant is a Double.")
Case Variant.TypeBoolean
  MessageBox("The variant is a Boolean.")
Else
  MessageBox("The variant is of another type.")
End Select

In this example, dynamicValue.Type is used to determine the type of the Variant value and perform corresponding actions.

When Should You Use Variants?

Suitable Use Cases

Generic Functions

If you are writing functions that need to work with different data types, Variants can be very useful.

Function CompareValues(value1 As Variant, value2 As Variant) As Boolean
  Return value1 = value2
End Function

// Using the function with different data types
Var isEqual As Boolean
isEqual = CompareValues(10, 10)          // True
isEqual = CompareValues("Hello", "Hello")  // True
isEqual = CompareValues(3.14, 2.71)      // False

Interoperability with External APIs

When working with APIs or interfaces that return different data types, Variants can provide an easy way to handle this data.

// Example API response that can return different data types
Function GetApiResponse() As Variant
  // Simulated API response
  Return "42"  // Could also be an Integer or a JSON object
End Function

Var apiResponse As Variant = GetApiResponse

If apiResponse.Type = Variant.TypeString Then
  MessageBox("Response is a string: " + apiResponse)
ElseIf apiResponse.Type = Variant.TypeInt32 Or _
       apiResponse.Type = Variant.TypeInt64 Then
  MessageBox("Response is an integer: " + apiResponse)
End If

Data Structures

In situations where you need data structures that contain different data types (e.g., an array that can contain both strings and numbers), Variants are a good choice.

Var dataList() As Variant
dataList.Add("Xojo")
dataList.Add(2024)
dataList.Add(True)

// Accessing different data types in the array
For Each item As Variant In dataList
  Select Case item.Type
  Case Variant.TypeString
    MessageBox("String: " + item) 
  Case Variant.TypeInt32, _
       Variant.TypeInt64
    MessageBox("Integer: " + item) 
  Case Variant.TypeBoolean
    MessageBox("Boolean: " + item)
  End Select
Next

Situations to Avoid Using Variants

Performance-Critical Applications

When performance is critical, you should avoid Variants because automatic type conversion introduces additional overhead.

Var dynamicValue As Variant = "9999999999"
Var myDouble As Double

For i As Integer = 1 To 1000000
  myDouble = dynamicValue  // Performance hit due to repeated conversions
Next

Code Clarity and Maintainability

When code readability and maintainability are paramount, you should use explicit data types to ensure that the code is understandable to other developers.

Var myString As String = "Hello"
Var myInteger As Integer = 123

Function ConcatenateStrings(s1 As String, s2 As String) As String
  Return s1 + s2
End Function

Var result As String
result = ConcatenateStrings(myString, myInteger.ToString)  // Clear and understandable

The use of Variants in Xojo offers both advantages and disadvantages. While flexibility and rapid prototyping capabilities are compelling arguments, you should be aware of the potential problems that can arise from implicit conversions. Variants are best suited for scenarios where flexibility and generic programming are required. In performance-critical applications or projects that require high maintainability, it is advisable to use explicit data types such as String, Integer, Double, Boolean, Color etc. or, if you decide to use Variant, you can also have the explicit data type of the Variant delivered. To do this, use the Variant …Value properties (for example StringValue, IntegerValue, BooleanValue etc.).

By taking a conscious and deliberate approach to using Variants, you can leverage their advantages while avoiding potential pitfalls.

For more detailed information, you can refer to the official Xojo documentation on https://documentation.xojo.com/api/data_types/variant.html.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What are Delegates?

A Delegate in Xojo is essentially a “pointer” to a method. It allows you to dynamically reference a method, treating it as if it were a variable. This means that a method can be passed to another method or function like a data variable.

' Defining a Delegate
Delegate Sub MyDelegateMethod(value As Integer)

' Method to be called
Sub PrintNumber(value As Integer)
  MessageBox("Number: " + value.ToString)
End Sub

' Using the Delegate
Sub UseDelegate()
  Var d As MyDelegateMethod = AddressOf PrintNumber
  d.Invoke(10) ' Calls PrintNumber with the value 10
End Sub

In this example, a delegate MyDelegateMethod is defined to reference a method with an Integer parameter. Then, the method PrintNumber is assigned to the delegate variable d, and it is invoked using d.Invoke().

What is AddHandler?

The AddHandler command is used in Xojo to dynamically associate a method with an event. Instead of assigning an event handler in the design phase, this can be done at runtime. This allows for more flexible programming, especially in situations where event handling routines need to be assigned or changed dynamically.

' Method that acts as an event handler
Sub ButtonPressed(sender As DesktopButton)
  MessageBox("Button was pressed!")
End Sub

' Using AddHandler
Sub SetupButtonHandler(button As DesktopButton)
  AddHandler button.Pressed, AddressOf ButtonPressed
End Sub

In this example, the ButtonPressed method is dynamically associated with the Pressed event of a DesktopButton. When the button is pressed, the ButtonPressed method shows a message.

Important Note: Using RemoveHandler with AddHandler

Whenever you use AddHandler, it’s important to remember to use RemoveHandler to properly un-assign the event handler when it’s no longer needed. If you fail to remove the handler, you may encounter memory leaks or unexpected behavior, especially when working with objects that are frequently created and destroyed.

' Removing the event handler
Sub RemoveButtonHandler(button As DesktopButton)
  RemoveHandler button.Pressed, AddressOf ButtonPressed
End Sub

In this case, RemoveHandler is used to detach the ButtonPressed method from the Pressed event of the DesktopButton. This is especially useful when a button or event source is about to be destroyed or when you no longer want the handler to respond to events.

Similarities between AddHandler and Delegates

1. Dynamic Behavior: Both Delegates and AddHandler allow for the dynamic assignment of methods, providing more flexibility in the flow of the program.
2. Method Referencing: Both concepts use the AddressOf syntax to reference a method.
3. Flexibility: Both mechanisms are useful for reacting to specific events or functions at runtime.

Differences between AddHandler and Delegates

1. Purpose:

• Delegates are more general and are used to treat methods as variables and pass them as parameters to other methods.
• AddHandler is specifically designed for event handling. It is used to assign methods to events at runtime.

2. Target Structure:

• Delegates are strongly typed. They require an exact match between the method signature and the delegate.
• AddHandler binds methods to events, which require a predetermined signature but are dictated by the context of the object used.

3. Lifetime:

• Delegates can exist as standalone variables within any scope.
• AddHandler is tied to the event and object it is associated with. If the event or object is destroyed, the handler is no longer called.

Achieving the same functionality with both approaches

Event Handling with AddHandler

Let’s assume we have a timer event and want to specify at runtime which method should be called when the timer elapses.

' Method called by the Timer event
Sub TimerAction(sender As Timer)
  MessageBox("Timer elapsed!")
End Sub

' Dynamically assigning the event with AddHandler
Sub SetupTimer(timer As Timer)
  #If TargetMobile
    AddHandler timer.Run, AddressOf TimerAction
  #Else
    AddHandler timer.Action, AddressOf TimerAction
  #EndIf

  timer.RunMode = Timer.RunModes.Multiple
  timer.Period = 1000
End Sub

In this example, the TimerAction method is assigned to the Run/Action event of a timer at runtime.

Same Functionality with Delegates

Now, the same logic but using Delegates:

' Defining a Delegate for Timer actions
Delegate Sub TimerDelegate(sender As Timer)

' Method to be called
Sub TimerAction(sender As Timer)
  MessageBox("Timer elapsed!")
End Sub

' Assigning and invoking the method via a Delegate
Sub SetupTimerWithDelegate(timer As Timer)
  Var d As TimerDelegate = AddressOf TimerAction

  #If TargetMobile
    AddHandler timer.Run, d
  #Else
    AddHandler timer.Action, d
  #EndIf

  timer.RunMode = Timer.RunModes.Multiple
  timer.Period = 1000
End Sub

In this case, a Delegate is used to reference the same TimerAction method, but the structure remains nearly identical.

AddHandler and Delegates both provide ways to dynamically handle methods at runtime in Xojo. While Delegates are more flexible and general-purpose, AddHandler is specifically designed for dynamic event handling. Both mechanisms are useful depending on the use case. The main difference lies in how they are used and their target structure: Delegates are strongly typed and can be used anywhere in the code, whereas AddHandler is used to link methods to events dynamically.

Additionally, when using AddHandler, it is crucial to remember to use RemoveHandler to properly unbind event handlers when they are no longer needed. Failing to do so can lead to performance issues, memory leaks, or unintended behavior, especially when dealing with dynamic or temporary objects.

By combining these two techniques, you can make Xojo programs more flexible and dynamic.

Happy Coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value that is unique worldwide. UUIDs are commonly used in software development to identify objects and have the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, where each “x” is a hexadecimal digit.

The Code: GenerateUUID

The following code shows a simple Xojo function that uses the built-in Java method on Android to generate a UUID. The function allows you to create the UUID either with or without hyphens, depending on your project requirements.

The Code:

Function GenerateUUID(useHyphens As Boolean = True) As String
' https://developer.android.com/reference/java/util/UUID
  Declare Function generateUUID Lib "java.util.UUID" Alias "randomUUID().toString" As CString

  Var uuid As String = generateUUID

  If useHyphens Then
    Return uuid
  Else
    Return uuid.ReplaceAll("-", "")
  End If
End Function

Code Explanation:

● Declare Function generateUUID: This Declare statement gives us access to Android’s native Java library. We use the shared randomUUID method from the java.util.UUID class to generate a random UUID. This method returns the UUID as a string.

● Var uuid As String = generateUUID: The generated UUID is stored as a string.

●  useHyphens: This optional parameter controls whether the UUID is returned with or without hyphens. The default value is True, meaning the UUID will be returned in its usual format with hyphens.

●  If useHyphens Then … Else: Depending on the value of useHyphens, either the standard UUID is returned or a hyphen-free version, where the ReplaceAll method is used to replace all hyphens with an empty string.

Use in Your Android Project:

1. UUID with Hyphens: If you want to get the UUID in its standard format with hyphens, you can call the function without any arguments:

Var myUUID As String = GenerateUUID 
' Example result: 123e4567-e89b-12d3-a456-426614174000 

2. UUID without Hyphens: If you prefer a UUID without hyphens, you can pass the argument False to the function:

Var myUUID As String = GenerateUUID(False) 
' Example result: 123e4567e89b12d3a456426614174000 

Why Use UUIDs?

UUIDs are ideal for cases where you need to ensure that every generated identifier is unique, even if they are generated by different devices or systems. Some common use cases in Android development with Xojo include:

●  Uniquely identifying users or devices

●  Creating keys for database entries

●  Tagging objects in a distributed application where no identifier conflicts should occur

With the GenerateUUID function, you can easily generate a unique UUID on Android devices using Xojo, without worrying about the complexities of native Android APIs. This method integrates seamlessly into your Android application and offers the flexibility to generate UUIDs with or without hyphens. If you’re working on a project where uniqueness is crucial, using UUIDs should be at the top of your list.

Good luck with your Android project in Xojo!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

From now on, Buttons and TextFields can use Xojo Pictures directly and you no longer need to save images that you want to use. Take a look at the “Deprecations Version 3.0” section in the Read me to find out which methods are deprecated in this regard.

Now it’s getting colorful!

In this version, support for over 180 system colors has been added, depending on which Android version your app is running on. The sample app has a new page with the system colors. It gives you a good overview. Using these colors can help you to design your apps according to the Material Design Guidelines in light & dark mode.

Picture objects and the content of a MobileHTMLViewer can now also be printed.

We are familiar with the DrawInto method from the Desktop Framework, which draws DesktopUIControls and DesktopWindows into a Graphics object. These methods have now also been added for MobileUIControls and MobileScreen.

The title bar and the NavigationBar can now also be highlighted in color. The font, color and alignment of the NavigationBar can also be changed.

How? What? Where?

The system paths for various folders (SpecialFolder) have also been added.

Almost all modules have been updated according to the new Declare data types. The example app has also been further optimized for dark mode in this version.

The new Declare capabilities in Xojo 2024r3 are another huge step forward. You now have the possibility to declare in almost every Android API without having to go through an Android library.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In The Beginning

Threads have been a part of of the Xojo language for a long time, and by now experienced users know the basics: subclass a Thread, fill in the Run event, then call Start. The code in Run will execute independently from the rest of your code leaving your app responsive while it does work in the background.

Mostly.

See, until now, a Thread was only “cooperative”, meaning it ran alongside your main code with the framework deciding when to switch between them and how long each should execute. While the main code was running, the Thread code was paused, and while the Thread was running, the main code was paused.

Think of it like standing before two devices that perform different functions when cranked, but only having one crank available. You run the first machine for a bit, then the other, then back to the first, until they are done. And you do it really, really fast.

This worked pretty well when your goal was, say, to keep your user interface responsive. You could spin long-running code into a Thread, then present the results once it finished.

But it was inadequate if your objective was to speed up some intense process, or the code in your Thread did not present logical places to yield time back to your main code. In the former scenario, you were better off not using a Thread, or perhaps using Worker (a severely limited earlier attempt at allowing simultaneous processing), while in the latter you would have to manually yield back processing time, leading to even slower operation.

In The Now

Cooperative threads are fine for many tasks, but when you need something that truly runs independently within your app, a “preemptive” thread is required.

A preemptive thread spins off onto another core in your machine, which probably has at least four, and runs there entirely isolated from other threads. It’s like launching a separate, mini-app that you can share information with.

The limitations that apply to cooperative threads drop away. Since it runs on a different core, it cannot slow down or interfere with your main code, and will run as fast as its core will allow.

Challenging Times

This sounds almost too good to be true, but it’s not without its challenges. While cooperative threads were rather easy to work with, preemptive threads require an extra layer of thought and awareness for Xojo users.

When a cooperative thread’s code is running, you know nothing else is, so you don’t have to worry about, say, updating a Dictionary or removing an element from an array. But with preemptive threads, code runs simultaneously with other code so you cannot just update that Dictionary if there is a chance that the main code, or another preemptive thread, might be doing it too.

Consider this example.

// In our thread
If MyArray.Count = 0 And FinishUp Then
  Exit
Else
  Process MyArray.Pop
End If

//////////////////////////////

// In the main code
FinishUp = True
MyArray.Add 1

You might think the thread is going to process the last element and then exit its loop because FinishUp was set to True, but with preemptive threads we have to be aware of race conditions where the order of actions is unpredictable. Here, the main code could set FinishUp to True, and the thread could see that MyArray was empty and exit before the main code could add the last element. Conditions can change at literally any instant, even in the middle of a single line of code.

Fortunately, there are ways to protect against this and you must use them to ensure orderly operation and avoid surprises.

Know Your Type

The first step is creating a preemptive thread, and Xojo’s implementation is pretty straightforward. Rather than introducing a unique class, you can continue to work with the existing Thread by setting its new Type property to Thread.Types.Preemptive. The Type can be set when instantiating the Thread or from within its running code. You can even switch types at will, although once running, the Type can only be changed from within the Thread.

Example:

// A subclass of Thread called PThread

MyThread = New PThread
PThread.Type = Thread.Types.Preemptive
PThread.Start

Or within the Run event, you could do this:

Me.Type = Thread.Types.Preemptive

You can also set Type through the Inspector after dragging a Thread to a window.

Protect Yourself

Now that you have a preemptive thread ready to go, you have to think about how to protect common resources. Xojo has done a good job of making a lot of the framework safe, but that just means your app shouldn’t crash if, say, the Thread tries to manipulate a variable at the same time as other code. It’s up to you to make sure one area of your app doesn’t clobber the changes made by another.

Consider this code that maintains a Dictionary of Integer arrays.

// Thread code
Var arr() As Integer

If MyDictionary.HasKey(x) Then
  arr = MyDictionary.Value(x)
Else
  MyDictionary.Value(x) = arr
End If

arr.Add 1

//////////////////////////////

// Main code
If Not MyDictionary.HasKey(x) Then
  Var arr() As Integer
  MyDictionary.Value(x) = arr
End If

Run this long enough and you’re going to wonder why some data got lost. Why? Because both the Thread and main code might be checking for the key at the exact same instant and filling it in when it’s not found. If the Thread does it first, the main code will almost instantly replace it with an empty array.

Instead, you should use a Semaphore or CriticalSection to make sure code is protected.

You’d first instantiate one of these in a common property like a Window or Module. (I’m using Semaphore here, but it works the same for CriticalSection.)

MySemaphore = New Semaphore
MySemaphore.Type = Thread.Types.Preemptive

Notice the new Type property? It must match the one in Thread and can be used between the main code and a Thread or between same-typed threads. (This is one of the limitations of Xojo’s implementation: you cannot share a Semaphore or CriticalSection between preemptive and cooperative threads.)

The example can be updated like this:

// Thread code
Var arr() As Integer

MySemaphore.Signal

If MyDictionary.HasKey(x) Then
  arr = MyDictionary.Value(x)
Else
  MyDictionary.Value(x) = arr
End If

MySemaphore.Release

arr.Add 1

//////////////////////////////

// Main code
MySemaphore.Signal

If Not MyDictionary.HasKey(x) Then
  Var arr() As Integer
  MyDictionary.Value(x) = arr
End If

MySemaphore.Release

This will force either the main code or Thread to wait for the other to complete before continuing, ensuring proper order and avoiding the race condition.

Limitations

Using preemptive threads comes with certain restrictions. The biggest one is the aforementioned inability to share a Semaphore or CriticalSection with a cooperative thread. The other is the same as in a cooperative thread: you cannot update a user interface component directly instead relying on the UserInterfaceUpdate mechanism (more on that below).

If you are setting up multiple threads to work on different parts of some object, that may crash hard depending on the type of object. For example, writing to the same file or different parts of a MemoryBlock is fine, but updating a Picture may not be. In those cases, you will have to get creative.

What’s It Good For?

Choosing preemptive threads over cooperative means that you either have some code that needs to truly run in the background that would otherwise interfere with you user interface, or you have some large task that can be logically processed in parts.

Window Service

In the former case, the easiest technique might be to drag a Thread to your window, set its Type, and implement the Run event. It can be started from within the window either through a manual process like a pressing a button, or automatically when the window opens.

Just like with a cooperative thread, you can send data back to your window using the AddUserInterfaceUpdate method and implementing the UserInterfaceUpdate event.

Splitting It Up

If your task involves something that can be split up into logical chunks, I encourage you to look at my ThreadPool module, accessible through the Xojo Examples or my GitHub page. (The latter has a README with more details.)

The ideal usage for ThreadPool is when you have some data that can be processed in sections. For example, suppose you wanted to count the vowels in a large file. You could subclass ThreadPool and implement its Process event to count one block. You would then send the file into your subclass in chunks of, say, 256k each and gather the results.

The benefit of ThreadPool, among other things, is that it will handle the coordination for you so the dangers of using preemptive threads are minimized. You still have to consider how to send your results back to your main code safely, perhaps using Semaphore/CriticalSection or the AddUserInterfaceUpdate method, but each block can be considered independently of the others.

(A big thanks to MVP Anthony Cyphers for writing the example included with Xojo.)

Juggling Chainsaws

The power of preemptive threads is clear, but the potential pitfalls can be serious. Unless you’re very careful, you can easily create bugs that may not be readily apparent, and may take hours or even days to track down. (I say this from unfortunate experience.) Unless you have a compelling reason to take on that challenge, don’t bother.

What I’m trying to say is, if a cooperate thread does the job adequately, there is no need to introduce the headache that preemptive threads can bring.

But if you do have a legitimate need, like a long-running process that needs to run quickly without blocking your UI, go for it, just be careful.

In any case, it’s great that we finally have that option.

Kem Tekinay is a Mac consultant and programmer who has been using Xojo since its first release to create custom solutions for clients. He is the author of the popular utilities TFTP Client and RegExRX (both written with Xojo) and lives in Connecticut with his wife Lisa, and their cat.

Need More Information? Read more about preemptive threads in the Xojo Documentation and Blog. Or read about Semaphore and CriticalSection, also on the Xojo Blog.

What is Overhead?

Overhead refers to the additional computational and memory effort that does not directly contribute to the execution of the main tasks of an application. This can arise from various factors, such as inefficient algorithms, unnecessary computations, or redundant memory allocations. High overhead can lead to slow response times and increased resource consumption.

Identifying Overhead with Code Profiling

To effectively minimize overhead, it is first important to identify it. This is where code profiling comes into play. Profiling is a runtime analysis technique that provides insight into how long certain parts of your code take to execute and how often they are called. Xojo offers integrated tools for this purpose, such as the Profiler, which gives you detailed information about your application’s performance. Code profiling is available on all targets except Android.

Steps to Profiling in Xojo:

1. Activating the Profiler: Go to the menu item Project > Profile Code to enable or disable the profiler.
2. Manual Profiling with StartProfiling and StopProfiling: Use the StartProfiling and StopProfiling methods in your code to analyze specific sections.
3. Analyzing the Profiler Results: After running, you will receive a report showing which methods and functions take the most time.

For more information on the Code Profiler, see the Xojo Documentation.

Example of Manual Profiling

With StartProfiling and StopProfiling, you can target specific parts of your code for profiling. Here’s a simple example:

Var total As Integer = 0

// Start profiling
System.DebugLog("Profiling started")
StartProfiling

For i As Integer = 0 To 1000000
  total = total + i
Next

// Stop profiling
StopProfiling
System.DebugLog("Profiling stopped")

In this example, the profiler is activated only for the loop to analyze its performance precisely.

Techniques to Minimize Overhead

Once you have identified the areas with optimization potential, you can apply various techniques to reduce overhead:

1. Algorithmic Optimizations:

–  Use more efficient algorithms. An O(n) solution is better than an O(n^2) solution.

–  Avoid recursive algorithms when iterative solutions are available to avoid stack overhead.

2. Memory Management:

–  Minimize unnecessary memory allocations and deallocations.

–  Use local variables as much as possible and avoid global variables to reduce memory consumption.

3. Data Structures:

–  Choose the right data structures for your requirements. For example, arrays are often faster than other structures for sequential data access.

–  Use dictionaries for fast lookups as they manage key-value pairs efficiently.

4. Asynchrony and Parallelism:

– Use asynchronous programming and multithreading to perform tasks in parallel and improve the responsiveness of the user interface.

5. Code Simplicity:

–  Write clear and simple code. Complex structures and nested loops increase overhead.

–  Use Xojo’s pre-built functions and libraries, which are often more optimized than custom implementations.

Tips and Tricks for Optimization

1. Lazy Loading:

Load resources only when they are needed instead of loading everything at the start of the application.

2. Caching:

Implement caching mechanisms to avoid repeated computations and database queries.

3. Avoiding Polymorphism:

Polymorphic calls are often more expensive than direct function calls. Use them only when necessary. Polymorphism is a concept in object-oriented programming that allows objects of different classes to be treated through a common interface. In Xojo, this means you can define methods in a base class and override them in derived classes. However, this can add overhead as the exact method call must be resolved at runtime.

4. Using Breakpoints and Inspectors:

Set breakpoints and use the debugger inspector to check runtime data and identify inefficient parts of the code.

Example: Optimizing a Loop

Here is an example of how to optimize a loop:

// Unoptimized code
Var total As Integer = 0
For i As Integer = 0 To dataArray.LastIndex
  total = total + dataArray(i)
Next

// Optimized code
Var total As Integer = 0
Var lastIndex As Integer = dataArray.LastIndex
For i As Integer = 0 To lastIndex
  total = total + dataArray(i)
Next

In this example, we moved the LastIndex method call out of the loop since repeatedly calling it creates unnecessary overhead.

Minimizing overhead in Xojo applications requires careful analysis and optimization of your code. By using code profiling, you can identify the areas that consume the most runtime and take targeted actions to optimize them. The techniques, tips, and tricks presented here can significantly improve the efficiency of your applications and ensure a better user experience.

Leverage Xojo’s powerful tools to keep your applications lean and fast, and benefit from improved performance.

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Why Clean Coding Matters

Before diving into the specific practices, it’s important to understand why clean coding matters:

1. Readability: Clean code is easier to read and understand, which is crucial when multiple developers are involved or when you revisit your code after some time. This reduces the cognitive load on developers, making it easier to grasp the code’s functionality quickly.

2. Maintainability: Code that follows clean coding principles is easier to maintain and update, reducing the risk of introducing bugs. Maintainable code allows for efficient troubleshooting and quick implementation of changes or new features.

3. Scalability: Clean code can be more easily extended with new features, facilitating the growth of your application. Well-structured code makes it easier to see where and how new functionality can be added without disrupting existing features.

Key Practices for Clean Coding in Xojo

1. Use Meaningful Names

Using meaningful and descriptive names for variables, methods, and classes is one of the simplest yet most powerful practices in clean coding. Avoid abbreviations and opt for clear, self-explanatory names. This practice helps other developers understand your code without needing extensive documentation.

Example:

// Bad
Var n As Integer

// Good
Var userCount As Integer

In the good example, userCount clearly indicates the purpose of the variable, making the code easier to understand at a glance.

2. Follow Consistent Coding and Naming Conventions

Consistent naming conventions make your codebase uniform and easier to navigate. Establish and follow conventions for variables, methods, properties, and classes.

Read more detailed about Coding and Naming Conventions in the Xojo Documentation

3. Keep Methods Short and Focused

Each method should perform a single, well-defined task. If a method is too long or performs multiple tasks, consider refactoring it into smaller, more focused methods. This makes the code more modular and easier to test and maintain.

Example:

// Bad
Sub ProcessUserData()
  ' Code to validate user input
  ' Code to save user data to the database
  ' Code to send a confirmation email
End Sub

// Good
Sub ProcessUserData()
  ValidateUserInput
  SaveUserData
  SendConfirmationEmail
End Sub

Sub ValidateUserInput()
  ' Validation logic
End Sub

Sub SaveUserData()
  ' Database saving logic
End Sub

Sub SendConfirmationEmail()
  ' Email sending logic
End Sub

By breaking down ProcessUserData into smaller methods, each method has a single responsibility, which makes the code easier to understand and maintain.

4. Comment Wisely

Comments should explain why something is done, not what is done. The code itself should be self-explanatory whenever possible. Over-commenting can clutter the code, while under-commenting can make it difficult to understand the rationale behind certain decisions.

Example:

// Bad
// Increment the user count by 1
userCount = userCount + 1

// Good
// Increment the user count to keep track of active users
userCount = userCount + 1

In the good example, the comment provides context for why the increment is necessary, which might not be immediately obvious from the code alone.

5. Use Constants and Enumerations

Avoid using magic numbers and strings. Instead, define constants and enumerations for values that have specific meanings. This makes your code more readable and easier to update.

Example:

// Bad
If statusCode = 200 Then
  ' Success logic
End If

// Good
Const kHTTP_SUCCESS As Integer = 200
If statusCode = kHTTP_SUCCESS Then
  ' Success logic
End If

Using kHTTP_SUCCESS instead of 200 makes the code more readable and the purpose of the value clearer.

Enumerations

Enumerations (enums) are a powerful way to represent a set of related constants. They make your code more readable and maintainable by grouping related values under a single type. This can be particularly useful for handling states, options, or categories in your application.

Example:

// Define an enumeration for user roles
Enum UserRole
  Admin
  Editor
  Viewer
End Enum

// Use the enumeration
Var currentUserRole As UserRole = UserRole.Admin

Select Case currentUserRole
Case UserRole.Admin
  ' Admin-specific logic
Case UserRole.Editor
  ' Editor-specific logic
Case UserRole.Viewer
  ' Viewer-specific logic
End Select

In this example, the UserRole enum defines three possible roles: Admin, Editor, and Viewer. Using an enum makes the code more readable and ensures that only valid roles are assigned to currentUserRole.

6. Handle Errors Gracefully

Implement proper error handling to ensure your application can gracefully recover from unexpected conditions. Use Try…Catch blocks and meaningful error messages. This practice improves the robustness and user experience of your application.

Example:

Try
  ' Code that might throw an exception
Catch e As OutOfBoundsException
  // Log the error and inform the user
  System.DebugLog("Error: " + e.Message)
  MessageBox("An unexpected error occurred.")
End Try

By catching exceptions and providing informative error messages, you help users understand what went wrong and how to proceed, while also aiding in debugging and logging.

7. Refactor Regularly

Refactoring is the process of improving the structure of your code without changing its functionality. Regular refactoring helps keep your code clean and manageable. It involves restructuring your code to improve its internal structure while maintaining its external behavior.

Example:

Before refactoring:

Sub DoEverything()
  ' Lots of code here
End Sub

After refactoring:

Sub DoEverything()
  PerformTaskA
  PerformTaskB
  PerformTaskC
End Sub

Sub PerformTaskA()
  ' Task A code
End Sub

Sub PerformTaskB()
  ' Task B code
End Sub

Sub PerformTaskC()
  ' Task C code
End Sub

By breaking down DoEverything into smaller tasks, the code becomes more modular and easier to maintain.

Advantages and Disadvantages of Clean Coding

Advantages

1. Improved Readability: Clean code is easier for other developers and yourself to read and understand, which is crucial for effective collaboration and maintenance.
2. Easier Maintenance: Maintenance tasks are simplified with well- structured and well-documented code, reducing the time and effort required to update and debug the code.
3. Fewer Bugs: Following clean coding principles reduces the risk of bugs by promoting clarity and simplicity in the code.
4. Better Collaboration: Teams can work more efficiently together when the code is understandable and consistent, reducing misunderstandings and errors.
5. Scalability: It’s easier to integrate new features when the code is well- structured, as the modular design allows for more straightforward extensions.

Disadvantages

1. Time Investment: Clean coding requires more time and effort, especially in naming, documentation, and refactoring. This can slow down initial development but pays off in the long run.
2. Initial Learning Curve: Developers unfamiliar with clean coding principles need time to learn and apply them, which can temporarily decrease productivity.
3. Over-Perfection: There’s a risk of spending too much time perfecting the code, which can impact overall productivity and delay project timelines.

Clean coding is not just a set of guidelines but a mindset that can significantly improve the quality of your software. By adopting clean coding practices in Xojo, you ensure that your codebase remains readable, maintainable, and scalable. Whether you are working on a small project or a large application, these principles will help you write better code and build more robust software.

Incorporating clean coding practices into your development workflow might require an initial investment of time and effort, but the benefits far outweigh the costs. Clean code leads to fewer bugs, easier maintenance, and a codebase that can grow and evolve with your project’s needs.

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This small update runs exclusively for all Xojo 2024r2+ versions and now offers methods to access a few more system details, such as specific folders (MobileApplication.GetCacheDirXC, GetDataDirXC, GetFilesDirXC, etc.) or methods for checking screen properties like MobileApplication.IsScreenHdrXC, IsScreenRoundXC, ScreenHeightDpXC, or ScreenWidthDpXC.

Feel free to take a look at the developer repository, create feature requests, and provide feedback on extending this extension library.

I’m happy to receive any voluntary financial support for the work I’ve done so far, which you are welcome to share here. You can download the project with many examples at https://github.com/XojoGermany/AndroidDesignExtensions.

Happy coding.

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Last week, I attended the WWDC 2024 event in Cupertino. It took place in both the original Infinite Loop campus, as well as the Apple Park “spaceship” campus which opened in 2017 and cost $5 billion to build. Apple’s WWDC events are no longer a traditional developer conference. The developer session videos are all uploaded for free, and even the keynote is a prerecorded, so event attendees see it at the same time as the rest of the world. Instead, this is more of a social event – an opportunity to meet fellow developers, bump into some famous people, and take advantage of Apple’s hospitality. I found the event uplifting and exciting, and I was able to talk with many people and share perspectives with them. 

Inside the Infinite Loop campus – rumors of a free bar may or may not be greatly exaggerated

The event was a great opportunity to share ideas and plans with other developers

Now, you might think that the event is solely for Swift developers, but this is not entirely true. Of course, Apple are constantly pitching their chosen language and frameworks at the event, but there is also a recognition that many people develop software for Apple platforms in tools other than Swift and Xcode. Of the people I spoke to, quite a number of people were using something other than Swift (including an Apple engineer!). Many of the sessions from WWDC are naturally catered towards Swift developers, but there are still some that will be useful to Xojo developers. I’ve highlighted a selection of videos below, along with my own description.

I want more stuff

When browsing WWDC videos, if you come across new functionality or an API that isn’t exposed in Xojo, the best course of action is to create a feature request at https://tracker.xojo.com. But don’t stop there. Tell the community about your request on the forum and ask them to give the request a “thumbs up” if they agree. This helps the Xojo team gauge interest. For some requests, you may also want to rope in support from me or one of the other MVPs, so that we can potentially engage with the team directly on your behalf at one of our regular meetings.

At each WWDC, Apple releases beta versions of its new tools and operating systems. These are very early versions, especially at this point in the beta cycle, and should not be installed on your main machines without very good reason. Early anecdotal evidence suggestions few problems with Sequoia (the new version of macOS) and Xojo apps, but testing such software should be done in virtual machines or on machines that you don’t use for your daily coding. When Xojo support for the new OS and the new version of Xcode becomes official, the System Requirements page will be updated at https://documentation.xojo.com/resources/system_requirements_for_current_release.html

Highlighted WWDC 2024 videos

“What’s new in App Store Connect”

Take better advantage of the App Store, get your app nominated for featuring and more.

“Add personality to your app through UX writing”

This is a quintessentially Apple presentation, but it may be thought provoking. What is the tone of your app? Does it matter for your market?

“Implement App Store Offers”

Self-explanatory from the title. Most of this will require the use of MBS plugins.

“Platforms State of the Union 5-Minute Recap”

The full State of the Union presentation, which follows the main keynote each WWDC, is rather lengthy and not required viewing for Xojo developers. But the five minute recap is worth watching to get an overview.

“Build multilingual-ready apps”

A lot of this video involves Swift code but there is still useful information for everyone in this.

Notes: 

• Apple also have a “Expanding your app to new markets” document at https://developer.apple.com/localization/. 
• To take advantage of much of this in your Xojo apps, see https://documentation.xojo.com/topics/localizing_your_apps/introduction_to_app_localization.html

“What’s new in SF Symbols 6”

SF Symbols (SF stands for San Francisco) is a library of thousands of clean and simple symbols for use in Apple platforms only. Apple typically updates this yearly.

Notes:

• To take advantage of SF Symbols in your iOS apps, use the Picture.SystemImage method. See the docs at https://documentation.xojo.com/api/graphics/picture.html#picture-systemimage
• There is no built-in support for SF Symbols in Xojo Mac apps, but you can still take advantage of them. See this blog post for details: https://blog.xojo.com/2021/10/21/quicktip-using-sf-symbols-in-macos-revisited/
• Tell Xojo that this support should really be built-in! Lend your support to this case; https://tracker.xojo.com/xojoinc/xojo/-/issues/60751
• Whilst SF Symbols is Apple-only, there is also a library of images built into Xojo for Android developments, also using the Picture.SystemImage method.
• Browse SF Symbols on your Mac (and get their names for use in Xojo) by downloading the SF Symbols utility from https://developer.apple.com/sf-symbols/

More videos

Want to watch even more videos? (Shouldn’t you be coding?) Subscribe to the official Xojo YouTube channel and also see videos from the recent Monkeybread Software conference, including presentations from Xojo engineers and other MVPs. https://www.youtube.com/@MonkeybreadSoftware/videos

Gavin is a Xojo MVP and is based in the UK. He has been a Xojo developer since the first version in 1998.