MobileChart

Matching the features available for iOS, MobileChart lets you create a wide variety of charts to show in your Android app.

MobileColorPicker

This new control, as its name suggests, lets you use the system color picker to select a color.

MobilePDFViewer

Last year Android added PDFDocument support for creating your own PDFs, and now we’ve added MobilePDFViewer to give you an easy way to show PDF document files from your Android apps.

Zip/Unzip

The FolderItem class now supports the Zip and Unzip methods to make it simple to compress and uncompressed Zip files.

Android Keeps Getting Better

There are also improvements to MobileTabPanel, MobileTextArea, MobileSlider, MobileScrollableArea, Barcode and more. With each release, Android gets closer to feature parity with iOS!

And of course, we continue to squash framework and compiler bugs.

Be sure to check out the full release notes for all the details!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

With this feature you can provide custom drawing for a control at design time, making it easier to visualize your UI without running the project.

If this sounds familiar, it’s because it brings Desktop and iOS/Android projects closer to what’s already possible in Web projects with WebSDKUIControl, where custom layout rendering has been available for some time.

Why this matters

Previously your custom Canvas controls would appear as generic placeholders, making it difficult to understand how they would look at runtime. Now you can:

• Render a preview of your control directly in the layout editor
• Display dynamic or state-based visuals
• Make custom controls much easier to work with at design time

How it works

For Desktop projects, you can subclass DesktopUIControl and implement the DrawControlInLayoutEditor event. Your drawing code is executed by the IDE as it renders the control in the layout. For iOS and Android projects, this event is available on MobileUIControl.

You can also use this event directly with DesktopCanvas and MobileCanvas controls, so you can start drawing in DrawControlInLayoutEditor without needing to subclass anything.

This event gives you the flexibility to draw whatever you need—shapes, text, or even simplified representations of runtime content. For example, a custom media player control could display a play button and timeline, or a chart control could render a sample graph.

A note about XojoScript limitations

One important detail to keep in mind is that DrawControlInLayoutEditor runs using XojoScript. This allows the IDE to safely execute your drawing code at design time, but it also means not everything you’d typically expect to use in Xojo is available, especially when it comes to the graphics APIs.

In practice, most common drawing operations—such as shapes, lines, and text—work as expected. However, in some cases these graphics calls use a slightly different API, as is the case with LinearGradientBrush.

Also, because this runs as XojoScript, you cannot call other methods from within your DrawControlInLayoutEditorcode. To access your control’s properties, you’ll need to use the built-in  ColorProperty, BooleanProperty, IntegerProperty, DoubleProperty, and StringProperty methods.

Support for more Graphics

In 2026r1, we’ve expanded the graphics capabilities available to DrawControlInLayoutEditor, building on what was previously supported for WebSDKUIControl. New additions include support for:

• LinearGradientBrush, PictureBrush, and ShadowBrush
• LineDash, LineDashOffset, LineCap, LineJoin, and MiterLimit
• Outline
• Scale, Rotate, and Translate
• SaveState, RestoreState
• Color constants (Red, Green, Blue, Yellow etc.)

Since XojoScript does not support the Pair type, the LinearGradientBrush API was adapted slightly:

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

The main difference is how the brush is constructed and how stops are added, without needing Pair. With this new API, you can turn a basic graph into something much more visually appealing.

Turning off this feature

While many may prefer custom rendering for custom controls, it can become a bottleneck when a large number of controls are rendering content. If you prefer a less resource-intensive experience, you can disable this behavior in Settings → Layout by enabling the Static Rendering option.

Finally

With DrawControlInLayoutEditor now available for Desktop and Mobile projects, you can take advantage of the same benefits Web projects have enjoyed for years. Be sure to check out the new DrawControlInLayoutEditor example project, adapted from the WebSDK → CustomButton example. We hope you enjoy designing and previewing your custom controls with this new event—and yes, it also works in Libraries!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• 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

Martin started using Xojo around the time he got his first MacBook. He was drawn to Xojo’s simplicity and flexibility. If you ask him, Martin will say designing clean, intuitive user interfaces is one of his favorite parts of development. Though he’s also a Xojo MVP, he’s probably best know as the developer behind Android Design Extensions.

Mac, Windows or Linux?

Mac.

How would you explain your most recent project to a new developer?

The Android Design Extensions are a collection of enhancements for Android projects in Xojo, aimed at polishing the UI of your apps. This is the primary focus of the project. It addresses aspects that Xojo does not natively provide.

We live in a visual world—design in advertising and product presentation shapes users’ impressions of a company or product. The same applies to software. Is the UI user-friendly and visually appealing? Is it enjoyable to use the app? These questions have always been the guiding principles behind the creation of the Android Design Extensions.

What do you think Martin from 2020 would think about what you do now?

Five years ago, I could never have imagined that I would be a Xojo MVP and be able to make my own project available to other users. Android Design Extensions is the result of many hundreds of hours of intensive collaboration with the Xojo team, which has resulted in Xojo Android becoming more stable and, above all, enormously powerful. For example, in terms of declares, it’s really easy and there’s hardly anything now that you can’t implement in Android projects, as long as you know how to read the Android API and handle declares.

That’s almost the best memory of the last five years, that Xojo has listened to feedback from Android users and responded very quickly. It’s amazing how fast Android support in Xojo has progressed over the past two years.

What is on your “Learn Next” list?

Definitely delve deeper into Android APIs to explore the possibilities of Xojo Android even more.

How did you find Xojo? And when did you start using Xojo?

I first came into contact with Xojo around 2008. At that time it was still called Real Studio and I had found it on a DVD that was enclosed with a computer magazine. I was an active Delphi developer at the time and immediately fell in love with the simplicity of the language.

What do you build with Xojo now?

Fortunately, I have greatly expanded my programming skills thanks to Xojo. My focus is on UI development, controls, especially the TextInputCanvas, Android and desktop programs.

What is something you worked on that you want to talk about?

I became very friendly with TextInputCanvas (a free plugin) and together with Björn Eiríksson from Einhugur, we created an updated API 2.0 version of the plugin, which we still maintain today.

I used to work as a developer for Bob Keeney and was responsible for the Formatted Text Control, which is based on TextInputCanvas. There are several programs on the market that make intensive use of this control and I am still involved in some of these projects today, making the WYSIWYG experience even more pleasant for customers when entering text.

Do you use Xojo for any hobbies?

I also use Xojo to write software for genealogical purposes. From a young age, I developed a curiosity and desire to learn more about the history of my family and its members. That is how I came to genealogy. It is a kind of detective work that can lead to surprising family connections, secrets, strokes of fate, and even unknown relatives. Since I enjoy reading, I prefer to have such information in book form and written out, rather than in tables. A book with text feels more tangible to me—something the reader can engage with more consciously.

None of the genealogy software available on the market has ever met my expectations. That is why I wrote my own software in Xojo, which can process the standard format for genealogical data known as Gedcom. You can think of it as a database in plain text format. From this data, I can then generate—depending on what is desired—full biographies, ancestor and descendant trees, and more. The finished result is a Word document, complete with indices at the end for all people, places, professions, and so on—just like in a real book.

Thank you to Martin T. for answering questions and sharing his Xojo experience with the community. Martin accepts donations for his work on Android Design Extensions. Download Android Design Extensions. Read more about Android Design Extensions on the Xojo Blog.

• 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

UserAuthentication works similarly to how it is used on iOS. You can drag the control from the Library onto your layout and then implement the AuthenticationSucceeded event.

To request authentication, call the Request() method with a short string asking the reason why you need authentication.

UserAuthentication1.Request("Authorize me, HAL")

Because this is using system-level APIs, you and your app never know the details about the authentication. You will not know the password, passcode or have any specifics about a fingerprint or face. Instead, if the system determines that the authentication was successful, then the AuthenticationSucceeded event is called.

Here’s a quick video of it in action.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In previous releases, the MobileSharingPanel control allowed your app to share a single picture, a URL, or text with any registered iOS system service or app. Now, you can share multiple pictures at once and also share as many files as you want (including entire folders)!

To share multiple pictures, we’ve overloaded the SharingPanel.SharePicture method so its first parameter can accept an array of pictures. It’s that simple. When the panel appears, the same action will apply to the whole group.

For sharing files, you now have two methods available:

MobileSharingPanel.ShareFile(file As FolderItem, parentScreen As MobileScreen = Nil, parentControl As MobileUIControl = Nil)

MobileSharingPanel.ShareFile(files() As FolderItem, parentScreen As MobileScreen = Nil, parentControl As MobileUIControl = Nil)

The first method is designed to share a single FolderItem instance. If that FolderItem points to a folder, the entire contents of the folder will be shared.

The second method accepts an array of FolderItem instances as its first parameter. This is likely the best choice when your app needs to share a group of items from different sources, offering greater flexibility.

Overall, the enhanced SharingPanel is now more powerful and versatile. We’re excited to see how you’ll put it to use in your mobile apps!

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Before you can use MobileMapViewer you will need to have a Google Maps account configured so that you can generate an API Key. Instructions for doing this on available from Google: Google Maps Platform, Get Google Maps API Key.

Google Maps is not free to use. Although there is some free usage available for testing your app, your account does get billed based on usage once the small amount of free testing credits are used up.

When you have your API Key, you can add it to your Xojo project using a new App property. Select App in the Navigator and in the Inspector, put the key in the Google Maps API Key field. Note that the key is not saved with text projects and is instead saved as part of the UI state file that is local to the development machine. This prevents the key from being accidently committed to a source code repository.

With the configuration work out of the way, you can now use the control. Drag a MobileMapViewer from the Library onto a screen. When you run the project you’ll see an interactive map that you can swipe, zoom and move around as you like.

This code shows Fenway Park in Boston:

FenwayLocation = New MapLocation("Fenway Park, Boston, MA USA")
FenwayLocation.Title = "Fenway Park"

MapViewer1.ZoomRadius = 5
MapViewer1.GoToLocation(FenwayLocation) // Center map within radius km

MapViewer1.AddLocation(FenwayLocation) // Drop a pin

The MobileMapVIewer API matches what has already been in use for iOS. You can also use the MapLocation class to track specific locations. Although the overall API matches what has been used for iOS, there is one exception: MapLocation.PointsOfInterest() is not yet implemented. Implementing this requires another Google SDK and API Key (the Places API) and is being reviewed for a future release. We may also consider adding alternative mapping engines as well.

Note: You can’t get there from here is an old Maine saying.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

But even though I have my own pets, I do love looking at pet pictures. It’s a simple pleasure, but there’s not much that I find more calming.

Years ago I made a Xojo app (CatsUp) that displayed random cat pictures and it was a lot of fun. And one thing that Xojo excels at is making it fun to create software! That’s what the Year of Code is all about, after all.

Speaking of that, here is the Year of Code topic for May: Mobile Apps.

You can already find CatsUp for iOS and Android included in the Xojo examples, but why stop at just cats? Being a dog guy, I want to see some dogs. All the dogs.

Since I’m not here to start a cats vs. dogs war, I thought, why not both? It turns out I’m not the only one that thinks this as there are actually public web services that serve up pictures of cats and dogs. Web services and mobile apps go together like peanuts butter and chocolate.

The web service for cats that I’ve previously used is called TheCatAPI and is available here: https://thecatapi.com

There is an equivalent dog one called, unsurprisingly, TheDogAPI: https://www.thedogapi.com

