To create an Android library you will need to use Android Studio, which you should already have installed as its compiler toolchain and SDK are required by Xojo.

Create a New Android project (File->New->New Project), choosing “No Activity” from the Phone and Tablet section.

You should be sure to choose Kotlin as the language and the Minimum SDK should be 26 to match what Xojo uses. For this example, I’ve named the project “LibraryTest”.

In this project, add a module (File->New->New Module), choosing the “Android Library” template. Here you can name your library, choose the language, etc. Again, stick with Kotlin.

I’m naming the library “utility” so that it can contain a random collection of things.

In the Android Studio navigator, expand the utility library and then the java folder. Yes, it is weird that Kotlin code is in a Java folder, but a lot about Android Studio is weird to me.

Right-click on “com.example.utility” and select New->Kotlin Class/File. In the selector, choose “Class” and type the name of the class as “regex” and press return. In this class will be a method to do some simple regex pattern matching.

This creates an empty class:

package com.example.utility
class regex {

}

Currently Xojo can only talk to methods in the companion class. These methods are similar to Shared methods in Xojo and work without creating a specific class instance.

In the class, add the companion object so that it looks like this:

package com.example.utility

class regex {

    companion object {

    }

}

Inside the companion object, add a method that will do simple regex pattern matching. Your code now looks like this:

package com.example.utility

class regex {

    companion object {

        fun regexmatch(regex: String, text: String): Boolean {

            // Use the regex pattern
            val pattern = Regex(regex)

            // Returns true if it matches, false if it does not.
            return pattern.matches(text)
        }

    }

}

The last step is to change the Kotlin version to match the version Xojo uses. In the Android Studio navigator, open Gradle Scripts and double-click “build.gradle (Project: LibraryTest)” to open it.

Change the last line with the kotlin.android version from whatever is there to “1.6.20”:

// Top-level build file where you can add configuration options common to all sub-projects/modules.

plugins {
    id 'com.android.application' version '8.0.2' apply false
    id 'com.android.library' version '8.0.2' apply false
    id 'org.jetbrains.kotlin.android' version '1.6.20' apply false
}

Note: You may be prompted to do a Gradle sync after making this change. Go ahead and do the sync if prompted.

The last thing to do in Android Studio is to build the library. From the Build menu, choose “Select Build Variant”. In the Build Variants panel that appears, click on the Active Build Variant value for the utility row and change it from debug to release.

Select Build->Rebuild Project to build the library file that Xojo will use.

In your file system, go to your project’s location and fine the aar file, which is located here: LibraryTest/utility/build/outputs/aar/utility-release.aar Make a note of this as we will be using it with Xojo in a moment.

Speaking of Xojo, create a new Xojo Android project and name it LibraryTest. Add a button and a table like so:

In the button’s pressed event, write the Declare statements to call the regexmatch method in the library, passing it a regex pattern and a string to test. Here is the code, which tests three strings and outputs the result to the table:

Declare Function regexmatch Lib "com.example.utility.regex" (pattern As CString, value As CString) As Boolean

// Look for g, followed by any number of "ee" pairs and ending with ks
Var pattern As String = "g([ee]+)ks?"
Var result As Boolean
Var values() As String = Array("geeks", "geeeeeeeeeeks", "geeksforgeeks")

For Each v As String In values
  result = regexmatch(pattern, v)
  Table1.AddRow(v, result.ToString)
Next

// From: https://www.geeksforgeeks.org/kotlin-regular-expression/

The important thing to note in this code is the use of CString in place of String, a requirement when working with a Declare even if it doesn’t directly apply to Android.

Also note that you need to provide the full path to the class. You have to use “com.example.utility.regex”, not just “regex”.

The next step is to add the Library to the Xojo project. Select Android in the Build Settings and add a Copy Files Build Step (Insert->Build Step->Copy Files).

Expand Android and click on CopyFiles1. Rename it to LibCopy and drag it so that it is before the Build entry. Change the Destination to “Framework Folder”.

Add the library that we built with Android Studio to this LibCopy step. Click “+” in the command bar and locate utility-release.aar.

Note: If you still have Android Studio open at this point, you should close it, otherwise it will lock debugger access and prevent the Xojo app from starting.

Pro Tip: You can keep Android Studio open and run from Xojo by choosing this preference setting: Build, Execution, Deployment -> Debugger -> Use existing manually managed server. You’ll want to set it back to “Automatically start and manage the server” if you use Android Studio for anything else. Constantly flipping that setting is common when working with Android libraries.

Run the project. If you did everything correctly, it should launch on your device or emulator. Click the button to see the output which should look like this:

With libraries you can add your own extensions to Xojo’s Android support. You are limited to simple types at the moment, but that still opens up a lot of capabilities. This capability will continue to be expanded through the Android beta.

Feel free to share any Kotlin libraries you create in the Android topic of the forum.

Download this Example RegEx Library

Here is another simple Library you can download and examine.

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.

In this series of blog posts, I will cover the sixteen sample projects I created for that session (JSONReader, Mastodon, DisplayDB, DrawCards, with separate versions for desktop, web, iOS and Android) in more detail.

You can watch the presentation on YouTube:

The accompanying hands-on session might also be interesting, where I show the projects running on Android:

You can also download all the sample projects. 

The first project is JSONReader, so let’s dive in.

JSONReader

This sample demonstrates a couple classes that can read some specifically formatted JSON. I generated this “mock” JSON data using Mockaroo.

The two classes are Staff and StaffDetail. The Staff class contains the JSON data as a constant for simplicity, but it could load it from anywhere, such as a file or from the web. These classes use standard Xojo framework code and are fully compatible with desktop, web, iOS and Android projects.

On Staff are three methods which are used to fetch information from the JSON: Everyone(), GetNames() and GetSlogans().

Each of these methods are similar in that they loop through the items in the JSON like so:

FOR pos As Integer = 0 To JSONData.Count - 1

The simplest method is GetNames() which just fetches the first and last name from the JSON and combines them into a single string. It then returns all of these names as a string array.

GetSlogans() is similar, but it instead fetches the Slogan field from the JSON, returning them all as a string array.

The Everyone() method makes use of the StaffDetail class which is just a storage class with properties for each field in the JSON. It also loops through the JSON, but grabs each value and puts it into a StaffDetail instance. All of these are collected into an array and returned.

Although this design is simple, it demonstrates how to separate processing code from the UI. Because everything related to JSON is hidden in these classes and returned as arrays, the UI code (which will be different between platforms) only has to deal with arrays and not with how they were created. You can copy and use the classes as needed in whatever project types you are creating.

For the desktop app, the Window has three buttons which display the results of the above methods in a ListBox.

For example, the NamesButton has this code in its Pressed event:

DataList.RemoveAllRows
Var allStaff As New Staff
Var names() As String = allStaff.GetNames

For Each name As String In names
  DataList.AddRow(name)
Next

The SloganButton is similar. The AllButton code only differs by having an array of StaffDetail:

DataList.RemoveAllRows
Var allStaff As New Staff
Var everyone() As StaffDetail = allStaff.Everyone

For Each detail As StaffDetail In everyone
  DataList.AddRow(detail.FirstName + " works on " + detail.Slogan + ".")
Next

When you look at the projects, notice that the code for the WebPage, iOS Screen and Android Screen buttons is exactly the same as the code for the desktop Window buttons!

That won’t always be the case, of course, but it is a good first start and demonstrates how similar the UI API is across platforms.

In my next post, I will look at the Mastodon sample projects which make use of URLConnection.

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.

We continue to make progress on all aspects of Android support which includes:

• Code generation work to make sure your Xojo code performs as you expect with the Android virtual machine
• Controls with names, properties, and events that match iOS as closely as possible
• The debugging experience
• Removing external dependencies where possible, so you hit the ground running

Right now we have many of the UI controls working, much of the Xojo language and more than 30 example projects to help with testing. As you may already know, we are creating native Android apps using native Android controls and targeting Android 5.0 (Lollipop, API 21) and higher.

To give you a feel for this, here is a look at the Android version our Eddie’s Electronics sample project.

This should all look pretty familiar, especially if you’ve worked with iOS projects. And speaking of familiar, this is what some of the code looks like:

We even have the ability to run this project in both the Android Emulator and on a physical Android device. Here is Eddie’s Electronics running on the Android Emulator (Pixel 4 emulation):

As you can see, there is still more to do, but many things have been completed. We look forward to beginning the testing phase once we feel like testers can have a good experience with the items noted above. We cannot commit to timelines, but we are thrilled with the incredible interest we’ve seen! Rest assured that we are as excited as you to have Android support in Xojo and are working hard to deliver it.

Though we have made a lot of progress since our last demo in April, we still have some items left to complete, including adding Debugger support and completing the IDE integration.

After we ship our initial release of Android, we have a few things planned. We will be updating the iOS Framework to API 2.0 and adding auto-layout to Android. In addition, we plan to have a single mobile project for both Android and iOS, so just as you select your target OS on the desktop today, you’ll be able to do the same on mobile – Android or iOS.

The conference attendees were very excited to see the latest update, the mobile future on Xojo is bright! Stay tuned for more news and announcements.

**Xojo Android is not currently in beta and we have not yet announced a ship date.

In fact, Xojo lets you easily cross-compile desktop apps for Windows, macOS, Linux and Raspberry Pi. Plus, you can use the same Xojo language to create web and iOS apps too (Android coming soon!).

