New App – Bird Atlas Mapstore

I’ve long wanted to have the Bird Atlas 2007-11 maps available on my phone, when out in the field – and now I can (thanks to the BTO for letting me develop and deploy this through their channels, published 18/01/2016). It’s all offline, optimised to 100Mb space and contains maps not published in the book too. See details here

It uses an ExpandableListView and ListAdapter to open up available maps for each species, which then leads to an ExtendedViewPager and TouchImageView combination from Mike Ortiz, which makes the maps pinch zoomable with sensible constraints and actions. The ViewPager loads up to the max four maps at a time per species.

The user can also switch between BOU and Alphabetic species orders, and between the maps published in the book or all available species.

Sniffing HTTP requests from Android Apps

I’ve recently had a requirement to rebuild a clunky and inefficient Android App with only partial access to the codebase (layouts and assets, but no Java/Android code). One of the issues was the App was talking to an online database via HTTP POST and GET. I had details of the HTTP root URLs used, but not the specifics on the parameters or how it was formatted.

So after a bit of digging, I found Drony (Google Play link), a kind of log watcher that can show you the exact nature of the HTTP requests, and from this tool I was able to see the exact format of the keys and values for the parameters to upload and download the right information. Great tool, really saved me a lot of effort (and stopped me having to chase original developers etc.)!

Great Android code snippets

I’ve been developing a new Android App over the last month, and found/learnt several new ways to do things, mostly from hacking other peoples ideas and code (but isn’t that what everyone does? why reinvent the wheel!) In no particular order…

Loading up PLIST files into Android from assets folder

Using xmlwise, which has a specific ‘plist’ class amongst other useful stuff, loading plist dicts and arrays into a Java map is simple.

public TreeMap getData(Context context) throws XmlParseException, IOException {
    TreeMap<String, Object> tMap = null;
    try {
        //To access files stored in Asset folder you need AssetManager
        AssetManager assetManager = context.getResources().getAssets();
        InputStream inputStream = null;
        BufferedReader br = null;
        try {
           inputStream = assetManager.open("myfile.plist");
           br = new BufferedReader(new InputStreamReader(inputStream));
           StringBuilder sb = new StringBuilder();
           String line;
           while ((line = br.readLine()) != null) {
               sb.append(line);
           }
           tMap = new TreeMap(Plist.fromXml(sb.toString()));
        } catch (IOException e) {
           e.printStackTrace();
        } finally {
           br.close();
        }
    } catch (Exception ex) {
        ex.printStackTrace();
    }
    return tMap;
}

Enabling touch and pinch zoom on images in ViewPager

Using TouchImageView from Mike Ortiz, I can overload a standard ImageView and set it as a Drawable to add to the ViewPager adapter. It’s really cool, and by a simple hack of Mike’s code it’s easy to tweak the zoom levels. Double-tap and pinch-control are both implemented and it seems fast and robust. Kudos to Mike.

Adding an Android splash screen, easily…

OK, so not everyone wants one, nor every app need them, but the simplicity of the app I’ve been working on needed some branding to remind the users who brought them this (free) app. First I created an XML resource for the layout (useful if you want a complex splash screen).

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context="org.my.package">

    <ImageView
        android:id="@+id/mylogo_view"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:background="@null"
        android:layout_gravity="center"
        android:src="@drawable/my_logo" />

</LinearLayout>

Then I created a simple class to start on launch, which included a runnable to redirect after short period of time to the main activity.

public class Splash extends Activity {

    //Duration of wait - 1000ms = 1second
    private final int SPLASH_DISPLAY_LENGTH = 1200;

    @Override
    public void onCreate(Bundle icicle) {
        super.onCreate(icicle);
        //This line is useful if using action bar etc. 
        requestWindowFeature(Window.FEATURE_NO_TITLE);
        setContentView(R.layout.splash);
        
        new Handler().postDelayed(new Runnable() {
            @Override
            public void run() {
                Intent mainIntent = new Intent(Splash.this, MainActivity.class);
                Splash.this.startActivity(mainIntent);
                Splash.this.finish();
            }
        }, SPLASH_DISPLAY_LENGTH);
    }
}

Finally, adding

android:theme="@android:style/Theme.NoTitleBar.Fullscreen"

to the android manifest gets rid of the title bar. Haven’t worked out if this AND

requestWindowFeature(Window.FEATURE_NO_TITLE);

(in the Splash class above) are necessary together or if one will override the other.

Java: Hibernate and JUnit

I’ve just been refreshing my [lack of] knowledge of Hibernate and JUnit. BTO had some poor experiences with Hibernate (through some tendered out code) and never really seemed to need JUnit.

Hibernate

I can see the attraction and time saving of Hibernate for new projects with bespoke databases. But, for legacy projects, which are hooking into existing, extensive databases with their own dependancies, I think this would cause just as many issues, slowing down initial project development – also BTO projects were costed as cheaply as possible, with little thought to funding database requirements (although the DBA was changing that in the right direction).

JUnit

Again, BTO never really felt it needed this. As a small team (of discrete/disparate developers), it seemed overkill. I can see the advantage if the developers aren’t familiar with the data being returned, so that they can get direction to populate the assertEquals and verify results.

assertEquals("10 x 2 must be 20", 20, myTesterMethod(10, 2));

Both things for me to research further…