Developing native Appcelerator modules – Part II – iOS module

Part II –  building a native Appcelerator module for iOS

Start by creating a new “Mobile Module Project.” To do this, right-click your Titanium App project in Appcelerator Studio, then select “New” and “Mobile Module Project.” Appcelerator will create an Xcode project for us.

Open the module project in Xcode and take a note that AppceleratorStudio created four Objective-C files: TiVkModuleAssets.h, TiVkModuleAssets.m and TiVkModule.h, TiVkModule.m. We won’t alter the automatically generated assets files. Some developers starting with Appcelerator modules development might get confused by Titanium documentation mentioning views and proxies necessary to implement visual elements. To make it clear, in our case, the module is only invoked through API methods. There are no buttons and/or similar. Hence, we won’t, at this time, make a use of these proxies/views.

In TiVkModule.h, we add the public properties and methods to the interface.

* TiVkModule.h
* Appcelerator module for social network VK
* Created by Diophant Technologies, OU
* Copyright (c) 2015 Diophant Technologies. All rights reserved.

#import “TiModule.h”
#import <VKSdk.h>
@interface TiVkModule : TiModule <VKSdkDelegate>
NSString *appid;
NSArray *permissions;
NSString *token;
NSString *user;

// VK permissions for public API
enum : NSUInteger
-(void) authorize:(id)sender;
-(void) deauthorize:(id)sender;
-(void) makeAPICall:(id)args;

Appcelerator Studio generated two important methods – moduleGUID and moduleId. Let’s keep those without altering. Add barebone public methods to TiVkModule.m and start building out the functionality. According to VK developer documentation, our module has to implement <VKSdkDelegate>. Take a note how our TiVkModule.h reflects this. It is also important to remember that although JavaScript methods authorize() and deauthorize() have no arguments, we need to declare Objective-C module methods with (id) argument.

The most important method is authorize. Let’s quickly code the initial implementation.

* JS example:
* var vk = require(‘ti.vk’);
* vk.appid = ‘1234567’;
* vk.permissions = [
* ];
* vk.authorize();
-(void) authorize:(id)sender
// we can only authorize for a specific app
if (nil == appid)
[self throwException:@”missing appid” subreason:nil location:CODELOCATION];

[VKSdk initializeWithDelegate:self andAppId:appid];
NSNotificationCenter * nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self selector:@selector(activateApp:) name:UIApplicationDidBecomeActiveNotification object:nil];
if (![VKSdk wakeUpSession])
[VKSdk authorize:SCOPE revokeAccess:YES];
} else {
// Have a token?
if (![[VKSdk getAccessToken] isExpired])
NSMutableDictionary *event = [NSMutableDictionary dictionaryWithObjectsAndKeys:
token = [[VKSdk getAccessToken] accessToken];
[self fireEvent:@”login” withObject:event];
}, NO);

Let’s also implement more authorize methods with appropriate signatures as below.
– (void) authorizeForceOAuth:(id)sender
[VKSdk authorize:SCOPE revokeAccess:YES forceOAuth:YES];