How does it work?

Xojo always builds your apps as native executables for your platform. There are no virtual machines and no interpreted code. And Xojo uses mostly native controls so that your apps have the look and feel that your users expect on each of those platforms.

You simply check the box next to the target platforms you want and click the Build button. Xojo does the rest.

Xojo has been around since 1998 offering the ability to create Mac apps, over the years adding the ability to create Windows, Linux, iOS, web and Raspberry Pi apps – and we’re currently working towards Android support!

Develop on Your Favorite OS

The Xojo IDE itself is written in Xojo. This means it is cross-platform itself, so you can use Windows, macOS or Linux as your development platform. Because Xojo makes things easy, you are able to build for any platform from any platform (with the exception of iOS which requires a Mac for development).

Installing Xojo is Painless

Unlike other tools that have a complex installation process with lots of dependencies, installing Xojo is simple and quick with nothing else to worry about. You’ll be able to download and install Xojo and probably have your first simple app made before other tools even finish installing.

Easy to Start, Fast to Develop

Use drag and drop to design your user interface and write your code within Xojo using its powerful code editor with auto-complete.

You also don’t have to learn the specific OS programming APIs. Xojo abstracts you from complex OS details allowing you to easily create apps for multiple platforms without extra work.

Learn and Develop for Free

Even better, it costs you nothing to get started with Xojo. You can download Xojo for free and start using it to develop apps. You can make your first app in minutes, check out these 2 minutes videos showing you how for Mac, Windows and Linux apps! Learn to code with Xojo – develop, run and test your apps all before buying a license. Purchase when you are ready to compile your app so you can share it with the world.

64-bit support, for example, has been a major focus and continues to be. At one time, 64-bit was a nice-to-have. Then it became important and now it’s critical. There are Linux distributions that no longer provide 32-bit support. iOS now requires apps to be compiled to 64-bit in order to be in the App Store. You might have noticed that the 2017r2 cycle was longer than usual. This was due to the fact that we were doing some major refactoring of how strings are handled under 64-bit. Some of the string functions you depend on were not always behaving themselves and were much slower than they were in 32-bit applications. That refactoring took twice as long as we’d originally planned. That’s just the way things go sometimes. Even companies such as Microsoft and Apple have announced features that were later delayed. We’ve all been there.

We are also working to provide a 64-bit version of the Xojo IDE. This is important for those you of with large projects because the current 32-bit IDE can only address so much memory. Once your project gets big enough, the IDE can run out of memory even though your computer has plenty to spare. We need this ourselves because the Xojo IDE is written in Xojo and as you can probably imagine, is a very big project. 64-bit applications can address all of the memory your computer (or any future computer you own) will ever have. A 64-bit version of the IDE will permanently resolve this issue.

Sometimes the platform vendors make changes that require us to rearrange things a bit in the short term. For example, our first 64-bit platform was going to be Linux until Apple announced the 64-bit requirement for iOS apps to be in the iOS App Store far earlier than expected. Recently, Apple made it clear that under iOS 11 the Xcode 9 version of the iOS Simulator would not support 32-bit apps or debugging. We had originally planned to support 64-bit iOS Simulator debugging in 2018. Instead we are working hard and fast on that right now.

As a result of all this, some of our plans have been pushed out a bit. We had originally aimed to have Android, interops and plugins made with Xojo available for beta testing by the end of this calendar year. Now that’s not going to happen. We are still working quite hard on all these things (and more) but the 64-bit work has just waylaid us a bit. It is our intention, barring any additional unforeseen circumstances, to ship these features in the first half of 2018.

Fortunately, not all things have been delayed. We are working on a big update to the Windows framework that will dramatically reduce the flicker you sometimes see. This will not just improve the user experience of your apps but the Windows version of the Xojo IDE as well. Those of you that deploy to Windows or use Xojo itself on Windows will be quite pleased. I’m confident we will have these improvements available by year end.

If you want to help us with testing 64-bit Xojo or the updated Windows framework this year, please join our Pre-Release Testing Program.

For those of you that have been participating in pre-release testing, thank you so much. You are providing a valuable service to us and the Xojo community at large.

This can have a significant impact on developers. The development and testing surface a developer must deal with is potentially as large as the number of OS versions they will support multiplied by the number of devices. On the iOS side, developers can often choose to only support the latest version of iOS because within a few months, most iOS users are running the latest version. There are really only 5 to a maximum of 8 iPhones and perhaps 4 iPads. That means 12 devices times a single OS version.

