I am absolutely thrilled to unveil my latest venture, Prototype 44: an online boutique showcasing a delightful assortment of playful t-shirts for preschool toddlers. We also carry a good portion of matching t-shirts for grown-ups.

We have four core collections:

• Ad astra per aspera is a collection of rocket / space ship themed toddler t-shirts
• Rainbows and unicorns is a collection of pink toddler t-shirts for girls
• Formula one is a small collection of F1 toddler shirts. But in this collection, I've started to introduce adult versions for their fathers.
• Sports car manga is geared towards the car guy father, like myself. There's a matching toddler shirt for every mens t-shirt.

We also have several one-off designs for halloween and other topics that are more experimental concepts in the store.

If you have a good idea for a t-shirt design you would like to see, don't hesitate to contact me and ask me to make it for you. Someone else in this small planet probably would enjoy it too!

Release build optimization - Part 1

The goal of this article is to remove calls to debug log for release builds. Debug logs, which is done using Log.d(tag, msg) often contains more information that you want exposed to the public. It also takes up valuable CPU cycles.

Remove Log.d calls via Proguard

Proguard is a tool on Android that shrinks, optimize, and obfuscate your code. We want to use this on our release builds. In Gradle, we enable this either in the buildType or product flavor closure. The details can be found in the Android Tools User Guide

Example build.gradle:
Note that there are two default rules files. When you first create a project in Android Studio, you usually get a proguard-android.txt file. In order for us to tell Proguard to remove the debug log, we need it to run the optimization phase, so we need to tell it to use the proguard-android-optimization.txt file instead.

The second thing to notice here is the inclusion of a second txt file, the proguard-rules.txt. This text file is how we tell Proguard to remove calls to Log.d, Log.v, Log.i, and whatever else you think is safe to remove.

Example proguard-rules.txt
The assumenosideaffects flag is an optimization option that tells Proguard to treat the declared method as an empty method and thus is safe to remove. Details can be found in the Proguard Usage Manual.

Please note that if for whatever reason you decide to use the returned integer from Log.d and assign it to a variable, Proguard will think that it maybe a useful method and won't remove it. So make sure that whatever method you decided to use this option with does not return a value that's being used, if your intention is to remove the call.

So now if we compile the release build, we would effectively remove the Log.d. So lets take the following example set of calls

Before Proguard:
After Proguard:
As we can see, it did a decent job of removing the debug logs. But it also left something behind. It created a new class and called some function. This is the obfuscated version of the code. So what we are seeing here is that the UserInfo class is still being created. So while we no longer take up I/O cycles by logging, we are still taking up CPU and memory by creating a class that we otherwise didn't need to create. So how can we change the code such that Proguard can safely remove the creation of the UserInfo class? It turns out that if we wrap it around a final boolean of FALSE, then Proguard will remove the code since there's no way the code can be executed. So we might consider changing our code to something like this:
This is a working solution. But because it requires that you add these "if (BuildConfig.DEBUG)" statements everywhere, it may not be acceptable, depending on the size of your project.

to be continued...

Quick & Dirty Tips: How to remove preloaded android apps

You need to have a rooted phone. Rooting of a phone is different for every device model, so it's important to find the right tools and procedure for your particular phone. Once your phone is rooted, connect your computer to your phone via USB and enable debugging via the developer options. You can now use the following set of commands in your computer terminal.

leo-osx:src_folder leo.kwong$ adb shell

shell@d2spr:/ $ su

root@d2spr:/ # mount -o rw,remount /system

root@d2spr:/ # cd system/priv-app/                                             

root@d2spr:/system/priv-app # ls MyTestApp*

MyTestAppForBlog.apk
root@d2spr:rm MyTestAppForBlog.apk
root@d2spr:/system/priv-app # exit

shell@d2spr:/ $ exit

leo-osx:src_folder leo.kwong$ 

What we're doing here is making the system folder read and write-able. Some of the preload apps will be in the system/priv-app and some will be in system/app. Only apks in /system/priv-app can use "system"-level permissions. Prior to Kitkat, all apks on the system partition could use those permissions. Uninstalling the app is just a matter of removing the APK file.

Reference: Android-Shell-Command-Reference

ModernUI guideline on Windows Phone 7/8

I was cleaning up my laptop today and found an old memo that I thought was worth saving. I wanted to post it here in case anyone thought it was useful.

Hiring your first Android developer

As a seasoned mobile application developer, I'm regularly approached by recruiters for new exciting opportunities, many of them from startup companies that are ready to jump into the mobile app world with existing web services.

Most companies start breaking into the mobile app development with iPhone/iPad app. This is influenced by reports that iOS users are more willing to pay. CNN reported in 2011 that Apple users buy 61% more apps! What's more, it's my personal experience that Android app simply takes longer to develop. Here are my reasons for that:

1. Apple's XCode has a wonderful emulator & profiling tool for performance.
1. Android's emulator is slow; really really slow. So slow that every developer must obtain a physical device.
2. Apple's Xcode is a mature IDE
1. Most developer still develop their Android app using the poorly executed Eclipse IDE.
2. If you're lucky and have some bravery, you've switched to Android Studio, which is based on the rock solid IntelliJ IDEA. Even though it's in beta, it will improve your life dramatically.
3. Apple's adoption rate is extremely high, so you code against only the latest SDK
1. Example: Adoption rate of iOS 7 vs Adoption rate of Android KitKat
2. In Android, you have to draw a line where your minimum SDK would be.
3. This version will have consequence in terms of how complicated your code becomes and what open source libraries you maybe able to take advantage of.
4. As an illustration, the project I'm currently involved in has an iOS and an Android team. We're building roughly the same app. Adjusted for developers dedicated to features specific to a platform, the iOS team has only 2 person, but the Android team has 4. I've been involved in developing a dozen mobile apps, and time and again, the iOS app has less bugs, jank, and requires less people.

How long does it take to make a mobile app? Answer: 18 weeks!

From: Kinvey Backend as a Service

If you've started with an iOS app, you have at least one mobile developer. She is going to understand the challenges presented to her like no other kinds of developer. She understand that you are going to be running code in someone's personal phone, which means the user care about battery life, bandwidth usage, privacy, and most obviously, the user need that phone to be a phone first, and an application second. Because of that your application can be interrupted any time. And because of these limitations, there are apps that simply doesn't belong in the mobile world, or at least not in the same form as you would on a desktop.

So what if your version 1.0 app is going to be an Android app because market research suggest that those are your primary customers? Here's what I would look for in a candidate:

Understanding application life cycle

• What type of objects would be appropriate to store in the Application?
• How would I handle the app being interrupted by a phone call in an Activity or Fragment?
• What special care to take if the app is to support orientation change?

Proper usage of thread

• What are Executors and how do you choose which Executor to use?
• When is it appropriate to use runOnUiThread and when would you use Handler instead?
• In which thread are the method in AsyncTask executed in and how would you make it safe to use if your app handles both portrait and landscape orientation?
• What things are appropriate to run in the UI thread?

Understanding Services

• What type of task is appropriate to be done in a Service?
• How does a Service notify the application UI of progress or result?
• What are the ways to start/stop a Service?

Know how to compose the UI

• Explain how LinearLayout and RelativeLayout work.
• How image size changes depending on which folder the image reside?
• How density pixel is calculated and used?
• What are 9-patch images?
• How to use themes.

Know how to write test cases in Android

And then depending on the type of application you are making, there are some area of topics that she should have experience with:

• If you plan to use a database
• Know how to create normalize tables and use SQLite database
• How to use ContentProvider
• How to use a Loader
• If you plan to have authenticated accounts
• Know how to write an Authenticator
• It would also be useful to know how to write a SyncAdapter
• Know something about caching such as the HttpResponseCache
• Familiar with popular open source libraries and can make suggestions as to which library maybe appropriate for your application.
• If you need real time update, she should know about Google Cloud Messaging
• and many many more topics, that not everyone is going to know
• Adding maps to your app
• Writing a widget
• Chrome casting
• Media playback
• Ads integration
• Facebook and Twitter integration

Lastly, you need to be able to build and distribute the app, which initially may be very simple, but soon enough you'll need someone who knows how to build, sign, and submit the app. You may want someone who's familiar with Maven, Gradle, and Google Play

I think if you're in a startup and wants to hire just one Android developer, she needs to have a good amount of diverse and deep understanding of Android. In my opinion, it's worthwhile to plan out what features you want to build so that you can ask the right questions. There's no point in hiring someone who has tons of experience in Map related apps if you're not going to be integrating maps. That's not to say you shouldn't hire a good generalist. But since this is your first and only Android developer in your startup, you need someone who is already an expert in Android, so in this case, you need someone who has already done it.

The other part of the hiring process that I find extremely flawed in the software industry is how we interview people. Most typically, we revert to CS 101 questions. While most of those questions are legitimate, many of them are useless. For example, a now popular question is about how to detect infinite loop in a linked list. This is popularized by an interview book that both interviewer and interviewee reads, and thus offer no insight today. If she ace the question right away, I'm pretty sure she just read the book. And honestly, how often do you encounter most of the things we ask in these interviews anyway.

The best interview that I've personally had was when I was asked to bring my own laptop, my own IDE, and pair program together a very simple app. For example, write an app that downloads a JSON file and display it in a ListView. Another type of question would be to design the app that you want to build. What component would we need. what open source library can we utilize. Perhaps most importantly, IMHO, is to make the interviewing process worthwhile for both parties. Both person should walk away learning something.

I realize my opinion doesn't align exact with Joel Spolsky's view on interviewing. I just think his views can be adjusted for different types of developers. And as Google admitted,  even their hiring process is flawed. And perhaps the technical interview is dead. One thing is certain, hiring and getting hired as a software developer is hard!

So godspeed to all who look for the right developer! and godspeed to those of us who strive to widen our knowledge and to sharpen our skills everyday. May we encounter good people and produce great product that enriches our society.