Now, we can finish implementing <VKSdkDelegate> methods, like the below.
// called when authorization succeeded
– (void) vkSdkReceivedNewToken:(VKAccessToken*) newToken
NSMutableDictionary *event = [NSMutableDictionary dictionaryWithObjectsAndKeys:
token = [newToken accessToken];
[self fireEvent:@”login” withObject:event];

Once we implemented all methods, let’s ensure that module.xcconfig includes a reference to the utilized VKSdk.framework framework so we could build our module with the Appcelerator Studio generated script.

Add the newly created module to your Appcelerator project from Help->Install Mobile Module… and adjust tiapp.xml.

The last step is to replace the require statement and we can use the brand new ti.vk native iOS module in our app.


We can now utilize the native iOS VK module to build Appcelerator apps. In the next installment, we will learn how to make our module work on Android.

Please follow and like us:

Developing native Appcelerator modules – Part I

A possibility of using native modules along with JavaScript is one of the reasons Appcelerator is selected for many projects. Modules narrow the gap between native and cross-platform development approaches. Sometimes, native modules are the only way to make your Appcelerator app do what is required.

Programming native Appcelerator modules is not difficult. At the same time, we felt that even with existing tutorials, the first time developers could use another detailed walk-through, based on a real project.

Enjoy the three-part blog post covering in detail implementation of a native Appcelerator module for the social network VKontakte, based on the VK SDK for iOS and Android.


Part I –  Designing native Appcelerator modules for VK

Why/when is a native plugin necessary? In every situation the answer in different. In our case, the app was originally made with a JavaScript module. We found a free barebone JavaScript Titanium module called ti.vkontakte on GitHub and within a couple of hours extended it with the additional functionality that we needed. The resulting module correctly worked on all supported platforms. The problem was that users were complaining about having to enter username and password via VK web authentication, instead of authorizing through the standalone VK app. In fact, we discovered that majority of end-users often do not remember their credentials. A native plugin would allow users to interact with the VK social network using a session already running on the VK app. There would be no need to enter credentials separately.

Our extended ti.vkontakte JavaScript Appcelerator module supported methods: authorize(), deauthorize(), makeAPICall(), exposed properties: appid, permissions, token and user, plus the JavaScript plugin generated various events. We were happy with JavaScript module’s API. Our goal is to rewrite the VK module in the native code, supporting one platform at a time. We decided to reimplement the JavaScript vkontakte module API keeping all signatures. This way, we would get away with only one conditional JavaScript statement to utilize native modules where available.

Further, we found a working Appcelerator module with similar functionality – ti.facebook developed for the same purpose as our module, except for Facebook. In this tutorial, we will create a new module named ti.vk based on the JavaScript module’s API, VK SDK for Android and iOS, as well as the ti.facebook Appcelerator module.

Before we begin coding the native VK module, let’s prepare by configuring VK SDK. We already had made a standalone VK app used to authorize with JavaScript. To authorize through SDK, VK requires that developers configure the app bundle field of the standalone app. The last configuration task is to setup our app’s URL-schema. We add the below section to the tiapp.xml file.


For more information about developing for VK, see the relevant developer documentation. In the meantime, we are ready to start coding our iOS and Android native Appcelerator modules. To be continued in Part II.

Please follow and like us:

Xamarin.Android Performance Analysis

Ever wondered how Xamarin.Android performance stacks against code written in Java? We did.

As an introduction, let’s refresh Xamarin.Android architecture. While on Apple iOS Xamarin code is compiled into native code, on Android things work differently. Xamarin code runs inside a VM which works side-by-side with Java VM running Dalvik code. Hence, since Xamarin does not need to go through JVM, it could in theory work as quickly as even faster than Java. In reality, Xamarin apps will be larger than Java apps, since there is a need to bundle the Xamarin runtime.

  • Let’s examine overhead of Xamarin runtime. In order to do this, we built a simple “Hello World!” app. The app size is under 2 MB.
  • Startup time for native Java apps is better than for Xamarin. While a small Java application starts almost immediately, our Xamarin app takes a second.
  • Integer and floating multiplication written in Java are about 20% quicker.
  • Operations with collections are almost 10 times faster on Xamarin than on Java, because Java lacks struct value type.
  • String manipulations under Xamarin are about four (4) times faster than code written in Android-native Java.
Please follow and like us:

Crossplatform Mobile App development with Xamarin

Now that Microsoft put its’ weight behind cross-platform C# development for Android and iOS with Visual Studio 2015, it makes even more sense to take a look at Xamarin.

Xamarin interacts with iOS and Android platforms via proxy libraries MonoTouch and Mono.Android.


  • Crossplatform – Multiplatform support is provided by standard Mono/.NET libraries – System.Data, System.IO, System.Net etc.
  • Xamarin apps run Android, iOS and Windows.
  • Visual Interface Designer- InterfaceBuilder and Visual Studio add-on allow visually designing UI.
  • C# – Developers familiar with C# can build apps suitable for AppStore distribution without having to learn Objective-C or Java.


  • Memory Leaks – Most classes implement IDisposable interface and memory leaks are a serious concern. Elements are often proxies to native objects and Dispose it required to memory leakage.
  • Exceptions – While Xamarin throws exceptions such by raising MonoTouch.Foundation.MonoTouchException and Java.Lang.Throwable, yet some exceptions only happen inside framework and never get to the app. Stack overflow, for example, crashes the app without even raising any exceptions.
  • Some native API calls are not supported. For example, MonoTouch.AddressBook.ABPerson.GetVCards is missing. Xamarin.Android does not generate events AnimationStart and AnimationEnd for ViewFlipper.
  • Support – there is a lot more information and help available for native development.

The shortcomings of Xamarin are manageable, but in some instances developers have to be ready to hack the Xamarin platform or engage a consultant to help with topical issues.
If you are planning to develop an app for just one platform, it probably makes sense to stay native, even if it requires learning a new platform.

Please follow and like us:

Crossplatform Mobile App development with Appcelerator Titanium

We would like to share lessons with learned from our experience developing mobile apps with Appcelerator Titanium. This information might be helpful to anyone selecting development tools for a new mobile app.


  • JavaScript – an ability to code in JavaScript then run an app on multiple platforms including Apple iOS and Google Android allows developers familiar with web technologies to develop apps without having to learn native iOS and Android programming languages and tools.
  • Rapid development – prototypes can be developed quickly with little code in JavaScript.
  • Same sources work on multiple platforms – the same Titanium JavaScript code, with little optional minimal variants, runs on multiple mobile platforms including: iOS, Android, Blackberry and now Windows.
  • Community – large developer community with active forums and a marketplace with a multitude of modules extending built-in functionality.


  • Double-clicking – An app developed on a native platform normally disables the element that generated an event while one is being processed. For example, a user presses on a button and while the app does what is necessary, the button becomes greyed. Appcelerator Titanium can send multiple events, which may be undesirable. Think of a user sending the same chat text multiple times.
  • Android memory management – Android memory management is a challenge even for native apps. An app will often receive only 16 MB of memory. Since each pixel is represented by four (4) bytes, one picture full-screen image with a resolution of 480×800 will take 1.5 MB. Given this reality, developers commonly have to monitor activity service for resource availability and exceptions to prevent apps from exhausting memory. Titanium does not provide this information to the app, and there is no simple way of getting it. In addition, Titanium has problems with memory leaks, which can be mitigated to a degree.
  • Conditional code for each platform – both API and screen resolutions require that developers create a variable or a function set to the platform and constantly include lines similar to the below:

    if(‘iPhone’) >= 0)
        isIPhone = true;
        isAndroid = false;


   var fontSize = hookup_utils.isAndroid() ? “6pt” : “10pt”;


    if (hookup_utils.isAndroid()) {
        winParam.exitOnClose = true;

  • Lag behind native tools – Apple releases RC versions several months to releasing the OS to the end-users. This allows developers using native tools to submit apps for an approval in time for general availability. Titanium lags few months behind native tools and usually these no way to coordinate release with Apple. Depending on the marketing strategy, this can seriously impair your ability to piggy-back off Apple marketing campaign.
  • Bugs – Each Titanium release addresses some of the known bugs, yet comes with its’ own set of new problems. Since Appcelerator sits above the native platform, all of these bugs are in addition to iOS and Android bugs. For example, Titanium version 3.1.3 caused a significant regression with animations.


The above problems are solvable. Depending on technical requirements and developers’ experience, Titanium can be a great platform. The important part is to make an educated decision so that benefits clearly outweigh challenges.

Please follow and like us: