World War Two Daily Promo

April 21, 2011, 3:17 pm

Over a year late, but I finally made a promo video for WW2 Daily.

Permalink - Comments - Tags: Development,iPhone

More nice Android bits

April 14, 2011, 6:59 am

I am going to talk about Android dev tonight at at GTUG, so I thought I thought I would write down a few other things about Android that are nice.

Slipstream releases

This is the obvious one. It is great not having the pressure when you submit an update, that you will have to agonised about re-submitting for every bug you find in the next fortnight. There is never a time I am not waiting for an app to be approved. I am waiting right now.

Notifications

One of the rare bits of UI on Android where the experience is far better than the iPhone equivalent. True for the user and true for developers adding notifications to their apps.

You have to deal with a bunch of cases when adding push/local notifications to an iPhone app (in the app, background, suspended, local, push) and your UI is pretty inconsistant. On Android you declare yourself a BroadcastReceiver in the manifest and have a single point to handle 'cloud to device' messages. You have complete control over your UI, but I recommend using the NotificationManager to get the standard pull down message UI:


          NotificationManager nm = (NotificationManager) m_context.getSystemService(Context.NOTIFICATION_SERVICE);
          String text = "Stuff in the notification;
          Notification n = new Notification(R.drawable.notification, text, System.currentTimeMillis());
          n.setLatestEventInfo(m_context.getApplicationContext(),
                    "Message Title",
                    text, getIntentForNotificationTap());
          nm.notify(YOUR_NOTIFICATION_ID, n);

Testing GPS

Testing GPS updates in the simulator for iPhone is pretty limited. If you want to send location updates to your app, you are basically reduced to hacking into the simulator binaries and hooking the appropriate libraries, so ... not so much. I spent a lot of time on trains testing my location stuff on the iPhone. On Android you can telnet to the emulator and set it's location on the command line (there has to be something nice about that thing):


$ telnet localhost 5554
geo fix <longitude> <latitude>

Permalink - Comments - Tags: Development,Android,Google

Showing Android resources some love

April 13, 2011, 12:42 pm

I have ranted at length on some of the shortfalls I have found with Android development, particularly when compared with my iPhone exploits. However, there are some things about Android dev that I love, so I thought it was time I talked about them.

If you have done much iPhone development you will be pretty familiar with laying out UI in Interface Builder, or if you are one of those ''XIBs are the work of Satan'' guys, then laying out your UI in code. Either way it can get pretty hairy, pretty quickly. In IB you struggle with entering layout through the UI and in code you end up with your UI metrics spread across multiple source files.

Android has a much better solution to UI definition. If you are a web developer, you will find the XML layout definition language pretty familiar. All your UI is nicely contained in source control friendly, well structured XML files.

Let''s say I want to arrange a couple of text views and a custom button view vertically down the page:


<LinearLayout
android:layout_width="1px"
android:layout_weight="1"
android:layout_height="wrap_content"
android:orientation="vertical">

<TextView
android:text="Some bold heading type text"
android:layout_weight="1"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:padding="10dp"
android:textSize="16sp"
android:textStyle="bold"
android:textColor="@android:color/black"/>

<TextView
android:text="Some regular text"
android:id="@+id/detail"
android:layout_weight="1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:padding="10dp"
android:textSize="14sp"
android:textColor="@android:color/black"/>

<Button style="@style/Button"
android:id="@+id/something_funky_button"
android:text="Ow! Too Funky!"
android:layout_height="88dp">
</Button>

</LinearLayout>

A couple of things to notice about this snippet:

Define ids on your views so you can get to them from your code with View.findViewById. All the properties you can define here can be played with from the View subclass. So you have complete control over how things are laid out at design and runtime.
Padding, layout widths, heights, etc work predictably and intuitively. This makes scaling your app for various devices work out of the box most of the time.
The style attribute on the Button element refers to a separate style resource, so you can define commonly used UI elements in a single XML file and use it in all your layouts:


<style name="Button">
<item name="android:textSize">18sp</item>
<item name="android:textColor">@color/button_text</item>
<item name="android:textStyle">bold</item>
<item name="android:padding">5sp</item>
<item name="android:background">@drawable/button</item>
<item name="android:layout_width">fill_parent</item>
<item name="android:layout_height">wrap_content</item>
</style>

I have just scratched the surface of what you can do here in your Android project''s resource directory, but it is all pretty awesome stuff.

Permalink - Comments - Tags: Development,Android,Google

What's wrong with Google Maps development on Android - Part Three

April 13, 2011, 7:37 am

Update 5th December 2012 - Android Maps v2

Another sentence from the MapActivity documentation that causes developer pain:

"Only one MapActivity is supported per process. Multiple MapActivities running simultaneously are likely to interfere in unexpected and undesired ways."

This means one MapActivity subclass per Android process and therefore, only one MapView onscreen at any one time. This might not seem like a big deal, but there are times when you would like to have two maps on view at a time. A good example is my WW2 Daily app which lets you swipe locations (and their associated maps) on screen in a scrollview:

To implement this on Android I am going to have to layout image views around my map view and, as the user swipes, replace the adjacent images with a screenshot of the map view, then swap the image view and the map view in the hierarchy. So this is do-able, but compared to keeping multiple map views, a massive pain.

Based on the some of the questions on StackOverflow, this is not a unique gripe with the API (check out the this truly horrible workaround for the issue. Sticking your second map activity in a separate process? ouch!).

This rant continues:

Permalink - Comments - Tags: Development,Android,Google

What's wrong with Google Maps development on Android - Part Two

April 13, 2011, 7:05 am

Update 5th December 2012 - Android Maps v2

A smaller issue with the Android maps library, but worth mentioning

When I started doing web development with the Google Maps API six years ago, it required an API key. You associated it with your domain and prevented naughty people from doing bad things with the API.

Times have changed. With version three, the key went away. The API was infinitely more awesome than the old one, and this was one tiny part of that. The old key was a little irritating if you had to move code between domains, so not having to worry about it made things that much easier for developers.

"The android:apiKey attribute holds the Maps API Key for your application, which proves your application and signer certificate has been registered with the Maps service. This is required in order to receive the map data, even while you are developing.

So you grab your Maps API key by taking an md5 hash of your signing certificate and submitting it to Google to get your key. There are a couple of things that make this annoying for developers:

When you are debugging your application you use the SDK debug certificate, so you will need a different Google Maps key for your dev build.
If you are building multiple applications from the same source code, then you are going to have to make sure you have an API key for each one and conditionally compile them in.

Admittedly these are pretty minor irritations, but when you consider that neither the iPhone MapKit or the web API require a key (and I realise there are technical differences here), it seems like an unnecessary one.

This rant continues:

Permalink - Comments - Tags: Development,Android,Google

[First Page] [Prev] Showing page 15 of 40 pages [Next] [Last Page]

World War Two Daily Promo

More nice Android bits

Slipstream releases

Notifications

Testing GPS

Showing Android resources some love

What's wrong with Google Maps development on Android - Part Three

What's wrong with Google Maps development on Android - Part Two

Tags

Archive