If a developer is going to support 80% of Android users, they have to go back to Android version 4 (Ice Cream Sandwich released in 2011) which means they have at least 4 but as many as 6 versions of Android to support multiplied by more than 50 devices that have been released since 2011. I’ve heard that it’s not unusual for Android developers to only test on the two latest Samsung phones. While that makes it easier on them, it virtually guarantees that the quality of software on Android is going to be reduced. How much would be difficult to quantify of course. Having said that, Google does not add new features to Android at anything like the rate at which Apple adds features to iOS. This is probably why developers can get away with a more limited development/testing surface on Android. Unfortunately, this leaves that judgement call up to the developer.

This could be made easier on developers if the Android market solidifies around a few devices. It could be argued that such solidification is already happening around Samsung. Despite Android having 80% of the smartphone market share, only one Android phone maker, Samsung, makes a profit. Every other Android phone maker loses money. Apple, on the other hand, is the only iOS device maker. Depending on the quarter, Apple makes between 75 and 90% of the profit in the smartphone industry with Samsung making the rest. That too is telling. It suggests that the Android market almost certainly will continue to solidify, almost certainly around Samsung.

As a maker of development tools, we at Xojo, Inc., support many platforms: macOS, Windows, Linux, the web, Raspberry Pi and iOS. We absolutely plan to support Android as well. We have not kept that a secret. We know there are many Xojo users that are anxious for us to make that available. We’ve been carefully studying the Android platform, from the market down to the APIs, to make sure that we can offer the best solution for developing cross-platform mobile applications. While it’s no fun to have to wait, sometimes waiting and entering a market at just the right moment, makes it easier to provide a quality development tool that will make it easier for developers to develop and test quality software. We are your partner in this and want to be the best partner we can be.

Update: September 28th, 2016: Just 15 days after release, iOS 10 today has overtaken iOS 9 to become the most popular version of iOS.

If your app is a commercial app that will be available to the general public via an app store or through ad-based revenue, iOS is the platform of choice. It is well-documented that iOS users spend more money on apps in app stores as well view more ads. But you can still make money selling apps to Android users, right? Maybe. The cost of developing apps for Android is 2x to 3x higher than iOS for a multitude of reasons not the least of which are the number of devices and OS versions upon which you must test. So from a commercial software perspective, it could easily be argued that there is more profit in developing for iOS than for Android. There are of course exceptions to this rule. For example, if your app’s success depends on social networking (like WhatsApp, Instagram, Snapchat), then you really need to support all the popular platforms. However, that’s a tiny fraction of applications. If profit is your motive, you might want to consider ignoring Android entirely, at least for now.

But while commercial apps are the most visible, they are not the only kind of apps created for mobile devices. More and more apps are being created for internal use inside companies which can make the platform decision far more challenging. In this day of BYOD (Bring Your Own Device), the mobile landscape where you work is likely to be far different from the profit-centered commercial landscape. Your company may need to support multiple Android devices as well as various iOS releases to help your employees get their jobs done while on the move.

This is where web-mobile apps become a great solution. Web-mobile apps can run on just about any reasonably new mobile device and are easy to deploy to the user since they are accessed via the browser. Most workplace apps connect to some kind of server (usually a database) anyway so requiring connectivity is usually not a problem. However, developing web and web-mobile apps with traditional tools (HTML, JavaScript, CSS, PHP and AJAX) can be extremely time-consuming even for those that have the word “developer” or “engineer” in their job title. Xojo’s web framework abstracts you from all these details so you can drag and drop to create your interface and focus your code on what makes your application unique. This makes developing apps at least 5x faster than with the traditional tools, plus you can get up to speed a lot faster. If you don’t have lots of free time to learn 5 different technologies, Xojo is a tool you need to seriously consider.

A common downside to web and web-mobile apps is the difficulty of deploying the app. I’m not talking about the difficult of deploying to the end users- that’s actually really easy since they can just go to a URL in their mobile browser. But web apps run on a server and that usually comes with a whole new set of challenges. You need to learn how to set-up and configure a web server. And you need to consider security, which can be more challenging and time-consuming than developing the app itself. We have all seen the headlines about companies like Sony, Target and Adobe being hacked. And those are just the ones that make the headlines, lots of small companies get hacked everyday. So server security is extremely important though often ignored because of the complexity involved.

Xojo Cloud solves this problem for you. First, because Xojo makes the development tool and the deployment platform we have tightly integrated the two to provide zero configuration and one-click deployment. Secondly, because all Xojo Cloud servers are identical, they provide industrial-strength security that would otherwise be prohibitively expensive for individual businesses.

If you are creating commercial mobile software, you are probably better off focusing your effort on iOS rather than Android. However, if you are creating apps for internal use at your company, web-mobile apps are likely the way to go. Xojo (which supports the desktop as well) and Xojo Cloud provide a great solution. If you need to develop native iOS apps, start learning Xojo now because support for iOS is coming later this year. (Xojo iOS is here!)

Are you planning on building commercial apps or apps for internal use at your company? Add a coment and let me know.