EDIT: I recently found an article that's similar to mine but he went much further to claim that Android development cost 2-3x than iOS. http://stevecheney.com/why-android-first-is-a-myth/

Builder pattern in Java

I've always liked how nice the StringBuilder API is. But I have not found the perfect opportunity to use it until today when I wanted to create a clean API for a Request object for searching OnDemand videos. The server API has been defined to accept a bunch of parameters. And depending on what you want to search for, you may supply one or more of these parameters.

What I wanted to create was a request object that's immutable once it's created. I have plans to use this request as a key to retrieve cached response, so it would be messy if someone was allowed to modify the attributes of the original request. So I've decided to have no setter methods.

I could create a constructor with all the parameters, but that would mean that most of the time the developer may have to create a SearchRequest object with lots of nulls. It's also very easy to misplace the arguments. If argument 1 is the rating and argument 2 is the offset, and they're both integers, I can imagine someone accidentally putting the value for offset in the ratings position and the value for ratings in the offset position.

The Builder pattern can be helpful in my situation. So I've prototyped the class here. Let's take a look at how I use this class first. Here's an example of a SearchRequest that query for high rating sports TV shows and episodes.


Running this code generates the following print:
03-01 20:00:59.849    1321-1321/com.example.app I/System.out﹕ http://my.server.com/search.json?offset=0&max_result=100&rating=4&categories=SPORTS&types=TV_EPISODE,TV_SERIES

I've restricted the creation of the SearchRequest object directly by making the constructor private. Instead the developer need to create a new SearchRequestBuilder. The builder then has small methods that are clearly named to add attributes. Once you have composed the request you want, you call the toSearchRequest method and you get the SearchRequest object.

And here's the source code for SearchRequest. I've seen variations of this pattern, but I've implemented it to satisfy my own requirements. I'd love to hear how you've used this pattern in the course of your career and how it differs from my interpretation.

Intro to SQLlite in Android

It has been a while since I've dealt with SQL. Recently we wanted to see if having an SQLlite database in Android would provide a performance boost. The idea is to prefetch the day's TV guide and load it into an SQL database during the night. And then when the user starts the app, we would first look at the database to see if we already have the data. If so we would load that instead of going through a network request. There may also be a performance boost if the query was written properly. Another benefit over network request is that the REST resource is in JSON format and needs to be parsed, whereas translating from a database row into a POJO potentially is faster. It also takes us later into using CusorAdapter and load data on demand. For those reason it's worth trying it out.

By the way, great site to practice your SQL is http://www.w3schools.com/sql/trysql.asp

The first thing I need to do is store all my TV Program POJO into the database. And the first step is to create a table. To create a table, I execute an SQL statement such as this:
CREATE TABLE program (id INTEGER PRIMARY KEY, name TEXT NOT NULL, start_time NUMERIC, end_time NUMERIC)

It reads that we're going to be creating a new table with 4 fields: an ID, name, start and stop time. This table will have the name program. Each row in this table must have at least an ID and a display name.

In Android, we do this by creating a class that extends SQLiteOpenHelper and overriding the method
public void onCreate(SQLiteDatabase db);

In that function we can execute the query
db.execSQL(createTableQueryStr);

The SQLiteOpenHelper is a class that manage database creation and help with version control.

When you extends SQLiteOpenHelper, you are also required to implement onUpgrade method. Here, we'll simply delete the table and erase all previous data. The query is:
DROP TABLE IF EXISTS program

The Program POJO actually has more data than the 4 things, but for simplicity of this blog, we'll pretend there's only 4 fields. But I want to mention that in reality, the POJO also includes a List of Strings that denotes which genre(s) the program belongs to. In order to include this information, I needed to create a 2nd table of genres. I decided to use Foreign key contraint to better insure data integrity. This way I don't accidentally add a Genre that doesn't belong to any program. The query for that table looks like this:
CREATE TABLE genre (program_id INTEGER, genre_name TEXT, FOREIGN KEY (program_id) REFERENCES program(id))

A database query always return a Cursor. It's the mechanism for which you retrieve the result. It doesn't load all the results in memory, only what the cursor is pointing at. This is good if you pass this cursor to your view so that you only need to get the data that is displayed in the UI, but it's not always possible depending on how the app is structured. So for convinence, I've created some method to translate between table row and POJO and vise versa.
Before you can insert, query, or delete anything in the database, you need to open it. This is usually done either than your app is created or when your Service is connected. Here I've created a ProgramsDataSource class that'll help me insert query and remove programs based on the start_time of the TV program.
Note the use of the insertWithOnConflict method where if a row already exist, I'll replace the values instead of throwing an exception.
The other thing to note is that if you need to use the DISTINCT function of SQL to query all unique names for example. Let's say I want to know programs of my entire TV Guide during prime time during the week, but I don't want to see the evening news show up 5 times, I would do a query with DISTINCT. To do that in SQLiteDatabase in Android, you use the overloaded method for query with the boolean as first argument.

WebRep

currentVote

noRating

noWeight