With the recent addition of our free Indie Plans for both Titanium and Hyperloop, we’ve seen an influx of new developers join the Appcelerator community. So, we wanted to create a resource for users to troubleshoot their most common development issues and questions for each platform. To kick-off our series, we took a look some of the most common support questions for Android development.
In this post, we’ll be linking off to existing posts, articles, and guides. We’ll update it based on feedback and suggestions from you, so please leave a comment below.
Q: How do I use the working NDK version to create and compile Android modules?
A: In order to create Android modules, you’ll need to install Java support inside both Appcelerator Studio and, of course, the Android NDK. Android NDK is a set of tools that allows you to write native code you can re-use in your application.
After downloading the Android NDK, you can start creating new modules by running through the Axway Appcelerator Studio New Project Wizard.
- Open File > New > Mobile Module Project.
- Choose a project name, a module ID, and a deployment target (native platform).
- Click Next.
- Fill out the remainder of the items on the next page.
- Click Finish.
If you’re using the Appcelerator or Titanium CLI, you can use the appc new or ti new command and select Titanium Module and follow the instructions to fill in the project name, module ID etc.
If you encounter build errors, such as your Android application project path containing spaces or the Android NDK property is not set, then check out this guide on creating a new Titanium module.
Q: What are some best practices for numbering updated versions of my apps so they comply with Google Play Store rules?
A: Versioning builds and releases for your app may not sound like the most complicated concept, but failure to understand the app store rules around versioning could lead to frustration as you try to figure out why Google Play won’t accept your uploaded files.
The good news is that once you know the structure, versioning different builds is very simple — you can even write command-line scripts to auto-update them when rebuilding your projects.
Most developers run into issues when it comes to preparing their app for submission to the Play Store. Android apps actually have two version numbers — the first is the the visible version number that is displayed in the Google Play Store, for example, 1.0.0.
The second is the version code — this is an internal version number that the Play Store checks when uploading a new Android build — the default for new apps is 1.
This use of two version numbers means it’s possible to submit an app with the same number of 1.0.0 (maybe for a pre-launch bug fix) and just increment the internal version code. As long as the new version code is unique and higher than the previous one, the Android Package Kit (APK) will be accepted as valid and your app will remain in the Play Store as version 1.0.0.
You specify both version numbers in the TiApp.xml file:
<manifest android:versionCode="1" android:versionName="1.0.0">
If you want to learn more about versioning, check out this post.
Q: How do I know if the Android SDKs are correct?
A: Titanium requires Android SDK Tools to be installed in order to allow you to develop applications for the platform. Well, the Studio Platform Configuration Tool makes it easy for developers to identify, install, configure and update native platform SDKs on your system.
After launching the Platform Configuration window, you can specify where to install the SDK and the versions that you want to install. By default, the minimum supported version (currently 2.3.3) and the latest available version (currently 4.4) are selected. If you wish to build apps for other Android versions, simply select the appropriate Android SDKs from the settings view.
Each Titanium SDK supports building against a specific range of Android versions and requires at least one of these versions to be installed. For help identifying the min and max values for Android SDK versions, check out this post.
Q: How can I enable Push Notification implementation for Android users?
A: In order for push notifications from your app to reach a user, you must obtain a device token. Titanium has a PushNotifications API to help manage your user’s notifications subscriptions, but the device token is still necessary to permit Mobile Backend Services (MBS) to communicate with the push service provider.
To get a device token, you will first need to add the CloudPush module to your project. That module is included with the Titanium SDK, but can’t be found by default in new projects. For more about adding the CloudPush module and locating and saving the device token for later, check out this post.
Once you’ve acquired a device token, you can then use the Push Notifications API to subscribe and unsubscribe to notifications channels, send notifications to other MBS users or devices, or query MBS for the current user’s subscriptions. From there, you have some different options for managing push notifications, such as sharing them with specific users or over geo-location.
Q: How does Android handle permissions?
A: Starting from Android 6.0 (API level 23), users now need to grant certain permissions to apps while they are running instead of during the install. These permissions are divided into two categories called “normal “and “dangerous,” which determines whether the user has to manually approve the function based on privacy restrictions.
To support permissions in Titanium, we have the method requestPermissions starting from Titanium SDK 5.4.0. This is used to request any permission you may need, including functions for the dangerous permissions described above. An example of a dangerous protection permission would be android.permission.WRITE_CONTACTS. The requested permission must also be included in the Android Manifest.
There are also requestPermission methods that are ready-built for commonly used situations such as user Contacts, Calendar, Storage, Location Service, and Camera access. If you’d like to learn more about Android permission classifications, you can read more in this post.
Q: What are the best practices for structuring the code in apps using CommonJS libs to prevent leaks or improper memory usage?
A: The architecture you choose to structure the code in your app is one of the most important design decisions you will make as a developer. It can affect how you work with your own code, and how others work with it — either alongside you, or after you’ve handed the project over to someone else.
While there are many ways to do this (and ultimately the pattern you choose is what you’re most comfortable and productive with), we recommend a modular approach using CommonJS modules.
A modular, CommonJS design can be used to create small, reusable components that can be easily built and tested independently — more importantly, they can be reused in other projects. So, designing say a component to interface with an HTTP client to call remote APIs could be written in such a way to make it 100% reusable on another project, and since it’s been fully tested already you have confidence it will work.
More importantly, if you’re writing cross-platform commonJS modules, you can do all the testing on each platform, eliminate any bugs or issues and know with confidence that it’ll work fine in another project you use.
Alloy MVC is based on CommonJS, so you can do things like widgets to create components you can easily re-use. For example, a picker widget that is cross-platform and renders on both iOS and Android has events and methods for managing it, populating it and determining what was selected etc. A widget could easily be dropped into another project and integrated easily making it quicker and easier to develop.
CommonJS has another key advantage when it comes to memory leaks and avoiding them. Memory leaks occur when your app allocates memory but doesn’t release it. Identifying where the bugs are can sometimes be difficult, but here are some steps for monitoring allocations using Titanium for Android. This process won’t tell you the source of the leak, but it will help you identify the memory values of your app, so you can infer where the holdup might be.
If you’d like more advice on how to structure your app, you can find a useful guide in this post.
Need help to get started with Titanium? Check out our Welcome to Titanium guide for a full overview and our Quick Start guide for fast troubleshooting. For more, check out Titanium Sample Code and our free tutorials. We’ve also compiled Best Practices and Recommendations in case you get stuck.