Posts Tagged ‘apps’

Android Tricks: Multitouch AND 1.5 Support, Same App

Tuesday, July 20th, 2010

I don’t know about you but I have an emotional attachment to old platforms and APIs. They are often sweet and nice in their primordial simplicity, even with their well-understood limitations. Even when they become obsolete, we developers still remember and miss them.

In case of Android, version 1.5 / API level 3 is technically obsolete but is far from being extinct from the device market. In fact, as of the day I write this article, it is one of the most widely installed Android versions on the market. (And if you add the not-so-different 1.6, they take almost half of the market together.) While subsequent versions brought us a lot of goodies in various areas of the platform API, 80% or more of all functionality our apps need today is present in 1.5.

Sure, there are cases when your app just isn’t meant to run on 1.x. For example, its core functionality is based on the APIs that are absent from API level 3 (e.g. you’re making a live wallpaper), or when you don’t want to support old devices for performance reasons, or due to a marketing decision. However, in many cases what makes developers raise the minSdkVersion bar is the need to use some of the 1.6+ APIs, such as the new contact management facilities, signal strength detection or better animation support.

The good news I’m trying to bring in this article – to those who aren’t yet familiar with this trick – is that you can actually use the new API yet keep minSdkVersion at 3. This trick might not work in all cases, and might look like a hack, but it will work for many situations like this – and who knows, might allow your app to reach out to its grateful, ready-to-pay customers who still use 1.5.

(more…)

Android Beatz: Making a Drum Machine App

Monday, July 5th, 2010

Hello again! I’m back from a wonderful vacation and ready to share some more experience of Android programming. Today I’m presenting a simple drum machine app that I made for fun. If you saw the video above, then you probably got the idea how a drum machine works. The design was inspired by one of the greatest drum machines ever – the AKAI MPC. You can have a look at how the original device looked like for example here. Our app is, of course, greatly simplified compared to AKAI MPC, but you can have some fun with it too.

Here’s a screenshot for a better idea of how the UI looks (clickable):

Some interesting features of this app:

  1. The UI is done using bitmaps and custom controls to imitate the original device
  2. The latency is low enough not to be annoying (at least on my Droid)
  3. You can press multiple buttons at once which is very good for long samples such as the bass drum
  4. The LCD screen control uses a 9-patch bitmap background, and switches between flashing, static and ticker text
  5. The LCD screen uses a custom TrueType font that is included within the app

Now let’s see how the most interesting features of this app were implemented (as usual, the source is available at the bottom of the article).

(more…)

Android UI: Making a Live Wallpaper (Fire Simulation)

Sunday, June 13th, 2010

In the previous article we used 2D graphics via the Android Canvas to draw a custom UI widget. The Canvas approach is very useful when you need to draw relatively static graphics or when there is not too much complex animation. That is the typical case for UI widgets.

In this article we will develop a live wallpaper that displays a fire simulation that you might remember from the good old days of demo scene and DOS. Since we need very fast graphics, we will use OpenGL as the rendering engine. Although OpenGL is typically used for 3D graphics, it can also be used for hardware-accelerated 2D graphics, such as in this case.

Here’s our plan:

  1. Understand and implement the fire effect
  2. Enable OpenGL to render the fire on the screen
  3. Convert our simulation into a live wallpaper

The source code is available at the bottom of the article (but read on to learn some of its limitations).

Note: The part related to live wallpapers will only work on Android 2.1 or higher.

(more…)

Android Custom UI: Making a Vintage Thermometer

Monday, June 7th, 2010

Hi everyone. Today I would like to show how to design a simple yet cool-looking custom UI element for Android. Since an analog clock is already part of the standard UI, I came up with an vintage thermometer as an example.

The final result looks like this:

Here’s the list of nice features this custom view has:

  • A gradient metallic rim and a textured face
  • The logo changes its color depending on the temperature (as you can see in the screenshots)
  • A circle-bent title below the logo
  • A 3D hand with a shadow
  • The hand moves in a physically realistic fashion
  • And, of course, it shows the real temperature – based on the phone temperature sensor (if your phone has one)

Also, the thermometer view tries to be a good Android UI citizen:

  • Scales well to any size
  • Supports screen orientation changes and layout changes
  • Optimizes its drawing procedures, doesn’t eat CPU when the hand is not moving
  • Saves and restores its state gracefully when the activity is paused, re-created etc.
  • Reusable – not bound to any external code

If you’d like to know how to develop views of this kind, read on. It’s so easy and fun to do that you will be surprised.

(more…)

Android Guts: Intro to Loopers and Handlers

Thursday, June 3rd, 2010

One of the reasons I love Android API is because it contains so many useful little things. Many of them are not even specific to the platform and I really miss them in Java SE. Today I’d like to give a short introduction to two nice classes – Looper and Handler. They are used in Android UI internally, and available to us developers so we can do some cool things with their help.

So what can you do with Loopers and Handlers? Basically, they implement a common concurrency pattern that I call the Pipeline Thread. Here’s how it works:

  • The Pipeline Thread holds a queue of tasks which are just some units of work that can be executed or processed.
  • Other threads can safely push new tasks into the Pipeline Thread’s queue at any time.
  • The Pipeline Thread processes the queued tasks one after another. If there are no tasks queued, it blocks until a task appears in the queue.
  • Sometimes tasks can called messages and other names.

This architecture has some valuable traits and is widely used in frameworks and applications on different platforms.

In this post, we are going to build a simple app that emulates a queue of background downloads while showing its status in the UI. It will be based on a Pipeline Thread that we will build using Looper and Handler. As usual, the complete source is available at the bottom of the article.

(more…)

Android Architecture Tutorial: Developing an App with a Background Service (using IPC)

Tuesday, June 1st, 2010

Intro

Android is a wonderful platform. It has a rich API that allows you, a developer, to easily implement things that other platforms do not support at all or they need you to bend over backwards to get what you want.

The ability to develop a service that runs in the background and does something when the user is not actively working with your app is a great option for application authors. Examples of usage include mail or IM apps that send you a notification whenever there is a new message (we’ll discuss notifications and how to program them correctly in another post), background music players, background downloads and so on.

Yes, there is a dark side to Android background services too – too many services doing too much stuff in the background will slow down the phone and suck the battery. However it’s not quite what I wanted to bring up in this post, so maybe we’ll come back to resource management etiquette in yet another post.

Problem Definition

What we will develop here is a dummy application that contains the following components:

  1. A background service doing something important but not immediately visible to the user
  2. One or more activities that, once launched by the user, talk to the service, control the service and present some information that the service provides

The architecture also has the following characteristics:

  • The service will run in a separate process, allowing the platform to manage its lifecycle and resources separately from the activities
  • The service is supposed to run all the time (there are other valid usage patterns for services, but we won’t discuss that here)
  • The UI (activities) will get updates from the service in a callback or passive mode, reacting to service events rather than polling the service for updates. This is very important in terms of effective architecture, so please keep it in mind for now
  • Since the service will run in a different process, we need to use IPC to talk to it from activities. IPC stands for interprocess communication and is not an Android-specific term but Android has its own implementation (as we will see)
  • The service will do all the thinking (business logic) while the UI will be designed to be as thin and dumb as possible. We’ll keep the architecture well-layered
  • The service will be configured to start during system boot-up

In terms of functionality, our service will grab the latest #android tweets using the twitter search API. The activity will show the latest tweets grabbed by the service when you launch them, and update automatically. Yes, it is a pretty artificial use case, but later you can add notifications and turn the app into “Android News Notifier”, and then put it on the market. :)

(more…)