Titanium Mobile 1.5.0, released in December 2010, brought with it several enhancements which extended the possibilities for your Titanium Android application to interact with other Android applications, whether or not those other applications are built with Titanium. Marshall Culpepper and Kevin Whinnery introduced you to a lot of that new functionality in a Titanium webinar in early January 2010. If you missed that, or if you’re just now starting to get interested in how to use Titanium to tap into native Android functionality, I highly recommend that you watch the video. Also study our API documentation for the Titanium.Android namespace.
In the webinar video, starting at about 26:00, Marshall shows a series of examples of opening external applications by starting their associated Activities. (He also does a great job of explaining Android terms such as “Activity” and “Intent” beginning at about 3:10, so if you don’t understand my use of the term “Activities”, then that’s another good reason to check out the video.) I’m not going to re-hash everything here, but as a quick reminder, here’s an excerpt of the part of Marshall’s test application which launches an activity associated with a third-party barcode image processing library called ZXing:
You can see in the code that Marshall uses an Intent to tell Android what action he wants to perform (“com.google.zxing.client.android.SCAN”) and to pass a string (the desired “SCAN_MODE”, which is “QR_SCAN_MODE”) to the Activity which will be launched to perform that action. He then passes that Intent to startActivityForResult, along with a function that will be called-back when the Activity finishes.
So in that example, Marshall only needed to put a string value into that Intent, and we supported that just fine in 1.5.0. But shortly after Titanium 1.5.0 and its quick successor, 1.5.1, were released, we — and several of you — realized that we were missing a key piece of functionality that prevented developers from taking advantage of Intents and startActivityForResult for a fairly common use-case: launching an Activity that does something with a “content URI“. An Android content URI is a URI generated by one of the many “content providers” on your Android device. There are content providers that manage your contacts as well as sound, video and image data. Each URI points to a specific “record” or set of records, a record being a database table entry which points to a piece of data such as an individual contact or a photo.
Our problem was that the Activities which make use of these content URIs expect the URIs to be passed to them in code as instances of Android’s Uri class, and not simply as their string representations (such as “content://contacts/people/3”). We had overlooked the need to provide a way for you to put true content URIs into the Intents that are passed to these Activities. We have remedied that in Titanium Mobile 1.6.0 with the new putExtraUri method of Titanium.Android.Intent, which lets you pass the string version of the URI but then converts it to a true Uri instance for you. Now you can finally take advantage of the parts of Android native functionality which use content providers and therefore require content URIs.
We’ll leave you with a Titanium example that uses the new putExtraUri method. This little app (it can be used as your complete app.js) makes a voice recording and shares it. In order to do the sharing, it needs to give the Intent the URI to the recording, so it calls putExtraUri:
Enjoy finding new ways to use Titanium to work with the many content providers available on Android devices.
Follow us on social