Been fiddling with Twitter today. I used twitbacks to create a background picture so my profile isn’t quite so mundane. I finally started using lists (now if echofon would just let me see tweets from a list that would be something). I looked around for other #androiddev folks – not too many active at the moment, but then it is the holidays. I see some of the value of twitter but at this point it still seems like more of a time sink for me than a value. I have a feeling I shouldn’t miss out, though, ought to expand my usage, link everything I’m doing together and promote it. Because I do feel like I can add a lot of value to a corner of this internet.

I thought I’d take a crack at subclassing AlertDialog like I wanted. The goal is this: customize the view to include a text entry field linked to the positive button such that there has to be some content in the text entry field before the button is enabled. Simple enough for a single custom dialog – just set a key listener on the entry field and enable/disable the button accordingly. But I want to do this in several places so it seemed like a good idea to make a custom dialog class that could be configured a little differently each time but with the same general behavior. I thought all I need is AlertDialog with a custom view (it doesn’t allow any sort of text input) and some added behavior, right?

Subclassing AlertDialog turns out to be tricky. I mean, a simple subclass is trivial, of course, but the problem is the actual building of the dialog, which is normally accomplished by the AlertDialog.Builder inner class. This in turn relies on AlertController.AlertParams to hold the parameters that will be applied to the dialog when finally it’s built. Unless I’m mistaken, I’d have to recreate all that behavior in my builder. Suck! Forget it! I think what I’ll do instead is just have the custom dialog I already almost finished expect to be given a view with certain element IDs and wire them up. Well – even that is sucky because getting at the elements inside the dialog from outside the dialog pretty much sucks – which is why an AlertDialog would have been nice in the first place. Ok. I’ll make a fairly stupid class that just supplies the button-wiring behavior and let specific dialogs subclass from that and specify what gets wired. That works.

RTFMing some more. Defining preferences from XML isn’t described anywhere in the dev guide – but “Hello, Android” is helpful here. However, I had to use a little trial and error to figure out how to use a ListPreference (well – probably there are examples in the sample programs, but I figured it out). Here’s what a ListPreference definition looks like:

<ListPreference android:title=”Tracker click”
 android:summary=”What should happen when you click on a tracker?”

Of course the arrays are defined in values resources like so:

<string-array name=”trackerClickBehaviorVisible”>
    <item>Create instant log</item>
    <item>Create detailed log</item>
    <item>View tracker details</item>

Simple enough.

It’s good to know that you can create a custom toast layout if you so desire.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: