Tag Archives: Android

Tidbits

Just some interesting bits and pieces I have come across recently:

Flat UI Colors: a neat website that displays a colour palette, allowing you to click on a colour to copy its value to the clipboard. #design

ColorHex #android App: a simple colour picking app that that also allows one to store favourite colours. #design

Butter Knife: an interesting view injection framework for #android, created by Jake Wharton who also developed the ActionbarSherlock framework.

Latest Android Dashboard Stats: personally, I was surprised to see that as much as 9.9% of devices still fall under the small, ldpi configuration. #android


#programming #object-orientation

I recently did a bit of a refresh on some principles and guidelines for object orientated programming:


#server-side

I spent a bit of time recently developing a simple REST web-service using Google go and Google App Engine. Here are some useful links and examples:

  • Gorca: a utility package for RESTful go applications on App Engine.
  • Home: a simple App Engine application using go and Angular JS.
  • RESTful web-services in go: useful information on developing RESTful web-services using Google go.

Anyone interested in developing web-service APIs that need to be consumed by mobile apps and the web, should definitely have a look at Google Cloud Endpoints… I also played around with this cool feature for Java and below are some useful links:

Webbits: a silly Android app for testing embedded web content.

Recently I found myself working with some server-side web content that would ultimately need to be pulled into an embedded browser within an Android app. Depending on the device, the embedded browser within the app could be of variable size, so the content being pulled would have to display properly.

I wanted a means to test the content within an embedded browser of different sizes, so I looked around (not for very long) for a test app that could help me out; after a little bit of looking and not finding what I wanted, I decided to just write my own silly app, called Webbits.

The app supports both phone and tablet and essentially allows a user to specify the dimensions of the embedded browser (WebView) and the URL to load. It’s very basic but did exactly what I needed. Below are some screenshots of Webbits:

Screenshot_2013-07-05-13-17-49

Phone portrait

device-2013-07-04-183752

Tablet landscape

device-2013-07-04-183939

Developed by 2bits, of course.

Hopefully, someday, somebody else may find this useful.

Android WebView flicker when using hardware acceleration on Android 3.0+

There is an Android bug where WebViews may present an ugly flicker when being used on 3.0+ devices with Hardware Acceleration enabled. I was busy with an update to an Android app I’m working on which makes use of a WebView that slides in and out (using this awesome Sliding Menu library), when I noticed the *delightful* surprise when sliding the WebView back in:

Not ideal, is it?

Not ideal, is it?

As much as I can’t believe this kind of bug still exists, especially considering it seems to have been around for some time, it lives with us and thus we need to use some kind of workaround.  I immediately turned to SO for help and found a possible workaround:

WebView “flashing” with white background if hardware acceleration is enabled (Android 3.0+)

The workaround involves using a method that is only available from API level 11 (HoneyComb), and considering my app is targeting a minimum level of 8 I used the following code:

/**
 * Initializes the WebView:
 * - Configures the WebView settings
 * - Adds a WebViewClient
 * - Custom config of the webview
 */
@TargetApi(Build.VERSION_CODES.HONEYCOMB)
private void initWebView()
{
	// Other init code
	
	if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB)
	{
		// This is added as a work-around for the flicker which occurs in Android 3.0+
		// when hardware acceleration is enabled:
		// http://stackoverflow.com/questions/9476151/webview-flashing-with-white-background-if-hardware-acceleration-is-enabled-an
		getWebView().setLayerType(View.LAYER_TYPE_SOFTWARE, null);
	}
}

So pick your poison: reduced performance or flickering?

Android WebView Scaling

Just as it’s important for an Android developer to understand how to support multiple screen sizes, so too is it important to understand how the Android framework handles the scaling of the content in a WebView.

To demonstrate the scaling that takes place within a webview, I’m going to use a basic example of a webview that displays a local image and some text underneath it – as some additional information, the device used in this example is a Galaxy Nexus with an xhdpi screen (320 dpi) and resolution of 1280×720. Below is the HTML and CSS used and the result of the app run on the said device:

<html>
    <head>
        <link rel="stylesheet" type="text/css" href="sample.css" />
    </head>
    <body>
        <img src="localImage.png"/>
        <p>
            Lorem ipsum dolor sit amet, consectetur adipisicing elit<br>
            bla bla bla
        </p>
   </body>
</html>

the CSS…

img
{
    display: block;
    margin-left: auto;
    margin-right: auto;
}

p
{
	background-color: #E4E4E4;
	padding:1em;
	margin:0.5em;
	border-radius: 15px;
	font-size: 1em;
}

and finally the result…

Web content with default scaling.

Web content with default scaling.

Immediately it becomes obvious that the 300×200 local image has been scaled up considering the resolution of the device. Essentially what the Android framework is doing is assuming that the web content is targeted at an mdpi density (which Android treats as the base density), and as a result scales the content up accordingly for the xhdpi test device so that the drawn elements match the physical size they would appear on an mdpi display. Unless you explicitly specify the density you are targeting, Android will scale up/down accordingly.

To adjust the scaling performed by the Android framework, one can use the viewport meta tag to specify properties regarding screen density support:

<meta name="viewport" content="target-densitydpi=device-dpi" />

The Android docs explain the target-densitydpi property as follows:

You can use this to specify the target density for which the web page is designed, using the following values:

  • device-dpi – Use the device’s native dpi as the target dpi. Default scaling never occurs.
  • high-dpi – Use hdpi as the target dpi. Medium and low density screens scale down as appropriate.
  • medium-dpi – Use mdpi as the target dpi. High density screens scale up and low density screens scale down. This is also the default behavior.
  • low-dpi – Use ldpi as the target dpi. Medium and high density screens scale up as appropriate.
  •  – Specify a dpi value to use as the target dpi (accepted values are 70-400).

So if we use this information and modify our HTML to prevent default scaling:

<html>
    <head>
        <link rel="stylesheet" type="text/css" href="sample.css" />
        <meta name="viewport" content="target-densitydpi=device-dpi" />
    </head>
    <body>
        <img src="localImage.png"/>
        <p>
            Lorem ipsum dolor sit amet, consectetur adipisicing elit<br>
            bla bla bla
        </p>
   </body>
</html>

and run the test app again, we get:

Web content with no scaling

Web content with no scaling

One can now see that no scaling has taken place; the image is displayed as one would expect a 300×200 image on such a device, and the text is significantly smaller. Without the scaling it becomes obvious that the graphic and styles used are not suitable for the xhdpi device, so these would ultimately need to change yet still cater for other densities.

In many simple cases like our example, all we want is to be able to develop and test the web content against a specific test device to ensure that it looks correct, and then allow Android to scale up/down from there. To achieve this, one can declare the specific target density (or even the exact dpi) for which your content is being designed. The following demonstrates this using our example designed for the Galaxy Nexus (320 dpi):

<html>
    <head>
        <link rel="stylesheet" type="text/css" href="sample.css" />
        <meta name="viewport" content="target-densitydpi=320" />
    </head>
    <body>
        <img src="localImage.png"/>
        <p>
            Lorem ipsum dolor sit amet, consectetur adipisicing elit<br>
            bla bla bla
        </p>
   </body>
</html>

 

img
{
    display: block;
    margin-left: auto;
    margin-right: auto;
}

p
{
	background-color: #E4E4E4;
	padding:1em;
	margin:0.5em;
	border-radius: 15px;
	font-size: 2em;
}

With the CSS modified a bit for the higher density and a new higher resolution graphic, we see the following result:

Web content targeted at xhdpi

Web content targeted at xhdpi

We are now happy with the look of the web content on our device, and because we have told the Android framework the specific density we are targeting it will automatically scale up or down for devices with higher or lower densities respectively. The following is a screenshot of the same HTML/CSS and graphic on a lower density emulator:

Web content on an hdpi emulator

Web content on an hdpi emulator

Having said all of this, YMMV with this basic approach. Allowing Android to perform scaling like this may have undesirable results with certain aspects, such as image quality. A more in-depth method for dealing with web content and multiple screen sizes and densities is to provide specific styles/graphics for different densities using the CSS media feature; more information about this can be seen here.

Otto Event Bus for Android

In case you haven’t already checked out this cool framework, Otto is an event bus designed to help parts of your application communicate more effectively and in a more decoupled manner.

With respect to Android, one particular area where the Otto event bus can be really useful is in the passing of complex data objects between the Activity andFragment objects in your application. For instance, when passing a data object between two fragments, traditional methods relied on passing the object via the parent activity or by using the setTargetFragment()/getTargetFragment() methods of the Fragment class; a downside to these approaches is that it couples your fragments/activities to one another. Whilst one can use Interfaces to alleviate the coupling, it requires additional boilerplate code and if more than a single object is required one can be faced with handling the code and coupling of many Interfaces, which is often excessive. The following is a simple Java example of how Otto can simplify the communication amongst components and reduce coupling and boilerplate code.

We have a weather service which periodically needs to provide weather updates to various components. Without the use of Otto, the following is an example of how this could be achieved:

WeatherService Class

 public class WeatherService
{
	private String weatherDescription;
	private List<WeatherListener> listeners = new ArrayList<WeatherListener>();

	
	public void weatherHasBeenUpdatedFromSomewhere(String weatherDescription)
	{
		this.weatherDescription = weatherDescription;
		
		if (listeners != null)
		{
			for (WeatherListener listener : listeners)
			{
				listener.weatherUpdated(weatherDescription);
			}
		}
	}
	
	public void addListener(WeatherListener listener)
	{
		listeners.add(listener);
	}
}

This class has to maintain a list of listeners which it publishes updates to. Notice that although it isn’t coupled with any concrete class, it still has to know about an interface which does very little. Also notice how a large amount of the code is concerned with managing the listeners.
 
WeatherListener Interface


public interface WeatherListener
{
	public void weatherUpdated(String weatherDescription);
}

A simple listener interface. This is largely just boilerplate code given how little this interface achieves.
 
WeatherScreen Class


public class WeatherScreen implements WeatherListener, SomeOtherRandomService
{
	private String weatherDescription;

	@Override
	public void weatherUpdated(String weatherDescription)
	{
		this.weatherDescription = weatherDescription;
		
		// Do something...
	}

	@Override
	public void randomAction(RandomObject randomObject)
	{
		// Do something...
	}
}

Nothing fancy here, the WeatherScreen class listens for weather updates and possibly information from other services. One can easily see how it’s possible for these publisher/listener connections to result in a lot of unnecessary coupling and boilerplate code.

If we take the same example and use the Otto event bus to manage a lot of these connections, we end up with something like the following:

OttoWeatherService Class

public class OttoWeatherService
{
	private String weatherDescription;
	private Bus eventBus;
	
	public OttoWeatherService(Bus eventBus)
	{
		this.eventBus = eventBus;
		eventBus.register(this);
	}
	
	public void weatherHasBeenUpdatedFromSomewhere(String weatherDescription)
	{
		this.weatherDescription = weatherDescription;
		
		// post the updated weather on the event bus.
		eventBus.post(weatherDescription);
	}
	
	@Produce
	public String produceWeatherUpdate()
	{
		return weatherDescription;
	}
}

When the OttoWeatherService class receives an update, it posts an event on the bus to notify all subscribers. Note that the service class now has less responsibility as it no longer needs to be concerned with a list of listeners and is immediately decoupled from the interface. Also note that this class is a Producer, meaning that as soon as an interested subscriber registers on the bus it will receive the latest update.

OttoWeatherScreen Class

public class OttoWeatherScreen
{
	private String weatherDescription;
	private Bus eventBus;
	
	public OttoWeatherScreen(Bus eventBus)
	{
		this.eventBus = eventBus;
		eventBus.register(this);
	}
	
	@Subscribe
	public void weatherAvailable(String weatherDescription)
	{
		this.weatherDescription = weatherDescription;
		
		// Do something...
	}
	
	@Subscribe
	public void randomObjectAvailable(RandomObject randomObject)
	{
		// Do something...
	}
}

The WeatherScreen class now receives updates from the various services by subscribing for these updates/events on the bus. Otto results in less classes having to be created and less code concerned with connecting your components up, allowing the existing classes to focus on performing core functions.

The above was just one example of how Otto can reduce the complexity surrounding communications/connections in your application. Coupling is reduced but strongly typed event production/subscription is still maintained.
 
I’ve created an OttoSample Android project on GitHub that provides a simple demonstration of how the Otto event bus can be used to communicate an object between two fragments. Please note that this project also makes use of the Android Annotations framework for object/view dependency injection; I plan to discuss and provide feedback on this framework in the near future.

Android Action Bar Sherlock: Mimicking action item styling in a custom action bar.

When using Action Bar Sherlock in your project there may be times when you want to provide your own custom view for the action bar. As part of your custom view, you might also want to add your own action buttons which look and feel just like the standard action item views. For instance, the following is a simple custom action bar view with some title text on the left and a search button on the right; the aim here is to ensure that the search button behaves just like a standard action item.

Custom Action Bar view with search button

Custom Action Bar view with search button

When the search button on the right is selected, visually it should appear the same as a standard action item:

Custom Action Item with standard styling

Custom Action Item with standard styling

To accomplish this is fairly straightforward:

  • Define the style for your action bar button(s) in your styles.xml resource file:
 <style name="Widget.CustomSearch.ActionButton" parent="Widget.Sherlock.Light.ActionButton">
     </style>

This step isn’t entirely necessary as one could just reference the Widget.Sherlock.Light.ActionButton style directly in the custom layout below.

  • You then need to define a custom layout view for your action bar. In our case it is something like this:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent" >

    <LinearLayout
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentLeft="true"
        android:layout_centerVertical="true"
        android:layout_marginLeft="10dp"
        android:orientation="vertical" >

        <TextView
            android:id="@+id/actionbar_title"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@string/app_name"
            android:textColor="@color/ab_custom_view_text_color"
            android:textSize="16sp"
            android:textStyle="bold" >
        </TextView>

        <TextView
            android:id="@+id/actionbar_subtitle"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@string/action_bar_subtitle"
            android:textColor="@color/ab_custom_view_text_color"
            android:textSize="11sp" >
        </TextView>
    </LinearLayout>

    <ImageView
        style="@style/Widget.CustomSearch.ActionButton"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentRight="true"
        android:layout_centerVertical="true"
        android:clickable="true"
        android:src="@drawable/ab_search" />

</RelativeLayout>

In this particular case a simple ImageView has been used to represent the search button. The important things to note here are: 1) our custom action button style (@style/Widget.CustomSearch.ActionButton) is applied to the view; and 2) the view is made clickable.

  • In your main Activity class, enable the use of a custom action bar view and apply your custom layout:

	@Override
	protected void onCreate(Bundle savedInstanceState)
	{
		super.onCreate(savedInstanceState);

		...

		// Allow custom view in action bar
		getSupportActionBar().setDisplayOptions(ActionBar.DISPLAY_SHOW_CUSTOM);
		getSupportActionBar().setCustomView(
			R.layout.ab_custom_view);

		...
	}

Where R.layout.ab_custom_view is the layout resource defined in step 2.

Attaching source code to Android libraries.

Since Android Development Tools (ADT) r17, projects in eclipse would automatically add any libraries placed in the libs folder to your build path. This is a great feature but has a pretty horrible side effect in that one cannot attach source code to the libraries in the conventional way under the build path properties page. Fortunately, since the release of ADT r20, there seems to be a work-around which is explained nicely on the following site:

Attaching Source to Libraries in Eclipse

I found that once I had created my x.jar.properties file I had to close and reopen my eclipse project for this to work.

Android Customization

Recently I’ve spent a little bit of time customizing Android on my Galaxy Nexus. I’m very much a n00b when it comes to this so I won’t pretend to have an in-depth understanding, but rather I’ll just briefly discuss my experiences thus far. The two apps I’ve installed and used to customize the OS thus far have been Nova Launcher and Ultimate Custom Widget.

Ultimate Custom Widget (UCCW)

At a very basic level UCCW is a WYSIWYG editor for constructing widgets, and an awesome one at that! So far I have been super impressed at how easy it is to create a new widget and how many  options are available in terms of customizing the widget. The widget can almost be thought of as  graphics editing program for your mobile where you are given an empty canvas and the ability to add/remove and position objects with touch. The following are some of the features the widget provides:

  • Change the background color or graphic of the canvas.
  • The ability to add all kinds of objects to the canvas. Some of these objects being predefined (such as date, current temperate or battery text) and others being more generic and allowing for customization (static text or shape). The objects can also be moved around and positioned using your finger.
Widget with custom background and static text object

Widget with custom background and static text object

  • The ability to assign action areas (hotspots) on the canvas which allow for actions to take place when touched. An example would be launching a particular app when a hotspot is touched.
Assigning a hotspot area to the widget

Assigning a hotspot area to the widget

Typically these were the features I used most when playing around, however, it’s only a scratch on the surface in terms of the level of customization the widget provides. As part of testing out the widget I decided to apply a Metro UI style look to my Galaxy Nexus using an icon pack and various widgets on my home screen:

UCCW widgets on my Galaxy Nexus

UCCW widgets on my Galaxy Nexus

Nova Custom Launcher

Nova Launcher is a home screen replacement for Android 4.0+. The launcher allows one to customize the OS in a variety of ways, from the look and feel of folders on the home screen to custom gesture recognition… it really does provide an impressive amount of tweaking.

I haven’t had enough time to fully utilize all of the features provided by Nova and as a result I don’t feel I’d be a suitable judge at this point; however, during the period of using the launcher I have noticed a couple of odd glitches, primarily in the form of how transitions between apps take place. Having said that, I will continue to use the launcher for the time being and hopefully be able to provide a better review at a later stage.

Is there finally apostasy amongst the fanboys?

I’ve had an interest in mobile for a long time and I’ve also had the privilege of being involved in the mobile dev scene for quite some time. This is a scene that is currently dominated by two platforms: Apple iOS and Google Android.

I must admit, until recently, when it had come to picking sides I had been very wishy washy; I had always taken a liking to Android, it was geeky and something about the community and the Google machine had me believing it would turn out to be big. Having said that, iOS had always seemed so slick and generally superior from an app and ecosystem point of view. My position was weak, I’d smack-talk the fanboys but deep down I couldn’t deny the superiority of the Apple products.

Things change. A good friend of mine pointed me to an article written by a self-proclaimed fanboy in which he describes his experience of switching to Android:

http://www.rottmann.net/2013/01/an-iphone-lovers-confession-i-switched-to-the-nexus-4-completely/

This is an interesting read and I’ve since followed Ralf on Google+ and subscribed to his site feed. What I found most interesting about the article is the frustration Ralf presents when discussing sharing and task-switching on iOS after having used Jelly Bean on Android… sentiments I agree with completely since having my Galaxy Nexus and subsequently using an iPhone (generally for testing purposes). Check out the article, it’s worth a read for anyone interested in the mobile space.

Android Grid Container

With the Android GridView and GridLayout view layouts, it is sometimes hard to customize the grid to fit a specific need. One such example may be to configure a grid where each row has a different number of views and the potential to specify different margins and heights for the rows.

I’ve created a GridContainer project on GitHub that provides the capability of laying out views in a custom grid-like configuration. Currently the grid has the following properties:

  • The rows will always use fill width.
  • One can specify the number of views to fit per row. The views will share the width equally.
  • One can specify an optional margin to use between the views.
  • One can specify an optional height for a row. If none is specified, the row will wrap content.

It’s also fairly easy to specify different grid configurations for different device orientations:

Portrait

grid_container_portrait

Landscape

grid_container_landscape

 

The GridContainer currently only supports the adding of views dynamically from code and not yet from the xml. The project includes a TestActivity class which demonstrates how the GridContainer layout can be used.

Please note that the GridContainer project is very basic and currently only fits a specific need. Feel free to take the code and modify as you need for your purposes.