I was recently contacted by the marketing team from Packt Publishing and asked if I could write a review for one of their new ebooks, so here it is!
This book gives a brief yet comprehensive overview of some of the processes you can follow to improve your applications chance of working on the varying versions of android that are currently in existence.
Having developed apps that work perfectly fine on my Galaxy S2 2.3.3, only to find they don’t work on a hardware identical S2 with 4.0, I certainly feel the pain of OS fragmentation!
Maven is a fantastic build tool, and a great addition to anyone developing on the android platform, however one of the first hurdles that people often stumble upon, is when their project involves one of the SDK libraries, such as Google Maps.
You’ll most likely see something like this when you attempt to first compile the project :
If you’re an android developer, chances are you’ve used an Async task more than once. As your apps develop, grow, and become more complex, theres a high chance you’re going to have multiple Async tasks. In an application I’ve recently been developing, I had around 5 Async tasks for a single activity, which made the actual activity quite difficult to read.
Adhering to KIS and DRY, I wanted to devise a mechanism for extracting the logic of these Async tasks out into separate external classes, thus reducing the clutter of inner classes in my activities, and also meaning that I could re-use these Async tasks elsewhere, and also externalising them makes them easier to mock and unit test.
I’ve spent the past few months working on an android application that involves an element of OCR capability, its been quite a painful journey so this is my attempt to reflect on these experiences and hopefully help others who follow in my path.
I’ve been developing an app recently that relies on being able to navigate and browse for images on the phone, which is all well and good when testing on a device as chances are you’ll have something like Astro installed.
This isn’t quite the case when developing on the emulator, since you’ll have just the stock version of android, which by default doesn’t come with a file browser (or at least not one you can easily interrogate).
The easiest thing to do, is just install a file browser (like Astro) onto the emulator….but wait…there is no market on the emulator so how do you do that?
I’ve recently put together a few proof of concept applications, and since they’re “rough and ready” applications, a lot of the functionality is actually mocked, or given a stubbed implementation.
For example, I’ve got various buttons for things like “sign in with LinkedIn” or “Connect with Facebook”. Since its just a proof of concept, and those features aren’t really must haves, I stub them with a Toast message saying something along the lines of “feature not yet implemented”.
This gives the user the opinion that the buttons are there, functional, however the actions they take are not yet implemented.
After launching my first application onto the market back in March 2011, and amassing somewhere in the region of 15,000 downloads since it’s launch, I was eager to produce another.
I offered up my services at my work to develop an application to “test the water”, teaming up with the marketing director we created a simple yet useful application for agile project managers; planning poker decks.
Adding a splash screen to your application is a quick and easy way to make it look more well rounded, complete, and more professional, it can also serve as a useful distraction whereby you have an extra few seconds to initialise your application components before displaying them to the user.
In this post I’ll show you how to quickly and easily add a splash screen into your application, I’ll also show you how you can create an option whereby users may disable or enable the splash screen for subsequent launches of your application. I’ll also post up my sample code freely on Github so you can checkout what I’ve done and use as you please.
Sometimes in android you have to deal with pixels, which can often be awkward, such as view.setPadding(int, int, int, int). Obviously this is not ideal as pixel ratings vary from device to device, nonetheless there is a work around for this
Simply come up with the value you want in dip (density independent pixels), such as 10, and then convert into pixels using the display metrics of the device you’re working on. This will ensure that when the conversion runs, it’ll always scale to the device the application is running on.
float sizeInDip = 10f; int padding = (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, sizeInDip, getResources().getDisplayMetrics());
I’m not the type of person that gets bored easily, I’ve always got many things to keep me amused, mostly side projects at home. I’m a firm believer, that if you don’t set yourself goals in the first place, then you won’t have anything to fail to achieve, so I’ve set myself a list of targets that I’d like to achieve in 2012 knowing full well I probably won’t get around to them all, but if I can do at least 3, it was worth it.