For my mobile app this month, I’ve created an all-new app that can show pictures of cats, dogs or both! I call it Pawz.

Actually, it’s two apps since I made versions for iOS and Android. Here’s a look:

Although they are separate projects, both use basically the same code. In fact there is only about 50 lines of code in each project! The UI itself is just a big ImageViewer that is used to show the picture and several toolbar buttons.

There are three buttons to request a cat picture, dog picture or a surprise picture that could be either. There is also an extra button that lets you share the picture, if you really like it.

You can find the source for the iOS and Android versions of Pawz on GitHub here:

https://github.com/paullefebvre/pawz

Year of Code is all about having some fun making an app. As you can see with Pawz, it doesn’t have to be anything extravagant. Even fun apps can be made quickly with very little code!

I can’t wait to see what great mobile apps you all create this month. Share your creations in the Forum topic.

One More Thing

Although phones and tablets are what we usually think of when talking about Mobile Apps, you know what else is rather mobile? A vehicle! And it just so happens that many vehicle manufacturers, such as Cadillac, Chevy, Ford, Honda, Polestar, Renault and Volvo are now using Android to run their infotainment systems. Technically it’s Android Automotive OS (AAOS), but it is very similar to regular Android.

Because Xojo builds standard Android Runtime (ART) apps, Xojo Android apps also work on Android Automotive OS as a “parked app”. You can test with this by using Android Studio to install an Android Automotive VM for the Emulator. Once you’ve added that you can run your Xojo Android projects on it just like any other device. Pawz works fine in an AAOS Emulator.

Why do I bring this up? No reason, although I believe Xojo 2025 Release 2 pre-release testing might be starting soon…

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Year of Code Project

• Year of Code: Kickoff
• January Project: Desktop Apps | Forum Discussion
• February Project: Database Apps | Forum Discussion
• March Project: Web Apps | Forum Discussion
• April Project: User Interface | Forum Discussion
• May Project: Mobile Apps | Forum Discussion
• June Project: Code Sharing | Forum Discussion
• July Project: Charting | Forum Discussion
• August Project: Console Apps | Forum Discussion
• September Project: Games | Forum Discussion
• October Project: Multi-Platform | Forum Discussion
• November Project: PDF | Forum Discussion

How to Play:

Each month we’ll announce a new theme and share an example project of our own. Share your projects to the Xojo Forum thread for that month via GitHub (all the links you need are posted above ↑ ). Learn how to use Xojo and GitHub.

The Prizes:

Monthly winners get $100 at the Xojo store. Every month you submit a project is another chance to win the grand prize. The grand prize is $250 cash plus a Xojo Pro license and a year of GraffitiSuite and will be announce in December. Learn more about the prizes.

For the most part, writing drawing code will just work because you use Xojo’s Graphics class for Android, Desktop and iOS projects. Web projects, however, don’t use the Graphics class. The WebCanvas control’s Paint event is passed a WebGraphics object. While the Graphics and WebGraphics classes have a lot in common, sharing many of the same methods with the same parameters, they are two distinctly different classes from the perspective of the Xojo compiler. That means that while the code you write will look almost identical, you still have to use a Graphics object for Android, Desktop and iOS projects and a WebGraphics object for Web projects.

Your instinct might be to simply write the code for one and then copy it to the other projects, changing Graphics to WebGraphics for Web projects. This will of course work, but then you have to remember to do this copy/paste/change operation every time you update your code. That’s not ideal.

Graphics vs. WebGraphics

With Xojo, the code can be written in such a way as to automatically handle the difference between Graphics/WebGraphics. Most often your graphics methods will be called from something that provides a Graphics or WebGraphics object for you to draw into such as a Canvas control’s Paint event. From there your code will call your methods that do the drawing. The problem is that your methods can’t use a Graphics or a WebGraphics type as a parameter because Graphics is not going to work for your Web projects and WebGraphics doesn’t exist in any framework except the Web framework. Thus using it anywhere else will result in a compiler error.

Using a Variant

Getting around this limitation is, fortunately, quite easy. Instead of using Graphics or WebGraphics as a parameter type, you use Variant. A Variant can hold any type of data from Strings to Integers, to Graphics to WebGraphics and more.

Once your drawing method gets the Variant though, it can’t use it to draw. It can only use a Graphics or WebGraphics objects. The trick is to then copy it into a Graphics or WebGraphics class variable:

Var g As Graphics = context

or

Var g As WebGraphics = context

The problem you now face, as mentioned earlier, is that WebGraphics only exists in Web projects. That means you have to write your code in such a way that you will declare the variable g as a Graphics object in Android, Desktop and iOS projects and as a WebGraphics object in Web projects. This can be achieved via conditional compilation. This is a simple technique that tells the Xojo compiler to only compile code into your app if conditions you specify are met. In this case, if you’re targeting Desktop or Mobile, it should compile in the line that uses the Graphics type, and if you are targeting a Web app, the line that uses WebGraphics. To conditionally compile, you just need to add that conditional code around these two lines:

#If TargetDesktop Or TargetMobile Then
   Var g As Graphics = context
#EndIf

#If TargetWeb Then
   Var g As WebGraphics = context
#EndIf

Since a project must be only one of the above types, when you run or build your project, the appropriate line of code will be compiled in. From there, you now have a variable (g) of the right type can use this to draw whatever you like. For example, there are four identical example projects (one for each project type) that show off this technique. They can be found in the Xojo IDE by choosing File > New Project, clicking on Examples, choosing the Graphics folder in the list and then the Cross-Platform Drawing folder. The examples all draw a checkerboard that looks like this:

They all contain the an identical Checkerboard class that handles the drawing. This class has DrawBorder and DrawCheckers methods that both take a Variant as a parameter. In each project is a Canvas control whose Paint event calls these methods:

Var cb As New Checkerboard
cb.DrawBoard(g)
cb.DrawCheckers(g)

The full DrawBoard method looks like this:

#If TargetDesktop Or TargetMobile Then
  Var g As Graphics = context
#EndIf

#If TargetWeb Then
  Var g As WebGraphics = context
#EndIf 

Var boxSize As Integer = Min(g.Width/8, g.Height/8) 'The size of the box
'Draw the rows
For y As Integer = 0 To 7
  For x As Integer = 0 To 7
    'Switch colors for each box in the row
    If g.DrawingColor = Color.Black Then
      g.DrawingColor = Color.White
    Else
      g.DrawingColor = Color.Black
    End If
    'Draw a box
    g.FillRectangle(x * boxSize, y * boxSize, boxSize, boxSize)
  Next
  'Switch colors again for the beginning of the next row
  If g.DrawingColor = Color.Black Then
    g.DrawingColor = Color.White
  Else
    g.DrawingColor = Color.Black
  End If
Next

In the example projects, check out the DrawCheckers method as well. It uses the same technique. What is great about this is that this class can be copied into any Android, Desktop, iOS or Web project and it will indeed just work.

Checking Out the Examples

There are four example projects (one for each project type – Android, Desktop, iOS and Web) that demonstrate the technique explained here. You can find them in the Xojo IDE by choosing File > New Project, clicking on Examples, choosing the Graphics folder in the list and then the Cross-Platform Drawing folder.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

ColorGroups

Now available for Android, ColorGroups are a way to have a color that can differ between light mode and dark mode. There are three types of ColorGroups: Single, Dual and Named. Add a ColorGroup to your project using Insert->ColorGroup.

A Single ColorGroup is not really a group, it is just a single color. A Dual ColorGroup has separate colors for light and dark mode. A Named ColorGroup gets the color from the system or, in the case of Android, the app theme. You can see the available options in the Android submenu.

For the most part you can use ColorGroups just like you can with other project types. Android does have one addition, the ColorGroup.ToColor() method lets you specifically convert a ColorGroup to a Color. Normally this is done automatically by Operator_Convert, but support for that in Android is still young and this method serves as a workaround should you run into issues with it.

In the Inspector for controls with ColorGroup properties, such as MobileButton.CaptionColor, you can use the ColorGroup selector to manually choose a Color or a ColorGroup:

In addition to working with ColorGroups as project items, you can also create ColorGroups in code:

Var cg1 As New ColorGroup()
cg1.AddColorPair(ColorGroup.Platforms.Mobile, Color.Blue, Color.Teal)

You can also use Android system color names to create a named color:

Var cg2 As New ColorGroup()
cg1.AddNamedColor(ColorGroup.Platforms.Mobile, "holo_purple")

Refer to the Android docs for R.color to see what the system color names are. Keep in mind that not all names are available on all versions Android OS.

For more about ColorGroups, refer to the documentation.

Dark Mode Support

ColorGroups are particularly useful with dark mode and starting with 2025r1, Android projects now default to having Supports Dark Mode switched on.

Several controls have been improved to work better in dark mode at runtime.

In addition, the Android Layout Editor has been improved to look better when working in dark mode and now shows controls with dark mode variants.

Download the latest Xojo release and get access to these new features and more.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This control is available in the Xojo Library panel and works similarly to iOSMobileUserControl: drag it onto a layout and implement the CreateView event.

Declare Function Button Lib "Kotlin" Alias "android.widget.Button(context as android.content.Context)" (context As Ptr) As Ptr

Var bp As Ptr = Button(App.AndroidContextHandle)

Return bp

The above code uses a Declare to create a native Button and returns it so that it can be displayed in a layout.

By using AndroidMobileUserControl and Declares to access the Android UI library, you can create your own UI controls. I look forward to seeing what the community creates!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

1. Add a Constant, give it a name, default value and set its type to String.
2. A Localized property will now appear in the Inspector. Turn it on.
3. This constant will now appear in a new “Localized Strings” section in the Navigator for the project item.
4. Use the “+” button to add a localized string, then set its Language and Value.
5. Use this localized string in your project.

Below is a localized string that contains some translations of “thanks”.

The most common way to use this is to specify the localized string name as the text property for a control, such as a Label. You prefix the name with “#” to indicate it should be looked up at runtime.

Below you can see “#ThanksString” is set as the value for the Text property of Label1.

Note that “Default” is shown in the IDE because it is using the value for the “Default” language in the localized string. If there was no “Default” language, then the value specified in the Inspector as the “Default Value” is shown in the IDE.

If we then run this project on a device set to US locale, it displays “Thanks”:

If I change to a German locale and run again, it shows “Danke”:

To change the locale, open Settings on the Android device. Navigate to System and then Languages & input. There you will see the Languages option.

Choose that to see the list of languages supported by the device. Click the “+” to add a language. Here I’ve added German (Deutsch):

To make Deutsch the default, drag it so that it is first in the list. You’ll immediately see the UI change its language.

You can also specifically request a language in code by providing the locale as a parameter to the localized string. For example to get the French value:

Var french As String
french = ThanksString("FR")
// Variable french now contains "Merci".

Read the Introduction to App Localization documentation topic to learn more.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

• Structures
• ByRef parameters
• Operator_Lookup
• Operator_Convert

Structures

Structures are a fixed-size data structure that can contain properties of simple types, such as Integer, String or Boolean.

Normally you would only use Structures with Declare API calls, but they can also work as a lightweight, project item specific data structure.

For Android, Structures are not fixed-sized data structures and are not appropriate for Declares, but they offer slightly more flexibility, especially with regard to Strings. When you add a String to an Android Structure, the specified size is ignored; you can store any size string in the property.

