Thaana on Android - Introduction & Best PracticesNaail Abdul Rahman @kudanai

Overview

• Thaana Support across devices– API Versions

• Using custom fonts– Android Views– Memory optimization

• Layout Direction– Setting specific views or entire application for

RTL

• Handling Input• aThaanaUtils

Demo App

• Download the demo app

http://github.com/kudanai/aThaanaUtils/releases

Demo App

API Versions

• Android 1.0 started off 2007• Android 2.3 “Ginger Bread”– API 10

• Android 3.0 “Honeycomb”– API 11

• Android 4.0 “Ice Cream Sandwich”– API 14

• Android 4.2 “Jelly Bean MR1”– API 17

API Versions

• Android 3+– Proper Unicode support started– New UI paradigms– Not seen in the wild a lot

• Android 4+ (API 14)– Action Bar pattern– Roboto Fonts

• Android 4.2+ (API 17)– Proper RTL support

API Versions

API Versions

API Versions

• Android is not like iOS, where we can safely expect a large % of the user-base to upgrade.

• Stick to API 14+– Lower versions limit potential– Not enough users to justify going there

anyway.

• If you Dare, stick to 17+

Using Custom Fonts

• Android allows embedding your own application fonts.

• Read UI guidelines on using custom fonts.

• Any well formed TTF or OTF font is valid.

Using Custom Fonts

• Throw them in the Assets folder

Android Views

• Two main classes of views commonly used.– TextView subclasses–WebView

TextView Subclasses

TextView Subclasses

• Obtain a Typeface object from the Assets

• Set typeface to the TextView using the TextView.setTypeFace() method.

WebView

• Backed by WebKit rendering engine.• Can render Thaana on Android 2.3 as

well.• There are some bugs in android 4.2 -

4.3

WebView

• CSS3 @font-face • Reference Assets folder using

file:///android_asset/

• Apply the font-face to html elements. Webkit does the rest.

Memory Optimization

• Typeface objects consume memory.• Views will hold strong references to

Typeface objects.• More Views with custom fonts = More

memory… naturally.– Careful while using ListView’s• Despite view recycling mechanisms,

improper handling can bloat memory use.

Memory Optimization

• DON’T– Use a lot of different fonts or create a

new Typeface object for ever view– Instantiate a typeface for every row of a

ListView– use custom views that call

Typeface.createFromAsset() in their constructor, in ListViews

Memory Optimization

• DO– Share the Typeface as much as possible.

Avoid instantiating too many.– If using a list view, let the Adapter own

the Typeface objects.– If using custom views… (see next)

Memory Optimization

• Use a Resource Manager pattern– Basically a Singleton which will cache

Typeface objects– Cache can use weak referencing for

further optimization, if required– Lazy instantiate Typefaces as required– Only one object per Typeface,

throughout the entire application scope.

Layout Direction

• Proper RTL since API 17+– Add android:supportsRtl="true” to the

manifest to enable RTL methods– Some RTL specific methods have no

effect without this.

Layout Direction

• Pre 17,– Align everything to the right and hope

for the best.

Layout Direction

• Usually you either flip specific views or flip everything.– onCreate() of activities

Layout Direction

• View direction RTL will flip ActionBar and NavigationDrawer correctly to the right. As expected.

• For Navigation Drawer,– Can either use “start” or “right” for

layout_gravity

Layout Direction

• Prefer “start” to “right”… • ActionBar title can be set using

setTitle() method. However, won’t display correctly.–Must set a custom view, which uses a

custom typeface.

Layout Direction

Handling Input

• Input mainly done into EditText (or subclasses)

• Can use two methods to handle Thaana Input– Use an InputFilter or a TextWatcher to

modify user input (substitute latin->thaana) on the fly.

– Use a custom KeyboardView

Handling Input

• Must apply typefaces and direction hints to EditText as before.

• InputFilter– Single method, filter()• Receives the user input. Can modify the

input as necessary.• Clean.• Disable Autocorrect !important

– Does not always work.

Handling Input

• TextWatcher– Attached to an Editable, will get called

when modified.–More flexible, but risky.

Handling Input

• TextWatcher–Modifications will trigger itself.–Will race unless recursion is checked.

• Less error prone to use a proper TextWatcher than an InputFilter.

• Can use multiple TextWatchers on a single editable.

aThaanaUtils

• http://github.com/kudanai/aThaanaUtils• API 14+• Collection of the above concepts.

Currently provides:– TypefaceManager to handle font loading– Some Custom Views (somewhat pointless

but why not)– TextWatcher & InputFilter for Input Handling–Misc. Utility functions

aThaanaUtils

• Planned additions– Custom KeyboardView for input• Already done, but too buggy right now.

–More conversion mechanisms– Upload to repo for easier inclusion in

projects

Thank you

Questions?

tweet-> @kudanai