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

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

Positioning

First of all, the primary function of Position Locking in the IDE is to prevent accidentally moving controls that you’ve already placed on a Window or Container. For users with very complex layouts and layers of overlapping controls, this feature is a must.

In previous versions of the IDE when you lock a control’s layout position, it stays in that position no matter what, and while that sounds like the desired result, it does have some not-so-desirable side effects, the least of which is that the control no longer obeys runtime control locking. If you follow these steps in 2019r1.1, you get a very strange result:

1. Create a new Desktop Project.
2. In Window1, drag a Canvas control to the lower-right corner of the window.
3. Set the control locking in the inspector so that only the right and bottom sides are locked.
4. Right-click the control and select “Lock Position”
5. Resize the Window by dragging the lower-right handle

In 2019r1.1 and below, the Canvas acts like it’s locked on the top-left corner and stays at the same x and y position as when you locked it. If you do these same steps in 2019r2, the control now follows it’s runtime locking rules and stays with the lower-right corner of the Window. 

Alignment

The second issue we had was that Position Locking did not affect the alignment tools. Previously, if you selected one or more controls whose positions were locked, the alignment toolbar buttons were always enabled, but clicking them didn’t affect all locked controls. Instead, the IDE would figure out the outer bounds of all selected controls and move the unlocked controls to align with this boundary. This leads to unexpected results if one or more locked controls are selected because they don’t move. 

Starting in 2019r2, the rules for alignment have changed somewhat.

• The alignment controls are now only enabled if you have at most one locked control selected. 
• If no locked controls are selected, the IDE will align controls using the outer boundary of all selected controls as a guide, just like it did before.
• If a locked control is selected, the controls will be aligned to that control.

In an engineering meeting, I mentioned a discussion I had with a user about the speed of the Layout Editor and Travis said he had recently been reminded of how slow it was too. While most of the time issues in Xojo are carefully calculated and prioritized for maximum bang for the buck (as we say around here), that’s not always how it happens. After the meeting, Travis decided to dive into the Layout Editor code and see what could be done to speed it up.

The results are pretty remarkable.

The video below tells the story best.

The difference is greatest for layouts with a lot of controls.

To optimize for speed, we made two changes:

1. On all platforms, selecting and dragging controls now only re-renders those controls that are selected. A buffered image (picture) is taken with everything but the selected controls, and thus only the selected controls have to be drawn on top of that as they move. This is an improvement from before, where every control was re-rendered in every frame whether it was moving or not.
2. The second optimization is Mac-specific. Some controls take a long time for macOS to draw and composite. In particular, controls like Group Boxes in Dark Mode can take a while. We now keep a cached copy of the rendered control from the operating system, and use that unless its size or properties change. That way, we don’t need to wait for macOS to draw the control every time we want to display or move it on the screen.

If you have layouts with lots of controls, check out 2019r1. You’re in for a pleasant surprise.