Usage is the same. Create a Structure in the Structure editor for the project item, adding the properties you want.

Note that the Offset and Size columns are not relevant in Android since the Structure is not fixed-size.

In code, you create a structure by name:

Var st As StructTest
st.Age = 42
st.Dead = True
st.Name = "Bob Roberts"
st.Weight = 200.6

Since Android Structures are not size-based, the ByteValue, Size and StringValue members are not useful and will raise an UnsupportedOperationException when used.

ByRef Parameters

ByRef parameters allow you to pass a parameter “by reference” so that the caller can access its new value if it was changed. By default, parameters are passed ByVal (or “by value”) so that the caller does not see any changes made to them in the method.

Use the ByRef keyword in front of the parameter to make it ByRef.

The ByRef page in the docs has more information.

Operator_Lookup

Operator_Lookup might be unique to Xojo. When you add an Operator_Lookup method to a class, it essentially tells the compiler to not do a syntax check on method or property names. Instead, if the name that follows the “.” is not an actual member of the class, then the name is passed as a string parameter to the Operator_Convert method.

You can do some strange things with Operator_Lookup, including making your code much more difficult to debug. Use this advanced feature wisely.

Learn more about Operator_Lookup in the docs.

Operator_Convert

Operator_Convert is used with classes to allow them to either construct a new instance from a value of a different type or to allow them to return a version of itself that is compatible with the destination type.

Here is an example of a Person class that uses Operator_Lookup. The Person class has a property: FullName As String. This is how you might normally create an instance and assign a value to FullName:

// Person is a class with a property FullName As String
Var p1 As New Person
p1.FullName = "Bob Roberts"

Now add an Operator_Convert method to the class like this:

Sub Operator_Convert(name As String)
  Self.FullName = name
End Sub

With that method, you can now assign a string value to a Person variable and it will create an instance and assign the string value to the FullName property. The syntax looks like this:

Var p As Person
p = "Bob Roberts"

You can also add an Operator_Convert method that returns a representation of a class instance as a different type. For example, say you wanted a Person instance to be able to convert itself to a string. First you have to decide what the string would be and in this case it makes sense to use FullName.

Here is that Operator_Convert for Person:

Function Operator_Convert As String
  Return Self.FullName
End Function

This code then assigns a Person instance to a Label’s text property where it gets assigned what is in the FullName property:

Var p2 As New Person
p2.FullName = "Janet Jane"
Label1.Text = p2

Like with Operator_Lookup, Operator_Convert is an advanced feature. Use it carefully. It certainly allows for some code to be simplified, but it also means that code might not be as clear as it would if it used more standard syntax.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What’s New in Xojo 2024r4

Xojo 2024r4 brings a range of exciting updates that enhance cross-platform development, improve security, and provide more tools for creating dynamic and interactive applications. Here are some of the standout features:

Web Framework
Enjoy smoother and more efficient web applications with updates to Xojo’s Web Framework. Improved memory usage and numerous bug fixes ensure that your web apps run reliably and perform optimally, providing a better experience for your users.

Discover Web Framework Improvements

These updates and enhancements are designed to make your development process more efficient, productive, and enjoyable. Whether you’re building new applications or enhancing existing ones, Xojo 2024r4 provides the tools and capabilities you need to succeed.

Get Started

To learn more about Xojo 2024 Release 4 and begin your development journey, please visit the Xojo 2024r4 Release Notes. The update is available for download now from the Xojo downloads page.

What’s Next?

We’re continuously working on new features, updates, and enhancements to our platform. If you have any suggestions or ideas, please add them to the Xojo tracker. We’re always looking to improve and expand Xojo to better serve our community.

Thank you for being part of the Xojo community. We’re excited to see what you create with Xojo 2024r4!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

If there’s something you need to do in code when the orientation changes, you’re in luck. The MobileScreen class has an OrientationChanged event. When this event fires, that means the user has rotated their device and the orientation has changed. This is where your code would go should you need to respond to an orientation change.

Note: If you need to know when the screen has changed in size, that’s what the Resized event is for (at least on iOS – it’s not yet supported for Android).

What might not be immediately intuitive or obvious is that rotating your device does not automatically mean the orientation has changed. Consider the following example project that displays the Resized and OrientationChanged events in a table when they occur. While this is on iOS, it works the same way (without the Resized event) on Android. The device is starting in portrait mode.

We will focus on just the OrientationChanged events for now. It gets an initial OrientationChanged event. Then the user rotates their phone clockwise enough that the orientation is changed from portrait to landscape.

You can see that another OrientationChanged event has fired as you’d expect. Next the user rotates the phone clockwise again.

Now the phone is upside down. Notice, however, the orientation from the perspective of the OS has not changed. The layout is still in landscape orientation. This is not a bug. The device does not support portrait mode when the device is turned upside down. Thus the layout is still in landscape orientation and thus no OrientationChanged event has fired because there has been no orientation change.

Next the user rotates the phone clockwise yet again.

You might think that an OrientationChanged event would fire, but it doesn’t. Why not? Because as far as the OS is concerned, the layout is still in landscape orientation. It has not changed its orientation. Finally, the user rotates the device clockwise once last time.

This time the orientation has changed from landscape to portrait and thus the OrientationChanged event fired. Given that the initial OrientationChanged event fired when the app launched, out of the four 90 degree clockwise rotations, only two orientation changes occurred and thus only two OrientationChanged events fired.

This is one of those cases where what is initially intuitive turns out to be wrong until you look more closely at what is really going on.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• 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

Layout Editor

The Layout Editor has been enhanced with two settings that can adjust the layout.

The command bar has two toggle buttons. The first one already existed and it is for displaying the layout in portrait (the default) or landscape.

The new toggle button displays the layout in a phone size (the default) or a tablet size. When you switch between any of these toggles, the locking is applied to the controls on the layout.

The layout editor also remembers the selections so that the next time you visit the layout, it will be where you left it. Here you can see a landscape tablet layout:

Default Screen

The App Inspector has an additional Default Tablet Screen property. When your app is launched on a phone or tablet-sized device, the specified screen is what gets displayed.

You can also choose “None” for a default screen if you just want to share a single screen across both types of devices.

If you choose “None” for the Default Phone Screen, then the app won’t launch on a phone. If you choose “None” for a Default Tablet Screen, the app will launch on the tablet using the Default Phone Screen, which matches prior behavior.

Design Considerations

Xojo for Android uses locking to automatically adjust controls on the layout. Locking will work for certain types of layouts that you want to run on both phones and tablets, but may not be sufficient for more complex layouts. In these situations, you are better served by designing completely separate layouts for phone and tablet and then using the above Default Screen properties to show the correct one.

When you need to show additional screens, you can show the phone or tablet screen in code by checking the device using DeviceData.Orientation and DeviceData.UserInterfaceType.

If System.Device.UserInterfaceType = SystemDeviceData.UserInterfaceTypes.Tablet Then
  // Show tablet screen
  myTabletScreen.Show
Else
  // Show phone screen
  myPhoneScreen.Show
End If

When you have multiple screens, it often makes sense to put the UI in containers and then use the containers on the different screens.

You can run your apps on a Tablet emulator for testing (you can create one using Android Studio) or you can debug directly on device. I enabled on-device debugging for a Lenovo Tab M10 Plus 3rd Gen with these steps:

• Go to Settings.
• Select About tablet.
• Tap 7 times in a row on the build number. This enabled Developer options. You may be prompted to enter your PIN.
• Select System and then Developer Options.
• Turn on USB debugging and give it permission.

The tablet will now appear as a debug device in Xojo, allowing you to run your Android projects on it.

What about Chromebook?

Some Chromebooks are able to run Android apps and those that can are also able to run Xojo’s Android apps. Android apps can be installed via the Play Store (give CatsUp a try) or manually, although doing it manually is rather difficult (I have not yet gotten that working on my Chromebook). The Play Store options works well, however. Here’s CatsUp from the Play Store running on my Lenovo 300e Chromebook:

When run on the Chromebook, Android apps can have a size of Phone, Tablet or Resizable. You can see that as an option in the title bar of the above screenshot. For best results you probably want to design your apps for a landscape tablet.

Xojo for Android does not have direct support for Chromebook features at this time, but if there is something you’d like to see, be sure to create an Issue so that we can look into it.

Since Chromebooks are just (low-end) Linux machines at their core, they can technically run Xojo Linux apps (x86 or ARM depending on the Chromebook), but this usually requires some sort of additional Linux installation.

And of course, Chromebooks are typically meant to run web apps, which Xojo can also do quite well.

Eddie’s Electronics Example Project

The Android Eddie’s Electronics example project has been updated to run on both phones and tablets. It makes use of Containers to contain the UI and displays them using screens for the appropriate device type.

Here you can see the Customer screen for a tablet displays the list of customers on the left, with details and invoices on the right.

Compare that to the phone version which has you navigate between that information using separate screens.

Tablet supports opens up a whole other category of users for your Android apps and should be particularly useful to those making bespoke apps for clients.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This post describes the things you can do with Declares and Libraries with Android projects.

Declare Integer Types

The size-specific Integer types are now precise when used with Declares. The mappings are as follows:

When mapping to Android API functions or Library functions, be sure to use the correct Xojo type that matches what is expected on Android. By far you will use Int32 and Integer.

If you previously created Declares, you will likely need to change usage of Integer to Int32 as the mapping for that have changed compared to prior versions.

Nullable Types

Xojo object variables (also properties, parameters and return values) can be Nil. With Kotlin, the default is that these things cannot be null (the equivalent of Nil). To ensure that you don’t get compile errors with your parameters, declare them as nullable in Kotlin by appending the “?” to the end of the type name.

Application Context

Many Android APIs require the application context. This is not available in a Library so it has to be supplied by the app itself. There is a property for this:

MobileApplication.AndroidContextHandle As Ptr

You can pass this value to a function on the Library that then either saves it or uses it directly.

Using Ptr

Xojo uses the Ptr type to interface with Declares, however Kotlin does not have a Ptr type. Instead the Any type is used with Kotlin. This means that if you are passing something that is a Ptr to Kotlin (such as the app context above), your library function declaration should use “Any?” as the type of the parameter.

In your function, cast the parameter to the actual type you want. The same rule applies to return values. If the return value in the Declare is a Ptr, then in Kotlin the function declaration should be “Any?”.

You can also use Ptr with API calls to save object references as described below.

Library Permissions

Depending on the API you are using, you may need to add permissions to the app manifest.xml for the Library. These permissions also need to be applied to the main app. This can be done using the Advanced tab of the Android Build Settings. There you’ll find the Permissions property in the Inspector where you can add one Permission per line.

Previous versions let you separate permissions by spaces or commas. Going forward, each permission must be on its own line. Empty lines are ignored.

There you can add the permission constants that are required by your Library. In addition, you can follow the constant with additional attributes and they will also be applied to the app’s manifest file.

For example, to include the android:maxSdkVersion attribute with the BLUETOOTH permission:

android.permission.BLUETOOTH android:maxSdkVersion="30"

Library Dependencies

Similarly to permissions, your Library may make use of additional dependencies, which could even be other Libraries. These are added to the build.gradle file for the Library, but also need to be included in the main app.

You can add these dependencies using the Dependencies property on the Advanced Android Build Settings.

Creating Objects

