Android Zeitgeist

Fixing the rotation - Instant Mustache #8

2013-01-14T20:47:00.000+01:00

Wrong orientation

If you run the current version of Instant Mustache and take some pictures you'll notice something odd: The orientation of the taken pictures is sometimes wrong. This may depend on the device you are using. When using a Galaxy Nexus the picture will be rotated 90° to the left when taking a picture in portrait mode but will be rotated correctly when taking a picture in landscape mode.

Wrong orientation of photo that has been taken in portrait mode

How does this happen? You may remember that we've used Camera.setDisplayOrientation() in one of the previous articles to explicitly set the display rotation. First, this setting only affects the preview picture. The picture passed to the Camera.ShutterCallback isn't affected by this setting. And second, we still have to account into how the device is rotated in the moment of taking the picture.

Detecting and remembering the orientation

What we need to do in our code is to register an OrientationEventListener to get notified whenever the orientation changes. We'll remember this orientation and use this to rotate the taken image once the callback returns.

Whenever the orientation changes onOrientationChanged(int) of the listener will be called. The orientation will be passed to the method in degrees, ranging from 0 to 359. We need to normalize this value as we are only interested in 90° steps for rotating the picture.

CameraOrientationListener.normalize()

Another method called rememberOrientation() will be used to save the orientation of the device in the moment of the user pressing the shutter button.

CameraFragment.takePicture()

Rotating the picture

Now we just need to rotate the Bitmap. We do this by creating a new Bitmap object and applying a rotated Matrix to the pixels. The rotation angle is calculated by summing the remembered orientation, the display orientation and the natural rotation of the device.

CameraFragment.onPictureTaken()

Result

Photos rotated correctly in portrait and landscape mode

Android 2012

2012-12-22T14:21:00.000+01:00

After Google Zeitgeist and YouTube looked back on 2012 it’s time to do the same for Android.

January

The year 2011 has just ended and the Galaxy Nexus is the current flagship phone. 12 days later on January 12th the Android Design website launched. Followed by the Android developers Google+ page on January 30th.

February

The first numbers of the year are published. 850,000 Android phones are activated every day. 300 million devices have been activated so far.

March

On March 5th expansion files are introduced and Android apps break the 50MB barrier expanding the size limit to 4GB. The Android market retires and is reborn as Google play on March 6th. The same month on March 21st the SDK tools and ADT revision 17 are released, adding an emulator that supports running x86 system images on Windows and Mac OS X. An update to the Android Developer Console on March 29th allows multiple users to manage published Android apps.

April

The emulator gets even more faster on April 9th by adding GPU support. On April 20th the first episode of Friday App Review airs and is later called The app clinic.

May

On May 4th Wolfram Rittmeyer publishes the first posting on his blog Grokking Android. Followed by the first article published on Android Zeitgeist on May 27th. 3 days before on May 24th In-app Subscriptions are launched on Google Play.

June

The Google I/O takes place for three days from June 27th to 29th. There are now 900,000 Android devices activated every day and 400 million devices have been activated up to now. Android 4.1 (Jelly Bean) is publicly shown for the first time on June 27th. The same day the Android 4.1 SDK is released. In addition to that the first tablet by Google is unveiled: The Nexus 7. On the second day of the Google I/O the Android SDK tools are updated to revision 20. At the end of the Google I/O there have been 3.5 million live streams seen from 170 countries.

July

On July 3rd the Ouya, an Android based console, is unveiled and a Kickstarter campaign is started on July 10th. On July 9th the Android 4.1 source code is published as part of the Android Open Source Project (AOSP).

August

The funding phase for the Ouya is completed. The campaign collected $8,596,475. That’s 904% more than the initial campaign goal.

September

New numbers are released. There are now 1.3 million devices activated every a day. About 70,000 of these devices are tablets. 480 million devices have been activated up to now. On September 9th the first episode of This week in Android development airs. A day later the first episode of Android Design in Action is uploaded to YouTube.

October

Till mid October 3 million Nexus 7 units have been sold. Starting from October 15th the new Google Play Developer Console is available to everyone. Google planned a launch event on October 29th in New York but it has been cancelled due to Hurricane Sandy. Nevertheless the Nexus 4 and Nexus 10 are introduced online this day. These are the first devices to run Android 4.2.

November

The first episode of (╯°□°）╯︵ ┻━┻ airs on November 8th. On November 13th the Nexus 4 and Nexus 10 went on sale and are sold out in minutes. Later that day the Android 4.2 SDK platform is released. Another day later the Android SDK tools revision 21 are released.

December

Google releases a new Google Maps API for Android on December 3rd. On December 10th a new version of the In-App billing API is released.

The Android team releases their Happy Holidays video:

2013?

What has been your Android highlight in 2012 and what are your wishes for 2013?

Mind the gap: String.isEmpty()

2012-12-11T20:41:00.000+01:00

Articles labeled "Mind the gap" are short articles mostly about simple problems that arise from using different API levels of Android. They are more short trivia postings than big teachings about Android development.

I try to write code as readable as possible. That's the reason why I don't want to compare a String to an other empty String object or check its length when I want to know if a String is empty.

In the book "Clean code" by Robert C. Martin you can read Grady Booch saying: "Clean code reads like well-written prose". So I try to use String.isEmpty() for that reason. Internally it may do a length check as well (I stopped my investigation at the native keyword) but when reading the following snippet it is absolutely obvious what I intend to do.

Even though isEmpty() has been introduced in Java 1.6 it hasn't been available in Android until API level 9 (Android 2.3) so I accidentally caused some crashes on earlier versions of Android. Nowadays lint thankfully saves me from doing this error.

So what to do now? I don't know if someone at Google felt the same but there is a class in the Android framework that solves that problem: TextUtils. This class also has a lot of other helpful methods like join() to join an array of elements to a String using a delimiter or getReverse() to reverse a String (Take that interview question!).

In addition to that the TextUtils class has a method isEmpty() that is available since API level 1.

Phew! By the way: Internally isEmpty() checks if the length of the String is 0 (and does a null check).

Examining the ViewPager #3

2012-11-05T20:40:00.000+01:00

This article is part of a series of articles about the ViewPager component. Click here to see a list of all articles of this series.

Horizontal scrolling pages

Have you ever tried putting horizontal scrolling components inside a ViewPager? Well, since revision 9 of the support library this is supported by the ViewPager. As long as the inner component can scroll horizontally this component will be scrolled. Whenever the component can't be further scrolled the ViewPager will handle the touch events and you start to switch to the next page. This works out-of-the-box for scrolling view components of Android like the WebView.

Internally the ViewPager uses ViewCompat.canScrollHorizontally(View v, int direction) to determine if a child view can be scrolled horizontally and should receive the according touch events. Unfortunately this method is only implemented for Android 4.0 (API level 14) and above. For all earlier versions this method will always return false and therefore never scroll the components inside the ViewPager.

Bezel swipe

Allowing horizontal scrolling components introduces a new problem: What if you want to switch pages but not scroll every component to its horizontal end? When you start the swipe at the phone's bezel (or actually from the edge of the ViewPager) you'll switch pages instead of scrolling the page's content. This gesture is called bezel swipe.

For reading more about the bezel swipe gesture from a UI point of view read "Bezel swipe, a Solution to Pan and Swipe Confusion?" on Android UI Patterns.

The good news is again: The ViewPager supports bezel swipe out of the box. But as you can't horizontally scroll inside pages on devices running an Android version lower than 4.0 (API level 14) bezel swipe isn't of any use on these as well.

The area to start a bezel swipe has a width of either 16dp or a 10th of the total width of the ViewPager depending on which one is smaller.

Fake dragging

The ViewPager supports fake dragging. Fake dragging can be used to simulate a dragging event/animation, e.g. for detecting drag events on a different component and delegating these to the ViewPager.

You have to signal the ViewPager when to start or end a fake drag by calling beginFakeDrag() and endFakeDrag() on it. After starting a fake drag you can use fakeDragBy(float) to drag the ViewPager by the given amount of pixels along the x axis (negative values to the left and positive values to the right).

The following example uses a SeekBar whose current progress state is used to fake drag a ViewPager by the given percentage.

SeekBarPagerListener.java

This video shows the fake drag in action:

Displaying the taken picture – Instant Mustache #7

2012-10-30T23:35:00.000+01:00

Writing the PhotoActivity

In the last article we wrote the code to take a camera picture and save it on the external storage. After saving the file the activity will be finished and a Toast will show up. This is not really user-friendly so now we'll write our next activity which will display the taken picture and later offer the option to share this picture.

We'll start by creating an empty activity called PhotoActivity and add it to the manifest of our application. For now the layout will only contain an ImageView to display the picture:

activity_photo.xml

Instead of showing a toast in our CameraActivity we create an Intent to start the PhotoActivity and use setData(Uri) on the Intent object to pass a Uri pointing to the picture file:

onPictureTaken() - CameraActivity.java

In onCreate(Bundle) of the PhotoActivity we'll retrieve the Uri from the Intent and pass it to the ImageView. The ImageView will take care of loading the picture from the external storage and displaying it.

onCreate() - PhotoActivity.java

And that's already all the code we need for the first version of the PhotoActivity.

CameraActivity (left) and PhotoActivity (right)

Taking a picture – Instant Mustache #6

2012-10-26T20:59:00.000+02:00

activity_camera.xml

As we encapsulated the code handling the Camera object inside the CameraFragment class the activity just calls takePicture() on the fragment when the user presses the button.

takePicutre() - CameraActivity.java

The fragment calls takePicture() on the Camera object. It's possible to pass up to four callbacks to this method: A shutter callback, a raw callback, a postview callback and a jpeg callback. According to the documentation their usage is:

The shutter callback occurs after the image is captured. This can be used to trigger a sound to let the user know that image has been captured.
The raw callback occurs when the raw image data is available.
The postview callback occurs when a scaled, fully processed postview image is available.
The jpeg callback occurs when the compressed image is available.

We are only interested in the JPEG image. The fragment itself is also the callback so we'll implement the Camera.PictureCallback interface.

Once the picture is taken onPictureTaken() will be called with a byte array. We decode the given byte array and create a Bitmap object and pass it via the CameraFragmentListener interface to our CameraActivity. Later we will use this bitmap to draw the mustaches on it.

onPictureTaken() - CameraFragment.java

Saving the picture to the external storage

Once the activity receives the bitmap object it needs to do a bunch of things:

Determine the directory to save the picture to and create it if necessary
Create a unique file for the picture inside the directory and save the image data to it
Notify the MediaScanner that we created a new file
Show a toast that the picture has been saved successfully (For now until we've written the activity to display the taken picture).

Determining the directory

We want to save the picture into a directory on the external storage that is visible for all other applications. By calling Environment.getExternalStoragePublicDirectory() and passing Environment.DIRECTORY_PICTURES we get the public directory for pictures (Available since API Level 8). Inside this directory we'll create a directory with the name of our application (if it doesn't exist already).

onPictureTaken() - CameraActivity.java

Saving the file

We'll create a file with a unique file name containing a timestamp, e.g.: MUSTACHE_20121031_235959.jpg. The compress() method of the bitmap object is used to save the picture into the file.

onPictureTaken() - CameraActivity.java

Notifying the MediaScanner

Scanning the SD card for changes is costly. Therefore most Android versions only scan the whole card if the card is re-inserted or was mounted by another device. This seems to be different in different vendor versions of Android but nevertheless you can't assume a file to be seen by other applications (for example the gallery) until it has been scanned by the MediaScanner. For that reason we'll notify the MediaScanner about the file we've created.

onPictureTaken() - CameraActivity.java

By now we've already created a simple camera application. We can take pictures and they show up in the gallery of the device. Pretty cool so far, huh?

Examining the ViewPager #2

2012-10-25T21:24:00.000+02:00

This article is part of a series of articles about the ViewPager component. Click here to see a list of all articles of this series.

Offscreen pages

The ViewPager doesn't create all its pages at once. When using a lot of pages this would be horribly slow and even unnecessary if the user would never swipe through all these pages. By default the ViewPager only creates the current page as well as the offscreen pages to the left and right of the current page.

If you only use a small amount of pages you may get a better performance by creating them all at once. You can use setOffscreenPageLimit(int limit) to set the number of pages that will be created and retained. Note that the limit applies to both sides of the current page. So if you set the offscreen page limit to 2 the ViewPager will retain 5 pages: The current page plus 2 pages to the left and right.

Responding to changing states

You can get notified whenever the displayed page changes or is incrementally scrolled. To listen to these state changes you can implement the OnPageChangeListener interface or extend the SimpleOnPageChangeListener class if you do not intent to override every method of the interfacce.

The following example listener updates the title of the activity according to the title of the currently selected page:

UpdateTitleListener.java

Margin between pages

When scrolling through pages they all look like glued together. You can use setPageMargin(int pixels) to define a margin between pages. The gap is filled with the background color of the ViewPager.

The following screenshots are showing the same ViewPager during switching pages. The left screenshot shows the ViewPager with no page margin set. In the right screenshot the margin has been set to 20 pixels. Notice that the method expects the margin to be defined in pixels. To use the same physical margin on all kind of screens independent from their pixel density define the margin in density independent pixels (dp) and convert them to the actual number of pixels for the current screen.

It's also possible to define a drawable that will be used to fill the margin between two pages using setPageMarginDrawable(int resId) or setPageMarginDrawable(Drawable d). The best approach is to use a Nine-patch that be scaled dynamically by the system to fill the space between the pages.

Switching pages programmatically

You can also switch between pages programmatically. Using setCurrentItem(int position, boolean smoothScroll) you can switch to the given position. If the second parameter is true a smooth animated transition is being performed. Using false the ViewPager will switch to the given page without any animation. If you always want to switch pages with an animation you can also leave the second parameter and use setCurrentItem(int position).

Examining the ViewPager #1

2012-10-22T18:30:00.000+02:00

This article is part of a series of articles about the ViewPager component. Click here to see a list of all articles of this series.

The Android support library offers a great UI component for horizontal scrolling pages: The ViewPager. Over the last iterations of the support library more and more functionality has been added to the ViewPager silently. For that reason I decided to study the various features of the ViewPager more closely. This will be a series of articles covering several of these features.

Disclaimer upfront

According to the documentation of the ViewPager the implementation and API of the class may change in future releases. Therefore also this blog posting may not be up-to-date if you are reading this a long time after the published date. Check the documentation if some of the examples may not work anymore as I described them here.

The basics

The ViewPager is a ViewGroup that displays by default one page at a time. The user can switch between these pages by swiping horizontally. A PagerAdapter dynamically provides these pages which can be just views or fragments. However the ViewPager is not an AdapterView like the ListView or the GridView. Therefore you need to implement a specific adapter class in order to use the ViewPager class.

The following video shows a ViewPager with different colored pages:

Adapter using fragments

The easiest way to write an adapter for a ViewPager is to use fragments and let your adapter implementation extend the FragmentPagerAdapter class. You only need to implement getItem(int position) to return a fragment for the page at the given position and getCount() to return the number of pages to display.

The following implementation shows the FragmentPagerAdapter used for the video above:

SampleFragmentPagerAdapter.java

Saving fragment states

When using a FragmentPagerAdapter and swiping through the pages the ViewPager may eventually have created fragments for all the pages. Depending on the number of pages this may need a large amount of memory just for holding all the offscreen pages. To solve this problem the support library offers the FragmentStatePagerAdapter class. This adapter will destroy fragments not visible to the user when needed. Whenever this happens the adapter saves the fragment's current state using onSaveInstanceState(Bundle outState) of the fragment class to restore it when the fragment for this page gets recreated.

Implementing an adapter extending the FragmentStatePagerAdapter is exactly the same as when using the FragmentPagerAdapter class. Just your fragment needs to take care of saving its state when getting destroyed. Take a look at the documentation for an example on how to retain the state of a fragment.

Adapter using views

You can also use the ViewPager with only View objects as pages if using fragments isn't an option for you. It's a bit more tricky to implement the adapter as you'll have to directly extend the PagerAdapter class.

The following example creates an adapter that shows a number of different colored pages like the FragmentPagerAdapter implementation above.

SamplePagerAdaper.java

As you can see you need to write some boilerplate code to add and remove the views to the pager. I published a simple ViewPagerAdapter class on GitHub that does all this for you so that you don't need to write much more code than when using fragments:

SamplePagerAdapter2.java

Displaying the camera preview - Instant Mustache #5

2012-10-18T19:28:00.003+02:00

In the first articles we decided to use a square ratio for the preview. After some testing around it seems the emulator is the only "device" that supports a square sized camera preview and picture size out of the box. To work around this issue we would need to use a widely supported ratio (4:3) and crop the preview picture as well as the taken photo ourselves. To keep the code and the first version of the app small (and to follow the Minimal Marketable App principle) I decided to change this requirement. We will use the commonly supported ratio of 4:3.

We implement onMeasure() to set the dimension of the view to a 4:3 ratio:

onMeasure() - CameraPreview.java

Setting up the camera

Even though we know our desired ratio we can't just set a size via camera.setParameters(Camera.Parameters). Instead we have to query the Camera.Parameters object we get from getParameters() to retrieve a list of supported preview and picture sizes. Then we have to scan this list for a size that has our desired ratio. This is what determineBestSize() does:

determineBestSize() - CameraFragment.java

We are using a threshold for the preview and picture size to save some heap space for the bitmap transformations we'll do later. For now these limits are 640x480 for the preview size and 1280x960 for the picture size.

Finally the determined values are used to setup the camera object:

setupCamera() - CameraFragment.java

The CameraPreview component will be used as view of our CameraFragment by returning it in onCreateView(). In addition to that our CameraFragment needs to implement SurfaceHolder.Callback in order to get notified when the surface is created or destroyed.

Accessing the camera

To access the camera of the device we need to call Camera.open(int cameraId) to obtain a Camera object. The camera ids are numbered starting with 0. As we currently don't want to support multiple cameras we will just call Camera.open(0).

Unfortunately using the camera can cause undefined exceptions to be thrown. Therefore we need to wrap some code accessing the camera object into try-catch blocks and catch the generic Exception object. This is usually considered bad practice but in this case encouraged to do by the documentation.

Sharing the camera resource

The camera can only be used by one application at a time so we need to release the camera every time the activity gets paused. Otherwise the user would not be able to use other camera applications while our activity is in the background. In some cases not releasing the camera can lead to the CameraService crashing. If this happens no camera application can be used until the user reboots his phone. We never want this to happen.

To be safe we will open the camera by calling Camera.open() in the onResume() method of the CameraFragment and releasing it again in onPause().

Once we have a Camera object and our surface is created we can assign the surface to the camera object and start the preview. We wrap the call to startPreview() in our own method called startCameraPreview() inside our fragment. This way we can setup the camera object before actually starting the preview.

startCameraPreview() - CameraFragment.java

Determining the display orientation

The screen can be rotated in four different angles (0°, 90°, 180°, 270°). In addition to that the camera can also be built into the device in four different angles by the manufacturer. Finally the camera can be on the front or on the back of the device. We will need to get all these angles and tell the camera object the display orientation so that the preview will be drawn on the surface using the right rotation.

This sounds tricky but fortunately there's a code snippet for that in the Android documentation. We'll use this code snippet to implement determineDisplayOrientation().

Screenshot

And that's how our app looks like so far:

As always the source code of the current version of the app is available at Github.

Using a fragment for the camera preview - Instant Mustache #4

2012-10-15T19:28:00.002+02:00

Fragments can be reused in different activities and layouts. Therefore they are perfect building blocks for composing UIs for different screen sizes.
They encapsulate the code for a specific component including the layout of the component. This makes the activity code and layout much more simpler and cleaner. By using a bunch of fragments the activity basically only has to handle events and delegate them to the appropriate fragments. This leads to the activity becoming some kind of light meta controller instead of an unreadable dumping ground for handling everything on the current screen.
Fragments can be dynamically added, removed, replaced, added to the back stack, animated and other cool things that can be painful to do yourself.

Activity layout

As said before we are moving the camera preview code and layout to a fragment. Therefore our activity's layout is really quite simple:

activity_camera.xml

Communication between activity and fragment

There are situations where the fragment needs to notify the activity about events. In our case the fragment needs to tell the activity when it's unable to instantiate a camera preview so that the activity can handle this error case. Of course we could just access the activity inside the fragment using getActivity() and cast it to a CameraActivity object to get access to a method like onCameraError() but then our fragment would only be usable with this particular activity:

CameraActivity activity = (CameraActivity) getActivity();

activity.onCameraError();

We work around this issue by defining an interface that has to be implemented by the CameraActivity and every other component that wants to use the CameraFragment:

CameraFragmentListener.java

Every time our fragment gets attached to an activity onAttach() will be called with the activity as parameter. We use this method to enforce that the activity implements our defined interface:

CameraFragment.java

Finally take a look at the CameraActivity source code on GitHub. It just sets the layout in onCreate() and shows a toast in case of the fragment calling onCameraError(). As this method will be called in case of non-recoverable errors we'll also finish the activity.

Know your resources: Integers and Booleans

2012-08-20T19:02:00.001+02:00

An Android application isn't only code but comes with a bunch of resources. Probably the most important resources (besides layouts and drawables) are the string resources. In conjunction with the resource qualifiers they are not only perfect to externalize strings for localization but also for defining different internal configurations of your app.

However sometimes string resources are overused. Especially when they are used to define boolean or integer values. Let's look at the following example. Code lines like the next ones can be found in several Android projects. For example you can find some of these in Yaaic.

Loading string resources and parsing as boolean or integer

Or even worse in a condition without casting, doing a string comparison:

Loading boolean as string resource and doing string comparison

The code above is not wrong but instead of using string resources and parsing or comparing them it would be easier to use resources of the appropriate type. Fortunately Android allows to define boolean and integer resources too (since API level 1). It's basically the same process as defining a string resource in XML just use the bool and integer tags:

Defining boolean and integer resources in XML

After that you can access these resources in code. However there are no alias methods on the Context object like for string resources. Therefore you need to get a Resources instance first and then ask it for the defined resources.

Accessing integer and boolean resources from code

Let's start coding ... NOT! - Instant Mustache #3

2012-08-01T21:01:00.002+02:00

The camera screen (CameraActivity)
The first screen the user will see after launching the app will be the camera screen. There are two main components we need: A camera preview and a button to take a photo. In addition to that we may want to reserve some space for future features like switching between cameras and mustaches.

Let's take a look at the the final version of the camera screen as I've drawn it:

CameraActivity

The following decisions I've made during drawing and experimenting:

I want the app to have an ActionBar. To be consistent I also want the ActionBar in the camera screen. I don't know yet if it's useful to show the app title "Instant Mustache" in the ActionBar as I've drawn it. It's quite long and may take up too much space. Furthermore the overflow menu drawn here may not be visible as we have no menu entries defined yet.
The camera picture will be a square. We'll have to define a picture ratio and a square may fit quite nice into the screen. The darker areas on the screen will grow or shrink depending on the screen size of the device and always center the camera preview.
There will be a bar at the bottom of the screen which will house the button for taking a picture. Here we will have enough space for adding more functionality in later releases.
Almost all activities showing a camera preview are fixed in their orientation. While moving the phone around to take a photo you don't want the phone to destroy the current activity, do the rotation and re-create the activity. Especially because the camera picture will be oriented correctly anyways because you are rotating the camera inside the phone as well. To satisfy the previous points we will fixate the orientation to portrait mode.

The photo screen (PhotoActivity)
After taking a photo you will see another screen showing the photo you've taken and you'll have the option to share the photo with other apps on your phone.

That's how my final version of the photo screen looks like:

PhotoActivtiy

The first version of this screen will be really simple:

At the top we'll have the ActionBar again. To share the photo we'll add a ShareActionProvider that shows a list of available share targets as well as the most used app as an icon right beside it.
Below the ActionBar we'll show the taken photo and that's everything for now.

What's next?

Now we've defined how our two screens will look like. In the next article we are going to launch our IDE and start writing the CameraActivity. I am curious to know what you think about the UI as described here and if you have other ideas. Let me know in the comments or on Google+.

Minimal marketable app - Instant Mustache #2

2012-07-03T20:08:00.003+02:00

This article is part of a series of articles about the development process of Instant Mustache, a fun camera app that adds mustaches to all faces using face detection. Click here to get a chronological list of all published articles about Instant Mustache.

In the last article I described roughly the idea behind Instant Mustache. Now it's time to get more concrete. While doing so we try to follow the principle of the minimal marketable feature (MMF).

Minimal marketable feature
The idea behind the minimal marketable feature is to strip all aspects of a feature that are not necessarily needed to end up with a useful (or marketable) feature. After that you'll end up with smaller features that are easier and faster to develop. This is only a very rough explanation of MMF. You can find a way better Introduction to Minimum marketable feature at the upstart blog.

Minimal marketable app
In this case we are slightly modifying this idea to end up with something like a minimal marketable app. This means we are going one level higher and strip all features that are not essentially required for a first releasable app. This does not mean that we won't develop these features at all but our first version will be without them enabling us to ship the app as early as possible.
Let's continue with an example. When you think about the app (see first article) you will very fast come up with an idea like: The user should be able to select between a bunch of mustaches - more mustaches = more fun. But do we really need this feature when we launch the app? No, we don't. Our fun app will still be fun with one single mustache. Of course this is one of the first features we should have in the next release after the initial one.

Another feature that's easy to come up with is switching between the cameras of a device. In most cases this means switching between back and front camera. Again for our basic app it's totally acceptable to strip this feature in the first release. The users of our app won't be able to take pictures of themselves easily and therefore they won't have much fun when there's no mustache-less friend to photograph around. Therefore we should rank this feature high as well to implement it right after the first release.

In our case the minimal marketable feature set is an app that has two screens: A camera screen - with a camera preview and a button to take a picture - and a second screen that shows the picture you took and has an option to share this picture. The camera preview will show a live preview. Every detected face on the live preview will automatically have a mustache overlayed. If you take a picture the second screen will show the composed picture including the added mustaches. The user will be able to share the picture via the Android intent system.

Roadmap and Milestones
Nothing is more motivating than playing around with what you have created. In contrast nothing is more killing motivation than programming for ages without coming up with something that runs at all. This leads us to the goal to always have a running prototype that step by step gets features added until it's ready to ship. So let's break the functionality into parts that can be implemented in order and always leave us with a working prototype that we can deploy on our phone and use at the next party.

Milestone #1: A camera screen that shows the camera preview and has a button to take a photo. The photos will be saved on the SD card. After that we will end up with a basic camera app that we can use to take photos on the go. Goodbye native camera app!
Milestone #2: We add the second screen. After taking a photo we’ll switch to this second screen which shows the taken photo and has an option to share the photo.
Milestone #3: It’s time to add the face tracking. We’ll use the face tracking and display mustaches for every face on top of the camera preview.
Milestone #4: When taking a photo we’ll compose the final photo using the information of the face tracking. The composed photo will contain mustaches like the preview screen before. The composed photo will be saved on the SD card and shown in the second screen. We are ready to release!

Creating a MarqueeLayout with the Android Animation System

2012-06-08T12:14:00.002+02:00

When I posted the article about the hidden BlinkLayout inside Android’s LayoutInflater Thierry-Dimitri Roy wrote on Google+:

That’s a challenge I accept! Back in the days when I worked at Jimdo we developed “a lifeboat for GeoCities” which allowed users to migrate their GeoCities website to Jimdo before GeoCities finally shut down in 2009. So I’ve some kind of heart for GeoCities users.

The view animation system of Android makes it quite easy to develop something like a MarqueeLayout. All we need to do is to extend an existing ViewGroup and attach a marquee-like animation to every instance.

The TranslateAnimation does already exactly what we need: It moves a view from a starting position to an ending position. The two positions can either be declared absolute (position on the screen) or relative to the view or its parent. After that we only need to define the duration of the animation and Android will do the rest for us.

We'll define the start and end positions of the animation by using coordinates relative to the view. When using relative coordinates you can think of our view having a size of 1x1 and it's top left corner placed at (0,0).

View of size 1x1 at position (0,0)

If our view's width stretches to the whole width of the screen we can consider the screen's size also 1 (relative to the view's width).

View (green) filling full width of screen (grey)

Assuming a screen size of 1 and a starting position on the right side outside of the screen gives us a relative starting position of (1,0). This will place our view exactly outside the screen (or it's parent).

View animation starting at (1,0)

The view should move from the starting position to the left until it's outside of the screen at (-1, 0).

View animation stopping at (-1,0)

The animation system will generate all transient positions needed for the animation. Given all the information above we can write a simple MarqueeLayout in a few lines:

MarqueeLayout.java

That's what our MarqueeLayout looks like when adding a TextView to it:

The following code was used to set up an activity using our MarqueeLayout:

MarqueeLayoutActivity.java

Instant Mustache #1 - The idea

2012-06-05T20:33:00.000+02:00

This is a rough idea every developer can come up with. In the following postings we will refine the idea, plan the app with some basic wireframes and develop an elementary version that can be extended to match our planned full-featured app later.

Do not forget the napkin

Of course as a good entrepreneur we had this world-changing idea on the go and had only time to sketch it on a napkin to not forget it later.

So here is the napkin we came up with:

The curious BlinkLayout

2012-05-27T19:01:00.002+02:00

While reading the source code of Android's LayoutInflater class I found a hidden gem that seems to be quite unnoticed yet. Ladies and gentlemen I present you the mighty BlinkLayout. Views that are placed inside this ViewGroup blink at a rate of 500ms.

The BlinkLayout is an inner class of the LayoutInflater and can therefore only be used in a XML layout that will be parsed by a LayoutInflater instance. Due to the implementation it's only possible to use it as root node using the <blink> tag inside a XML layout.

It seems like the BlinkLayout is available since Android 4.0 and isn't used in the Android source code I observed. Maybe it was added for debugging reasons and was forgotten later.

The video above shows the BlinkLayout in action using the following layout XML:

main_layout.xml

The following snippet was used to inflate the layout and pass it to the activity:

BlinkLayoutActivity.java