Logcat

Dealing with Android layout xml files can be a bit daunting at first. It definitely takes some time to learn the ins-and-outs of layout parameters to get your UI looking just right. We previously discussed how to decide whether you should use RelativeLayout or LinearLayout. Now we’ve compiled an overview of basic layout attributes and how to use them.

First of all, layout attributes that start with “layout_” have to do with a View’s LayoutParams, which are used by views to tell their parents how they should be laid out. Now let’s take a look at some of the more commonly used attributes.

layout_width and layout_height

These two are without a doubt the most common layout parameters you will encounter. In fact, these attributes are required on every view, and define the width and height of the view. For these attributes, the most common used values are “match_parent”, which sets that dimension to be as big as its parent’s, and “wrap_content,” which sets the dimension to just enough to wrap the content. You may also be familiar with “fill_parent” which was deprecated in favor of “match_parent” at API Level 8. You can also set either to specific values such as “40dip”. Here are few examples of a simple layout with a TextView with different values for layout_width and layout_height.

layout_gravity and gravity

These two attributes can be incredibly confusing, but remember that the one with layout_ is a part of the LayoutParams, which deals with the view and its parent. So layout_gravity defines how the view is positioned in its parent, while gravity defines how content is positioned within the view itself. You can set gravity to any of these values. In RelativeLayout, rather than using layout_gravity, you can use the RelativeLayout-specific attributes, which will be described later.

In the below example, setting gravity=”center” on the vertical LinearLayout centers all the views vertically inside the LinearLayout. Setting layout_gravity=”right” on the green TextView makes it right-aligned. In the orange TextView, you can see that setting gravity in a TextView aligns the TextView contents, which is the text itself. For a more comprehensive explanation of how this works, check out this blog post, which has a great visual of layout_gravity and gravity.
layout_margin and padding

Margin specifies extra space outside of the view, similar to the idea of css margins. You can either specify layout_margin which will assign the value to all four sides of the view, or you can specify each side separately using layout_marginTop, layout_marginBottom, layout_marginRight and layout_marginLeft.

Padding specifies extra space inside the view, on any or all of the four sides. You can specify padding all around the view at once with padding or each side individually using paddingTop, paddingBottom, paddingLeft, and paddingRight. Here is an example with the same basic “Hello World” TextView with different values set for padding and layout_margin.
layout_weight

This layout parameter is used only in LinearLayouts and allows you to assign importance to child views within a LinearLayout. For example, if you have a few views in a horizontal LinearLayout, you can use layout_weight to specify how you want them to take up extra space. For example, the first image below shows three TextViews, each with layout_width=”wrap_content” and no layout_weight set (default value is 0). Below that, you can see how the layout_weight values determines how the views take up extra space in the LinearLayout.
RelativeLayout-specific attributes

RelativeLayouts have a set of rules that helps determine where to place child views in the RelativeLayout.

layout_alignParent[Top/Bottom/Left/Right] specifies the view’s alignment within the parent. For example, layout_alignParentRight=”true” would align the view with the right edge of the parent.

Another useful set of rules for aligning views with respect to one another (rather than the parent) is layout_to[Right/Left]Of and layout_above and layout_below. These are set to the id of another view and will position the view appropriately with respect to the referenced view.

The last set of RelativeLayout rules is layout_align[Bottom/Top/Left/Right]. These allow you to align an edge of the view with the corresponding edge of another view.

Here is an example that uses several of these rules:

Note: be careful of circular dependencies! For example, as noted in the documentation, you can’t have a RelativeLayout that has layout_height=”wrap_content” and a view within it that has layout_alignParentBottom=”true”.

Setting Layout Attributes Programmatically

Setting these attributes in xml is pretty straightforward, but it gets a little tricky when you set them programmatically. Here are some basic guidelines.

For any attributes that have to do with the view’s LayoutParam, you have to get the LayoutParam and set the values on it. Be sure to cast it to the appropriate LayoutParams depending on the parent view. For example, for a TextView within a LinearLayout:

If the view is in a RelativeLayout, you will have to cast the LayoutParams to RelativeLayout. You can then set RelativeLayout-specific rules using addRule(), like so:

For other attributes that are not related to LayoutParams, you can set it directly on the view:

Hopefully this overview of most-commonly used layout attributes is helpful, especially if you are just getting started with Android xml layouts. If you have any tips you’ve found to be especially helpful, feel free to chime in with a comment!

When AsyncTask was introduced to Android, it was labeled as “Painless Threading.” Its goal was to make background Threads which could interact with the UI thread easier. It was successful on that count, but it’s not exactly painless – there are a number of cases where AsyncTask is not a silver bullet. It is easy to blindly use AsyncTask without realizing what can go wrong if not handled with care. Below are some of the problems that can arise when using AsyncTask without fully understanding it.

AsyncTask and Rotation

AsyncTask’s primary goal is to make it easy to run a Thread in the background that can later interact with the UI thread. Therefore the most common use case is to have an AsyncTask run a time-consuming operation that updates a portion of the UI when it’s completed (in AsyncTask.onPostExecute()).

This works great… until you rotate the screen. When an app is rotated, the entire Activity is destroyed and recreated. When the Activity is restarted, your AsyncTask’s reference to the Activity is invalid, so onPostExecute() will have no effect on the new Activity. This can be confusing if you are implicitly referencing the current Activity by having AsyncTask as an inner class of the Activity.

The usual solution to this problem is to hold onto a reference to AsyncTask that lasts between configuration changes, which updates the target Activity as it restarts. There are a variety of ways to do this, though they either boil down to using a global holder (such as in the Application object) or passing it through Activity.onRetainNonConfigurationInstance(). For a Fragment-based system, you could use a retained Fragment (via Fragment.setRetainedInstance(true)) to store running AsyncTasks.

AsyncTasks and the Lifecycle

Along the same lines as above, it is a misconception to think that just because the Activity that originally spawned the AsyncTask is dead, the AsyncTask is as well. It will continue running on its merry way even if you exit the entire application. The only way that an AsyncTask finishes early is if it is canceled via AsyncTask.cancel().

This means that you have to manage the cancellation of AsyncTasks yourself; otherwise you run the risk of bogging down your app with unnecessary background tasks, or of leaking memory. When you know you will no longer need an AsyncTask, be sure to cancel it so that it doesn’t cause any headaches later in the execution of your app.

Cancelling AsyncTasks

Suppose you’ve got a search query that runs in an AsyncTask. The user may be able to change the search parameters while the AsyncTask is running, so you call AsyncTask.cancel() and then fire up a new AsyncTask for the next query. This seems to work… until you check the logs and realize that your AsyncTasks all ran till completion, regardless of whether you called cancel() or not! This even happens if you pass mayInterruptIfRunning as true – what’s going on?

The problem is that there’s a misconception about what AsyncTask.cancel() actually does. It does not kill the Thread with no regard for the consequences! All it does is set the AsyncTask to a “cancelled” state. It’s up to you to check whether the AsyncTask has been canceled so that you can halt your operation. As for mayInterruptIfRunning – all it does is send an interrupt() to the running Thread. In the case that your Thread is uninterruptible, then it won’t stop the Thread at all.

There are two simple solutions that cover most situations: Either check AsyncTask.isCancelled() on a regular basis during your long-running operation, or keep your Thread interruptible. Either way, when you call AsyncTask.cancel() these methods should prevent your operation from running longer than necessary.

This advice doesn’t always work, though – what if you’re calling a long-running method that is uninterruptible (such as BitmapFactory.decodeStream())? The only success I’ve had in this situation is to create a situation which causes an Exception to be thrown (in this case, prematurely closing the stream that BitmapFactory was using). This meant that cancel() alone wouldn’t solve the problem – outside intervention was required.

Limitations on Concurrent AsyncTasks

I’m not encouraging people to start hundreds of threads in the background; however, it is worth noting that there are some limitations on the number of AsyncTasks that you can start. The modern AsyncTask is limited to 128 concurrent tasks, with an additional queue of 10 tasks (if supporting Android 1.5, it’s a limit of ten tasks at a time, with a maximum queue of 10 tasks). That means that if you queue up more than 138 tasks before they can complete, your app will crash. Most often I see this problem when people use AsyncTasks to load Bitmaps from the net.

If you are finding yourself running up against these limits, you should start by rethinking your design that calls for so many background threads. Alternatively, you could setup a more intelligent queue for your tasks so that you’re not starting them all at once. If you’re desperate, you can grab a copy of AsyncTask and adjust the pool sizes in the code itself.

By far the most commonly used ViewGroups in Android are LinearLayout and RelativeLayout. LinearLayout aligns multiple views horizontally or vertically; RelativeLayout aligns its child Views in relation to each other (or itself). There are other, more specialized ViewGroups (such as FrameLayout, TableLayout, or GridView) but the bulk of your hierarchy will be a mixture of LinearLayouts and RelativeLayouts.

They are similar in function so the question of which to use regularly comes up. Both have their use cases, and neither of them are appropriate all of the time. Problems which can be difficult using one layout can be a breeze with the other but it’s not always obvious which is correct.

This article will help guide you towards the right choice of layout for your hierarchies. Here are a few guidelines for usage, which I will go into more detail below:

• Use whichever layout requires the fewest Views (typically RelativeLayout).
• Views layered on top of each other is RelativeLayout’s job.
• Dynamically sizing multiple Views inside of a layout is done with LinearLayout.
• Keep in mind how your hierarchy will work with different content and screen sizes.
• All other things equal, LinearLayout is preferable due to its ease of use.

The Fewer Views, the Better

The number one goal for your layouts should be using the fewest number of Views possible. The fewer Views you have to work with, the faster your application will run. Excessive nesting of Views further slows down your application.

A RelativeLayout hierarchy will typically use fewer Views and have a flatter tree than a LinearLayout hierarchy. With LinearLayout, you must create a new LinearLayout every time you want to change the orientation of your views – creating additional Views and a more nested hierarchy. As a result, it is recommended that you first use RelativeLayout for any layout that has any complexity. There is a high probability you will reduce the number of Views – and the depth of your View tree – by doing so.

As a reference, there is an excellent Android article on creating efficient layouts (which goes into more detail about reducing View usage). Here is a simpler version of their example:

Here is an abbreviated version of this layout using LinearLayouts. It requires two LinearLayouts and has a maximum depth of 3 (full source code):

However, this version (using RelativeLayout) can do the same with fewer Views and a max depth of 2 (full source code):

That said – don’t try to force yourself to use nothing but RelativeLayout! There are situations where LinearLayout is a better solution, even if it uses a few more Views.

Layer Views with RelativeLayout

Sometimes you will want Views to be overlap each other. In those situations, RelativeLayout is a natural candidate over LinearLayout. There are two ways to align Views on top of each other with RelativeLayout. The first is to align the Views in relation to the parent (either by centering them, or by aligning them to the parent’s edges). The second is to align Views’ edges with each other. The example below uses both:

(Source code)

(Note: While you can technically layer Views with a LinearLayout via negative layout margins, RelativeLayout is almost always the right choice because it is better designed for it.)

Dynamically Weight View Sizes with LinearLayout

LinearLayout has a unique and useful layout parameter, layout_weight. With it you can size the Views inside of a LinearLayout in relation to each other – such as having two Buttons side by side, where one takes up 1/3rd the screen and the other takes up 2/3rds the screen.

(Source code)

RelativeLayout has no such facilities. On some level, its Views must have set bounds – whether it be set in itself, set in relation to other Views, or the parent itself. Its Views can expand and contract, but only in reaction to its bounds changing.

Consider the Extremes

Sometimes the choice of layout will be determined on the extreme circumstances of your hierarchy. “Extreme circumstances” can be anything from the content in your Views being unexpectedly large (lots of text in a TextView, an extra large bitmap in an ImageVIew), or the viewport being much smaller or larger than you had anticipated (an ldpi screen, a tablet, or even just the difference between portrait/landscape orientations).

Let’s look at a simple example – two TextViews, each in one of the corners of the screen. What happens with a naive RelativeLayout solution when the text inside of them becomes too long?

(Source code)

You can account for this problem by making sure they won’t overlap, but you can’t control how much of the width each View gets in this case – say, if we want both to take up at most half of the screen. To do that, you’ll end up using a LinearLayout:

(Source code)

I cannot give much advice since you’ll need to handle these on a case-by-case basis – but it’s something to consider while first planning your hierarchy. You may be surprised by how often you fall back to LinearLayout, though, to solve problems with extremes.

For Simple Hierarchies, Use LinearLayout

LinearLayout is easier to use than RelativeLayout. If your hierarchy is simple enough that it can be contained within a single LinearLayout, then there’s no reason to complicate things – just use LinearLayout. This advice applies whether the LinearLayout is the root view, or if you need to group a few Views further down the hierarchy.

Conclusion

Ultimately, the decision between LinearLayout and RelativeLayout is up to you. The rules above are just rough guidelines. There may be cases which are not covered that necessitate one or the other. Or it may be significantly easier to use a few LinearLayouts instead of one RelativeLayout and performance won’t be significantly affected by it.

You should focus your time on the hierarchies that matter the most. If you’ve only got a few Views on the screen and you could use either RelativeLayout or LinearLayout, take your pick. But if you’re working with a ListView row, you’ll want to reduce your View usage as much as possible for performance.

Good luck with making your hierarchies as effective as possible! If you want to play around with any of the code from this article, you can find the source code for the samples here.

In Android, the three default font options are monospace, sans serif and serif. You do have some flexibility with adding effects to the default fonts, but without custom fonts, you are pretty limited in how text in your Android appears to your users. Luckily, it’s fairly straightforward to set a custom font. You can find plenty of free custom fonts at sites like dafont.com – just download the .ttf file for the font of your choice, and add it to the assets/fonts directory of your codebase (create the directory if it doesn’t exist already).

Custom Fonts in Views

That’s it! Now you can easily set custom fonts for views in xml.

Custom Fonts in WebViews