Previous versions of Xojo only let you call Companion (essentially shared) methods on Library classes. Now you can also work with class instances and call instance methods. This gives you even better control and ability to interface with Android APIs.

To create an object, your Library class should have a factory method on the Companion that returns a new instance. It is clearest to use create() as this method name.

In Xojo you create a Declare to this create() method and call it, saving the result in a Ptr.

Declare Function create Lib "com.example.utility.counter" () As Ptr
Var counter As Ptr = create

Instead of using a shared factory method, you can also call the Class constructor using this syntax:

Declare Function counter Lib "com.example.utility.counter" () As Ptr

Because the function name has the same name as the class itself, this will call the constructor of the class.

When you want to call a method on the instance, you pass the instance as a Ptr. First, Declare to the method adding “.instance” to the library location to indicate you are calling a class instance.

Declare Function increment Lib "com.example.utility.counter.instance" (ref As Ptr) As Integer

Then you can call the method and save its value.

Var count As Integer = increment(counter)

The reference as the Ptr must be the first parameter passed in the Declare. Follow it with other parameters as usual.

You can also call instance methods directly in the Android API in this manner.

Method Callbacks

There are Android APIs that use callbacks to methods that you provide. In Xojo these methods are Delegates and are methods that you supply using AddressOf. It is very important that the signature of this method exactly matches what the callback expects which means you’ll be limited to just the Boolean and Ptr types.

If you want to use an API that uses its own callbacks, you’ll be better served by creating a Library and having the API do the callback to your own Library methods, which you can then call back to your Xojo methods.

You can pass the reference to the Xojo method using AddressOf like this:

Var cb As Ptr = AddressOf TestCallback
Declare Sub xojocallback Lib "com.example.utility.callback" (cb As Ptr)
xojocallback(cb)

The Xojo method can only use parameter types of Boolean and Ptr. It looks like this:

Public Sub TestCallback(b As Boolean, i As Ptr, s As Ptr)

In the Kotlin library you have to cast the incoming parameter to a function reference. This is a two-step process where you verify the function has the correct number of parameters and then you cast it to the specific parameter types. Sample code:

if (cb is Function3<*, *, *, *>) {
    try {
         (cb as Function3<Boolean, Long, String, Unit>).invoke(true, 42, "Hello")
         println("Sent callback to Xojo")
    } catch (e: ClassCastException) {
         println("Casting failed: ${e.message}")
    }
}

The “Function3” indicates a function with 3 parameters (the last “*” indicates the return type), but you can change that as needed using Function1, Function2, etc. You can pass anything back through a Ptr type, but the Xojo code has to convert them using Ptr methods so you should not change the types of the values you send back to be different than what your Xojo code expects.

Object Declares

Object Declares are not new, but for completeness are described here. Essentially an Object Declare uses special syntax to Declare to a UI control.

The typical way to use an Object Declare is by adding an Extends method to a Module. For example, an extension method to allow MobileButton to change its colors could look like this:

SetBackColor(Extends ctrl As MobileButton, c As Color)

The Object Declare looks like this:

Declare Sub setBackgroundColor Lib "Object:ctrl:MobileButton" (myColor As Int32)
setBackgroundColor(c.ToInteger)

Breaking this down, we’re calling the setBackgroundColor function. The Lib denotes this new type of Object declare: an Object, separated by a colon, the Xojo name of the object (in this case, our “ctrl” parameter), followed by another colon, and the Xojo type of the object.

Kotlin Declares

You can use the Android-specific “Kotlin” Declare designation to indicates that what is specified in the Alias section of the Declare should be used as is. This is particularly helpful when you want to cast Ptr values to a specific type for use with OS APIs.

This code gets a ColorStateList object for a Xojo Color value:

Var c As Color = Color.Blue

Declare Function valueOf Lib "android.content.res.ColorStateList:Kotlin" Alias _
"android.content.res.ColorStateList.valueOf(android.graphics.Color.argb(alpha.toInt(), r.toInt(), g.toInt(), b.toInt()))" _
(alpha As Int32, r As Int32, g As Int32, b As Int32) As Ptr

Var csl As Ptr = valueOf(255 - c.Alpha, c.Red, c.Green, c.Blue)

This code can then be used to call setStrokeColor on a MobileButton:

Declare Sub import Lib "android.content.res.ColorStateList:Import" // Imports the ColorStateList class

Declare Sub setStrokeColor Lib "Object:ctrl:MobileDateTimePicker:Kotlin" Alias "setStrokeColor(strokecolor as ColorStateList)" (strokeColor As Ptr)
setStrokeColor(csl)

As you can see, in the Alias is the Kotlin method call that casts the incoming Ptr value to a ColorStateList.

Import

Note the “import” declare in the code snippet above. This is also specific to Android. This Declare indicates that a specific class should be imported so that it can be used for casting purposes. If you left off that import, then the cast to ColorStateList would cause a compile error because ColorStateList would not be known.

You only need to import a specific class once. After you’ve done so it can be referenced by any other Declare, even ones in different methods.

The use of an import Declare is optional and is meant to simply the Kotlin method call code in the Alias. Instead of using import you can specify the full class path in the cast like this:

Declare Sub setStrokeColor Lib "Object:ctrl:MobileDateTimePicker:Kotlin" Alias "setStrokeColor(strokecolor as android.content.res.ColorStateList)" (strokeColor As Ptr)
setStrokeColor(csl)

Handles

Many classes in the framework now have Handle properties (or methods) which you can use with various Declare techniques described above. These include: FolderItem, Font, GraphicsPath, Locale, TimeZone, Graphics, Picture. In addition, the mobile controls have Handle properties that can serve as an alternative for an Object Declare.

Sample Project

You can download the sample project that demonstrates a library and some of the concepts described above. You can use this as a template or starting point for creating your own libraries or Declares.

