Tips for Developing an Android App: My Lessons Learned

Topics covered

Understand Android market

Tips for developing Android app

Lessons learned

I'm republishing and interesting post about Ivan Dimoski.Original source: Tips for Developing 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 development. 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
• a 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 being.
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 TouchWiz).
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, float xOffsetStep, 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 to achieve parallax
      if (!isPreview()) {
        float newXOffset = xOffset * 0.15f;
        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 three:

1. Ooshie overlay - trimmed and carefully scaled Ooshie bitmap (can be accessorized)
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 testing. 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 offset.
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 data. 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.

Conclusion

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. You can check our website or download Ooshies to give it a try.

Published with permission of toptal

Tips for Developing an Android App: My Lessons Learned 2015-10-01T02:56:00-07:00 Rating: 4.5 Diposkan Oleh: Unknown