Using custom fonts gives you a lot more control over the visual appearance of your application, but when don’t get carried away — using too many random fonts can make an app seem very disjointed. In general, try to use at most a few fonts that go well together. To get you started, here are 40 free designer fonts.

JSON (JavaScript Object Notation) is one of my preferred data formats for Android.  It is a wonderful mixture of ease-of-use, compactness and speed. You can use it to pass data between Activities (much easier than Parcelables, but for most cases not prohibitively slower), store data on the disk (easier than setting up an SQLite database for small amounts of data), or transfer data to and from your application to the internet (and quite compact when combined with gzip).

In this post, we’ll examine the different ways you can handle JSON, their relative strengths and weaknesses, as well as some examples to get you started.

Three Ways of Handling JSON

There are three basic methods for handling JSON:

Tree Model – The JSON document is a mutable in-memory tree.  There is a built-in org.json package that uses the tree model (via JSONObject and JSONArray).

Streaming – The JSON document is read and written in a streaming fashion.  In Honeycomb, JsonReader and JsonWriter were introduced as the streaming solution for handling JSON.  (If you want to use this library pre-Honeycomb, you can download the google-gson-streaming library, which has the same classes.)

Data Binding – Automatic conversion between JSON and a POJO (Plain Old Java Object).  There is no built-in Android functionality for this method, however there are plenty of libraries out there.

The primary battle between the tree model and streaming is memory vs. ease of use.  The tree model can run into memory problems: not only does the entire JSON document need to be in memory, but you can end up storing unnecessary data you don’t need.  In some situations you will have duplicates of the data in memory (e.g., if you convert the tree to Java objects or vice versa). On the other hand, it is much easier to read and manipulate data via a tree model since the entire object is held in memory; with streaming, you have to hand-hold the data closely.

As a secondary concern, streaming tends to be faster than the tree model.  For most situations this won’t be consideration – if you need speed, chances are you’re already parsing so much data that you’d be using streaming anyways out of memory concerns.

Data binding is convenient, but it’s not as flexible as the tree model nor as fast as streaming. Additionally, it does not save much effort – you still have to write the code to map JSON to a POJO. I think there is potential to make data binding much easier by automatically generating POJOs from a JSON template – thus justifying its deficiencies in comparison to the other methods – but I do not know of a library that does this yet.

I will not be covering data binding since Android has no built-in API; you’ll have to find a library on your own that utilizes it and read their documentation, as the implementation differs in the varying libraries.

Using JSONObject and JSONArray (Tree Model)

Here is a sample JSON object that we want to parse:

With the tree model, initial parsing is simple:

To read data, you can either use getX() or optX() (where X is the data type).  The difference between the two is that getX() requires the field to be there and will throw exceptions if the field does not exist.  As a result, I typically use optX() methods with fallbacks:

Reading JSONArray data is similar, except you reference indices instead of fields.

To write the above JSON using the tree model, you can just create a JsonObject then start placing data into it.  Once you’re done, you can use JsonObject.toString() to write out the JSON document as a String:

putOpt() only inserts an entry when both the name and the value are non-null.  This creates a handy shorthand so you don’t have to null-check data in variables before putting them into a JsonObject.

Using JsonReader and JsonWriter (Streaming)

Streaming parsing of JSON via JsonReader is more complex.  First, you need to create a Reader for the constructor based on your input (String, InputStream, etc.):

The JsonReader works by iterating through field names/values and parsing each one by hand. You also have to explicitly tell the JsonReader when an object or array has begun. Parsing the JSON above uses a standard JsonReader pattern for parsing objects:

Two things to pay attention to: JsonReader.peek() lets you take a look at the type of the value, which is helpful in parsing to avoid parsing null values (or when there are multiple potential data types in a field).  JsonReader.skipValue() lets you skip a field and all its children, which is not only required for ignoring fields you don’t want to parse but also speeds up parsing by allowing you to skip parts of the data.

JsonWriter is very similar to JsonReader.  First you create a Writer to write your data to, then you explicitly declare objects and arrays and place data into them:

Other JSON Libraries

The built-in JSON handlers are not the best or the brightest.  The org.json library lacks a streaming read/write method (which creates extra memory headaches) and the google-gson JsonReader/JsonWriter are not the fastest streaming JSON solutions.  Their main advantage is that they are built-in – no need to include extra libraries that increase the APK size.

Luckily there are plenty of good, free, open source alternatives out there.  Keeping in mind that benchmarks can be misleading, the jvm-serializers project does a good job of comparing the relative speeds of different JSON parsers.  You can also use the page as a reference to check out feature sets of each library.

Personally, I have used Jackson to great success, parsing through large amounts of data efficiently and would recommend it if you are looking for a high-performance JSON reader/writer.  Additionally, its library is very similar in nature to the built-in Android APIs and so it’s not difficult to adapt your code if you want to switch to it at a later date.