Sample Utility Library Project

You might also want to take a look at the Android Design Extensions open source project, which has hundreds of Declares that can enhance your Android apps.

References

• Android Libraries blog post
• Android Declares blog post

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• 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

Although still in Beta, there have been many improvements to Android in the last few releases and in this post I’ll highlight a few things that have been added or improved starting with Xojo 2023r4 and through the recently released 2024r2.

Xojo 2023r4

The final release of 2023 had a lot of Android improvements.

You should always read the entire release notes, which have a wealth of details, but here are some highlights of useful new features that were added to Android in 2023r4:

• Added System.DismissKeyboard method that can be used to hide the virtual keyboard.
• The Ptr type can be used with Declares that call Kotlin Library projects. Other usage of Ptr will result in a compile error.
• There is a new constructor on Font that allows you to load a font file from a FolderItem. Easy custom fonts!
• The Barcode class can be used to scan a variety of barcodes.
• The NewAndroidProject command can be used with IDE scripting to create an Android project.
• MobileApplication.UnhandledException event now better captures the user runtime call stack for Stack() and StackFrame().
• There were many internal changes to the Android framework to get it to have better compatibility with other platforms.
• Improvements to URLConnection data encoding.
• Several JSONItem improvements.
• The Android compiler toolchain was updated to newer versions.
• Added Dependencies property to the Android advanced build settings. This can be used with Declares and Libraries to load any external dependencies they need. Put one dependency per line, an example would be: io.github.bitstorm:tinyzip-core:1.0.0
• Improved compatibility with Android 14.
• Many framework and compiler fixes.

Xojo 2024r1

The first release of 2024 continued the trend of rapid Android improvements.

• MobileApplication.Activated and Deactivating events now work on Android.
• Fixes and improves to several parts of the framework, including:
  • Introspection
  • SQLiteDatabase
  • JSONItem
  • URLConnection
• Many other framework and compiler fixes.

Don’t forgot to review the full release notes!

Xojo 2024r2

The latest Xojo release has plenty of improvements for Android. Some highlights include:

• MobileHTMLViewer field focus is now more reliable.
• TCPSocket is now available.
• Many Graphics properties are now available, including: ShadowBrush, LineCap, LineDash, LineDashOffset, LineJoin, Outline.
• Improved some compiler error messages.
• Many more framework and compiler fixes.

The full release notes are a fun summertime read.

What’s Next for Android?

As you all know by now, we don’t preannounce when things will appear in Xojo releases. We are continually working on adding features and improving Xojo for Android and when new things are ready, they appear in the next scheduled release. The best way to stay on top of what is going to be released soon is to help us with pre-release testing. Remember, if you have an active Xojo Pro license, you have access to a special pre-release section of the forum. If you have a Xojo Mobile license and woudl like to participate in testing please make a request.

With that said, some of the Android features in development include:

• ByRef support
• RegEx classes
• DatabaseConnection
• In-app purchasing support

Related Topics You Might Like

Android Design Extensions 2.5 for Xojo 2024r1

Android Improvements in Xojo 2023r3

Creating an Android Library with Kotlin for Use with Xojo

All Android related blog posts on the Xojo Blog

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The focus of this release was on the integration of pictures in controls, such as MobileButton, MobileDateTimePicker, MobileTextFields, MobileSlider etc.

Let’s take a look at some new possibilities using examples.

Create a MobileButton with a Picture

This is a feature that is in demand in Xojo Issue Tracker and has not yet found its way into the Android framework. So let’s just do it ourselves with the help of the Android Design Extensions.

Create a new Android project. Now copy the Android Design Extensions folder into the project or drag and drop it into the Navigator. Now select Screen1 in the Navigator and add a MobileButton – Button1 – and give it the Opening event. Add the following code to the Opening event:

Me.SetIconXC(SaveSystemImage("camera")) 
Me.SetIconGravityXC(IconGravity.TextStart)

SaveSystemImage is an extension method that returns a FolderItem and saves a Picture.SystemImage with the specified name (here „camera“) in the Documents folder. Why? Xojo Declares do not support Picture as a data type and therefore we have to take the detour and save images once in order to load them into controls via the file path.

You can of course also use any other image and are not restricted to Picture.SystemImage. All Android Design Extensions extension methods that have to do with the display of pictures are prepared for this and expect a FolderItem as a parameter, which must of course be a picture (PNG, JPEG etc.).

SetIconGravityXC ensures that the Picture is displayed in front of the button text. And that’s all there is to it. Execute the project and you have a button with an image.

Tip: If you create a MobileButton subclass, you can cache the FolderItem via Static to create the image file only once. Of course, this only applies to the fact that all button instances of this subclass should always display the same image.

To see how to add an image to a MobileScreen, MobileSlider or MobileSwitch, simply take a look at the Android Design Extensions sample app.

TabPanel Badge Extension

MobileTabPanel tabs now also support text badges. How is it done?

Add a MobileTabPanel – TabPanel1 – to your project and add the Opening event to it with the following code:

Me.SetBadgeTextAtXC(0, "Exclusive")

And that’s all there is to it. The result is as follows:

There are other MobileTabPanel extension methods with which you can customize the badges (color, position, etc.). Give it a try!

TextFields on a New Level

TextFields can also be enhanced with the new Android Design Extensions version.

The SetBoxCornerFamilyXC call now offers the option of choosing whether you want rounded or flattened corners. You can also use SetCursorColorXC to define the color of the cursor for each individual TextField.

TextFields can now also have leading or trailing icons. The helper methods for this are SetStartIconXC and SetEndIconXC, which in turn expect a FolderItem (Picture) as a parameter.

There are many other new declares. Have a look here too.

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 here.

Happy Coding.

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