By Monte Goulding, published in revUp this week.

It probably comes as no surprise to most LiveCoders that I’ve been a little desperate for an Android Externals SDK for a while now. One of the most common pre-sale questions I field from mergExt customers is – do you have this for Android or that for Android. Up until this week I’ve had to say no, we can’t do that yet because RunRev haven’t released an SDK. Usually I cheekily ask them to harrass RunRev’s support team to help make it a higher priority (sorry Heather). It’s not just self interest though. I strongly believe that externals are a critical component of the platform enabling us to get the job done when the engine doesn’t cover a feature we need.

One of the great things for me about LiveCode going open source is I’ve been able to gain a much broader insight into how externals work by studying the api in the engine, RunRev’s externals and the lcidl compiler. For those that don’t know what the lcidl compiler is it’s an executable that reads in an interface definition file for the external and generates a C++ file that acts as a glue between the external implementation and the engine. One of the first things I noticed was it is quite easy to use the old externals SDK on iOS and Android for C or C++ externals. That’s how all of RunRev’s externals work cross platform and how mergJSON and mergMarkdown went cross platform. The problems start though when you want to access Android’s Java API.

We had some great discussions with Mark Waddingham, Mark Wieder and Jan Schenkel at RunRevLive 13 and on the Engine Contributors forum about how to implement the Java based externals, but things didn’t really start moving until Mark Waddingham implemented the core design of a support class, an implementation class and the JNI (Java Native Interface) glue binding it all to the engine. It was an exciting moment for me to test Mark’s demonstration external which consisted of the creation of a large button.

Say Hello to Android Externals… the first button

I immediately implemented a command lovingly named mergPopToast. A Toast on Android is a short message that is presented on screen for a few seconds before fading away.

Toasting the World

Having implemented my first command I wanted to get to work only to find that one of the most useful features in the iOS SDK, LCObjectPost, wasn’t fully implemented yet. You could post a message to an object but no parameters. So I went to work exploring JNI (something I hadn’t done before) and worked out how to do it. I submitted it to Mark and he promptly re-wrote it but I think my ideas helped a little bit… To test it all out I created mergStorageStartMonitoring which sends a callback (mergStorageStateChanged) whenever access to the sd card changes. I also added a function mergStoragePath to get the standard paths to the user’s public storage folders for good measure.

The next thing we needed was a way to start an Activity and get results back when it’s finished. Android applications are broken down to activities which can be thought of as cards with a specific feature. You start a new Activity with an Intent (to give it parameters for what it should do), when finished the user is returned to the Activity that started it with any results. The problem though was the engine’s Activity would handle all returns and not know what to do with the result from an Activity the external started. So we needed a way for the Java side of the engine and the Java side of the external to communicate directly. Starting the Activity and handing its result back to the external. When Mark commited an implementaton of an EngineAPI class I decided the perfect thing to test it on was barcode scanning by Intent (mergZXingGetBarcode). The function uses the Barcode Scanner or Barcode Scanner + app by Intent to scan. If the user doesn’t have the app it directs them to the Google Play store to get it.

Once I got into the swing of things I implemented a few more features. Android’s sharing Intent is functionally equivalent to the UIActivityController on iOS (with the exception of an annoying bug in the Facebook app) so I implemented mergPopActivity for Android using that. I also implemented mergAVPick to record and pick video from the media library. A client also required the ability to view a PDF so I implemented mergDocShowPreview to open a file in one of the user’s apps that supports it.

This collection of features is now known as mergAndroid and is currently available as a bonus to mergExt Complete users. The list of features will grow over time as people need things and eventually as the Android Externals SDK matures the goal is to merge these features into the iOS externals available in the suite and attempt to provide as near feature parity as we can.

It’s worth re-iterating that we definitely wouldn’t have mergAndroid yet if LiveCode wasn’t open source which has enabled us to have code level discussions and contributions in order to get something functional. A couple of people have asked how they might get started building Android externals. There isn’t any documentation just yet and eventually I hope to create some templates for setting up an IntelliJ IDEA project with an ant based build but in brief:

• checkout from this link, which is the most up to date until Mark merges my most recent pull request
• build the android engine (there’s a shell script in the tools folder)
• base your external on the sample revtestexternal in the repo
• build using the shell script that comes with revtestexternal

Read the rest of the newsletter here.