Receive More Updates

Date: - Time:

Saturday, 7 January 2017

Tips For Developing Or Building An Android App: My Lessons Learned

Hi! I’m Ivan and I’ve been an Android app developer for quite a while now. Or so it seems. Back in the day (we are talking about 2009), Android was just an infant and I watched the Little Green Man grow ever since. I’m afraid some time ago, Android managed to outgrow me. Nowadays, Android is not just on tens of thousands of different phones and tablets. It’s on your wrist, in your living room, in your car, and as soon we start assigning IP addresses to inanimate objects, it is going to be pretty much everywhere around us. A lot of ground for even an experienced Android developer to cover!

Also there are over one million apps just on Google Play, not counting Amazon AppStore or markets we are not generally interested in, like China.

So, how can an independent developer create a successful app in this huge market with big players? I have no idea, I haven’t made a successful app! But, I have made a cute one, and I’d like to share my story with you.

Lesson 1: Connect The Dots

Success (usually) doesn’t happen overnight and this is not my first app. I have ones ranging from unexpected over-the-weekend development hits like Macedonian Orthodox Calendar, with over 30,000 users in a  language that no more than 4 million people can understand, to more successful failures like TweetsPie, an app with heavy media coverage and a terrible user-base of just over 600 active users. A lot of lessons there!

While these apps helped me understand the mind of the “elusive creature called the User” a bit better, the one that inspired me was a two-hour project. Originally developed to make me a millionaire, once 1,428,571 users purchased the app as Google takes 30 cents out of every dollar, The Dollar App was made to test my merchants account.

Little did I know that years later I will receive an email from a happy mom stating that it was the best dollar that she ever spent since her boy was smiling every time my app gave him a hug.

And that’s how an idea was born! Why not use the fundamental human
need for a hug and make it pretty? Make it for a specific audience,
interactive, challenging, fun to use, and even more fun to share.

Lesson 2: Understand The Android Market

All the things I mentioned above added up to a live wallpaper app. The
basics are not that hard to guess. Android has a bigger market share
than iOS, but iOS users purchase more. Messaging apps are wildly
popular, but freemium games top the earnings. China, India, Brazil and
Russia are emerging markets, but lack spending habits. You can read
the App Annie Index for more insights.

So how does a live wallpaper app fit into this? First of all, it eliminates
most of the platforms since a live wallpaper is an Android thing. Second,
this feature was added in Android 2.1 so it has a large community and
quite a few beautiful examples. Most notably Paperland and Roman
Nurik’s open source Muzei, probably the best reference point for Android

While there are lot of live wallpapers out there, most of them fall under
the scenic/weather category, and very few fall under the cuteness
overload category. This is something we wanted to change and offer
something that gives you a smile each time you unlock your phone, even
though you unlocked it for a completely different reason. We gave you a
cute little bundle of joy to hug you before you go to bed at night, or when
you turn off your alarm in the morning. And even better, make it personal
and customizable.

Without further ado, and before we go into technical details, I proudly

present you: Ooshies - The Live Wallpaper

It features:

  • Free live wallpaper app that gives you hugs
  • 12 unique ooshies to choose from
  • Free, un-lockable, and purchasable content
  • Current weather updates
  • Social login and data sync
  • Seasonal greetings
  • Many surprises 
  • Ninja cat
  • Did we mention hugs?

Lesson 3: Try To Make It Happen

Ooshies seemed like a pretty straightforward Android app idea. Paint a 
background, overlay some clouds and stars, put a bear with a balloon on 
top, and you are good to go. But no, it’s Android! What seems easy is 
often quite difficult and we tend to repeat the same common
mistakes over and over again. Here’s a quick rundown of the challenges 
I faced:

1. Hardware acceleration - why draw using the CPU when the GPU is 
so much better at it? Well, it turns out that drawing bitmaps on a 
canvas cannot be hardware accelerated. At least not for the time 
2. OpenGL - if we want hardware acceleration we need to use OpenGL 
ES or even better a framework that does most of the work for us.
3. Bitmap loading - a well known memory consumption issue. We need 
to allocate 1 byte [0-255] of memory, for each channel in the #ARGB, 
to display a single pixel. Also the images we use often have higher 
resolutions than the device’s display. Loading them all will quickly 
result in OutOfMemroyException.
4. Home launchers - the live wallpaper will be hosted in the home 
launcher process, and different launcher tend to give different 
callbacks to the live wallpaper service (most notably Nova and 
5. Battery life - if not done right, the live wallpapers and the widgets can 
drain a lot of battery. With all the buzz about the Lollipop (Android 
5.0) terrible battery life the first app to go will be the live wallpaper.

So, overlaying a bitmap, painting it on a canvas, and then switching 
frames on touch to give a hug, doesn’t seem like a big deal, even when if 
it is done on the CPU, right? Thats right, it’s not a problem. But, who 
wants a static live wallpaper? It beats the purpose. The wallpaper should 
respond to your touches, it should move as you scroll your home 
screens, it should perform random acts of kindness and make you feel 
happy. And there is an Android development trick for that. There is a term called 
the parallax effect for adding depth in a 2-dimensional space. Imagine yourself driving a car. The house closer to you moves faster than the
mountain in the distance. Same effect can be achieved by moving
objects in different speed on a canvas. Although, they are all in the same
plane, your brain perceives the faster moving objects as closer to you.
Much like adding drop shadows, the parallax effect adds a z-axis.
And this is where all hell breaks loose! On most devices moving the
Ooshie, the weather overlay, and the background, at different speeds,
yields significant frame rate drop. Here’s how a single frame is drawn:

 canvas.drawBitmap(background, 0 - offsetX / 4 , 0 , null ); canvas.drawBitmap(weatherOverlay, 0 - offsetX / 2 , 0 , null ); if (!validDoubleTap) { canvas.drawBitmap(ooshieNormal, positionX - offsetX, positionY,null ); } else { canvas.drawBitmap(ooshieTapped, positionX - offsetX, positionY,null ); }

The offset is a percentage of the distance user has scrolled. It’s a
callback that the wallpaper engine provides:

 @Override public void onOffsetsChanged ( float xOffset, float yOffset, floatxOffsetStep, float yOffsetStep, int xPixelOffset, int yPixelOffset){ super .onOffsetsChanged(xOffset, yOffset, xOffsetStep, yOffsetStep,xPixelOffset, yPixelOffset); // athe current offset should be a fraction of the screen offset toachieve parallax if (!isPreview()) { float newXOffset = xOffset * 0.15 f; wallpaperDrawHelper.setOffsetX(newXOffset); if (isVisible() && hasActiveSurface) { wallpaperDrawHelper.drawFrame( false ); } }

I must note that all of this would be unnecessary if I knew how to work
with OpenGL! It’s on my TODO list, since anything more complex than
what we have now will require a hardware acceleration. But, for the time
being I have to work harder, not smarter (I’m open to suggestions in the
comments). So here’s what we did:

Lesson 4: Work With What You Have

As a big supporters of the minSdk=15 initiative, from the start we
eliminated all the 2.x devices. The effort for maintaining backward
compatibility is greater than the possible revenue from users
unable\unwilling to upgrade their phones. So, in most cases, we’ll be
able to achieve smooth experience with an added option to disable the
parallax if desired.

Another big optimization is how we handle the bitmaps. A very similar
parallax effect can be achieved with drawing two bitmaps instead of

1. Ooshie overlay - trimmed and carefully scaled Ooshie bitmap (can be
2. Combined overlay - a combined background and weather bitmap that
moves with a fraction of the Ooshie speed.

This Android development trick saves memory and speeds up the
drawing time, for a slight parallax effect degrade.
When scrolling the home screens, frames will be drawn quite often
(ideally more than 30 times per second). It’s crucial not to draw them
when the home screen is not visible (some lock screens, some app
drawer, opening/switching apps etc.) to minimize the CPU usage.
This is all tied closely with the weather updates. Initially there was a
repeating task, executing every hour or two, to sync the weather, but it
was really an overkill. If the user cannot see the wallpaper, the weather
info is irrelevant. So now, weather updates happen only when wallpaper
is visible.

 long lastUpdate =prefStore.getLong(SharedPrefStore.Pref.WEATHER_TIMESTAMP); if (System.currentTimeMillis() - lastUpdate >Consts.WEATHER_UPDATE_INTERVAL){ // update the weather if obsolete Intent intent = new Intent(getApplicationContext(),WeatherUpdateService.class); startService(intent); }

So, basically, here’s the checklist for a memory optimized smooth
software bitmap drawing:

1. Combine bitmaps once
2. Draw less bitmaps
3. Redraw only on demand
4. Avoid background tasks
5. Offer users some control over the process

Lesson 5: Test. Test. Test

I cannot stress how important this is! Never, I repeat NEVER, release
your app before testing it! And, I don’t mean that YOU should do the
testing. You wrote the code, you know how it works, and you influence
the result by knowing the expectations. I’m not talking about JUnit testing
(although recommended), but about staged rollouts i.e. alpha and beta

If you are into Android software development the terms are
straightforward, but here is a quick rundown:

1. Alpha testers - a small group of people consisting of your teammates
and people from the industry, preferably Android developers.
Chances are they are going the have high-end devices and will play
around with the developers options. They’ll send you stack traces,
bug reports, and even give you some code/UI optimization tips and
tricks. Perfect for early releases with partial/missing features.
2. Beta testers - a much broader audience with various demographics.
Stable releases should be published here. Even if your ninja level is
too damn high, you can never predict, let alone account, for all the
possible Android distributions and ways people use their phones.
Once we passed the alpha, I thought we were done. But, boy I was
wrong?! Turned out that not all Android users have Nexus devices with
the latest software! Who’d know? :)
Here are some Android development issues based on this revelation:

1. Different launchers have different default home screens - usually the
first or the middle one, and ,as far as I know, there is no way of
knowing it’s position.
2. It’s hard to center the Ooshie without knowing the default home
screen position - thus the settings slider for adjusting the parallax
3. An average user doesn’t know what parallax offset means - much
simpler terminology should be used on the settings page.
4. A random user will suggest your next feature.
So I would like to thank all our beta testers for the hard work they did. I
hope that getting all the latest features before anyone else is a decent
reward for their dedication. If you’d like, you can also be a part of
our Google+ Beta Community.

Lesson 6: Let The Data Speak

Making an Android app that stands out today is a bit more difficult than
making a calculator app, when there were none back in 2009. Making
the perfect app is hard. Mainly because perfection is in the eye of the
beholder. What is good for me, doesn’t necessarily mean it’s good for
you. That’s why it’s important to let the app grow. Our roadmap checklist for new features shows that we have enough work for the whole 2015.
Among other things we’ll soon include:

1. Sounds
2. Seasonal backgrounds
3. Customizations (background color, weather packs, ooshie skins, etc.)
4. Region specific ooshies (ex. babushkas)
5. A lot of new ooshies and ways to unlock them

Now, we might have kept the app in beta until all is done, but that way
we are throwing away valuable data. Not all beta testers will dedicate a
portion of their day to send you the feedback. That is where you can
benefit in using tools for getting the feedback. You can use Google
Analytics, Flurry, Mixpanel, Crashalytics, ACRA, etc. to collect usage

For example, by analyzing the data we noticed that users don’t click the
settings button a lot, so we made it more apparent and added a quick
tutorial for tweaking the settings.
Although this is a background process, it can be used to further improve
the user experience. Why not show the user how many times:

1. he/she received a hug
2. how many rainy days were brightened up by a smile
3. how many taps were needed to unlock an Ooshie with a mini-game
4. how many friends installed the app because of you

This is important because it provides consequences for their actions.
Don’t make the same mistake our educational system does, making the
users passive content consumers. Make them in charge. Give them the
option to control their own devices and create their own personal
experience. If you manage to package all this into a cute bundle that
steals a smile on the first splash, than is not too far fetched to ask the
user for spammy favors for content unlocking.
In the end, you need to evolve your Android app development based on
this data as a guide. Although primarily intended for moms/kids, this app
may become popular in other demographics. It may not fit into our
original vision, but users needs must be met. Otherwise they’ll find
someone who can.


Let’s return to my most successful failure TweetsPie. Despite couple of
awards and huge media coverage, the app failed to retain it’s users (the
reasons why are beyond the scope of this article).
Success is not always apparent. Thanks to the whole experience I
learned a lot. I gave, at least, a dozen lectures on How (not) to fail as a startup on various events and hackathons, and managed to get a couple
of clients at Toptal.

Even more important, I try not to repeat the same Android development
mistakes with Ooshies by following the tips and tricks in this guide.
To wrap up this long guide, what we define as a success is, at later
stage, tightly coupled with what we set as goal in the beginning. The
most common success measure is, of course, making a lot of money. No
matter if your app makes it or not, you must try to make it happen, and
believe me at the end you’ll become a better person (hopefully one that
manages to learn OpenGL). You’ll make new friends, few enemies, and
if you are lucky/smart enough you’ll make a lot of users happy.

This guest post article first appeared on Toptal and it was written by one of the best blogger called Ivann who is the CEO of 


  1. hmmm. av been longing for tutorial to build an app so tey

  2. mr blazer, i want to change all d character and bg in temple run. i need ur clue

  3. long, cool and interesting article

  4. long, cool and interesting article

  5. So it's possible to create an app wit a phone?

  6. Wow Very helpful...Thanks for this wonderful post i will make sure i share this with others 😋...

    Commenting from 😎👉👈😎


Is this post helpful?

Your comment(s) are highly appreciated to this post. Be the first to comment and make sure you also share to your friends and families about this post, for them to also benefit from it.

Share to all social networks like Facebook, Twitter and others social network you may know.

Are you finding it difficult to drop a comment here? Kindly click here and learn how to comment on