Would you like to contribute to the Titanium docs? To get started, sign up for an account on the Appcelerator Wiki and sign our CLA.

Skip to end of metadata
Go to start of metadata
Contents

Overview

In the Titanium Mobile 1.8.0.1 Release, our Android support was significantly changed to support multiple Javascript runtimes (namely: V8 and Rhino). These changes affect various APIs that 3rd party modules depend on. Despite the changes to the platform, most of the internal module changes required are simply changes to method signatures and type names / import locations.

Manifest changes

All 3rd party modules that target Titanium Mobile 1.8.0.1 (and above) will need to have a new property in the module manifest, apiversion, with a value of 2:

If you create a new 3rd party module with Titanium Mobile 1.8.0.1, this property is automatically generated for your project. If you have an existing 3rd party module, you need to manually add this property to your manifest, and make sure you rebuild your module (see Build changes below for the NDK requirement):

Build changes

To accomodate the new V8 runtime, all 3rd party modules now require the Android NDK and gperf for building V8 bindings. Download and extract the latest NDK from Google here:
http://developer.android.com/sdk/ndk/index.html

To build your module, you need to set the ANDROID_NDK environment variable:

Alternatively, you can set the android.ndk property in build.properties:

The gperf command must also be installed and in your system path. The gperf command is installed as part of the Xcode development tools on OS X, but you may need to install it if you are developing on Windows. See: Installing gperf for more information.

You also need to update your build.properties file (and .classpath file if you are using Eclipse) to reference Titanium Mobile 1.8.0.1 and API level 8 or newer:

General changes

1. Remove TiContext.

  • TiContext is being replaced, and any implementation utilizing TiContext will take a performance / stability hit compared to using the desired API's directly.
  • In most of the places where TiContext is used as an argument, the TiContext argument can be removed entirely or replaced with an Activity reference.

Example:

becomes:

In the specific case of fromUrl, the following form can also be used:

The specific alternative varies based on which API point is being modified, but generally there is a very simple alternative that can be used.

2. Use KrollFunction instead of KrollCallback

  • KrollFunction has been added, and KrollCallback has been removed; The dual runtime change required a common interface to be defined to replace KrollCallback.
  • In most cases, a direct replacement of KrollCallback with KrollFunction should suffice.

Specific changes

Known compatibility points that need to be changed:

1. Remove KrollInvocation as a method argment.

Example:

becomes:

2. Remove TiContext from your module constructor. super(TiContext) will no longer work due to the previously mentioned TiContext change. In most if not all cases, simply removing the argument will address the problem.

Example:

becomes:

3. When replacing KrollCallback with KrollFunction, you need to to pass a KrollObject argument to the call and callAsync methods.

Example:

becomes:

4. Change getView() on a TiViewProxy to getOrCreateView()/

Example:

becomes:

5. Change TiDrawableReference.fromUrl(proxy.getTiContext(), tiImage) to TiDrawableReference.fromUrl(proxy.getActivity(), tiImage) due to the TiContext change. Same applies to all the "from<source>" methods in TiDrawableReference.

Example:

becomes:

6. <KrollInvocation>.getActivity() no longer exists. getActivity can be called on each proxy to get the activity for that proxy or TiApplication.getAppCurrentActivity() and TiApplication.getAppRootActivity() can be used for getting activity instances to work with. In general, system services, etc., can and should use the root activity if it exists. TiApplication.getRootOrCurrentActivity() will serve this purpose in the vast majority of situations.

Example:

becomes:

7. Calling addOnLifeCycleEvent on a module is no longer necessary. Modules are now automatically registered to receive the lifecycle events (onPause, onResume, onStart, onStop, and onDestroy).

8. <KrollEventManager>.addOnEventChangeListener() is no longer supported. The new mechanism for this is to override KrollProxy.eventListenerAdded, and move the code from the listenerAdded method into the overridden eventListenerAdded method after the call to super.eventListenerAdded.

Example:

9. resolveUrl has been moved to the proxy object.

Example:

becomes:

10. Change getModuleById to getModuleByName and specify the module name in the module constructor. By default the module cannot be found by calling getModuleByName. You must use the form of super() in the module constructor that allows you to specify the module name.

Example:

becomes:

11. <TiContext>.getAndroidContext() no longer exists. If the ContextWrapper returned originally is being used to access system or app level resources, use TiApplication.getInstance() or TiApplication.getInstance().getApplicationContext() instead. To get the ContextWrapper for the top most Activity, use TiApplication.getAppCurrentActivity() instead.

Example:

becomes:

12. getContext() on a TiProxy no longer exists because its purpose was to return a TiContext instance. This call should no longer be needed in module implementation once TiContext is no longer being passed in as an argument (the normal use case for this method).

Example:

becomes:

13. Remove context from TiFileFactory.createTitaniumFile.

Example:

becomes:

14. getChangeDir is now called on the TiApplication instance.

Example:

becomes:

15. Overriding the fireEvent method requires a change to the method signature. The argument has changed from a KrollDict class to an Object.

Example:

becomes:

16. <KrollInvocation>.getTiContext() no longer exists. TiContext is no longer needed. Some examples show this being used to get the TiApplication instance. TiApplication.getInstance() can be used instead.

17. Change usage of KrollDict in method signatures to HashMap. Dictionary values are now passed to methods as HashMap objects. If you need to access any of the KrollDict methods on the HashMap object you can create a KrollDict object from the HashMap object.

Example:

becomes:

18. runOnUiThread is no longer supported. You must explicitly manage and call your methods on the UI thread where necessary. Specifically, you can use the TiMessenger class to run code on the UI thread.

Example:

becomes: