November 2009 Archives

"Grid" layout in Android

You know how your mother (or, in this case, your front end developer friends/colleagues) always say “never use a table for formatting unless you’re really making a table”

That may be true for HTML. However, it doesn’t seem to hold when you’re working with Google’s Android.

You see, now that I have a shiny new Motorola Droid (see my previous post), I’m now working with Android in my spare time.

I was struggling with using Android’s UI XML to layout a simple login page. And I was going nuts.

I was trying to use A LinearLayout containing several RelativeLayouts, one for each row. “Row” should have been the clue.

After poking through the PragProg Hello, Android book for a bit, I found an example later in the book that used a TableLayout.

That was my aha moment.

TableLayout is pretty simple to use. It is designed to contain several TableRow (a ViewGroup child as are other *Layouts). A TableRow looks thus:

<TableLayout
  android:layoutwidth="fillparent" 
  android:layoutheight="wrapcontent"
  android:stretchColumns="1" 
  android:padding="10dip" >
  <TableRow
    android:layout_marginBottom="10dip">
    <TextView
      android:id="@+id/login_label"
android:layoutheight="wrapcontent" android:text="@string/login" /> <EditText android:id="@+id/login_field" android:layoutwidth="fillparent" android:layoutheight="wrapcontent" android:lines="1" /> </TableRow> <TableRow android:layout_marginBottom="10dip"> <TextView android:id="@+id/password_label" android:layoutheight="wrapcontent" android:text="@string/password" /> <EditText android:id="@+id/password_field" android:layoutwidth="fillparent" android:layoutheight="wrapcontent" android:lines="1" /> </TableRow>
</TableLayout>

The android:layout_marginBottom attributes on the TableRows are entirely optional. However, odds are that you will want to add some sort of formatting to your TableRows.

Incidentally, there may be DRYer ways of representing rows in Android XML (i.e., something similar to a Rails partial); however, admittedly, I’m still very much learning Android.

Posted by evan on Nov 28, 2009

A brief review of the Motorola/Verizon Droid

On the last leg of the return from my road trip, I picked up a Droid from the Best Buy in Salisbury, MD.

In a nutshell: I love it.

And, yes, more than an iPhone.

Why?

The Device

From photos, I had thought that the Droid was just an ugly brick. In the “flesh”, it’s more like an F-22: oblique surfaces but with rounded edges. This results in a device that is comfortable to hold with or without the keyboard open (which, sadly, I could not say the same of my former Palm Pre; it could be painful to type upon).

The Droid is a heft to it. It feels like it means business. And it’s solid: no flimsy plastic casing here that gives when you squeeze it.

The keyboard slides open easily enough, snapping in place when fully open. However, there are no springs involved; the slider requires gentle but constant pressure. The keyboard itself is spacious enough. However, I haven’t seen keys like this since the old Timex Sinclair home computer. The keyboard is covered in a slightly flexible but thick sealed plastic. The keys are only barely raised above the slider with the actuators themselves set in the slider.

While the keyboard takes some getting used to, I can tell that my typing is already improving.

The speaker on this thing is amazing. In fact, audio, overall, is lovely. But the speaker is simply the loudest that I’ve heard in any smartphone – even louder than the Pre.

Oh, and the device uses micro USB. I had never seen this connector before the Amazon Kindle. However, it seems to be becoming more common on contemporary smart phones.

The Software

Speaking of keyboards, Android 2.0 comes with a soft keyboard. However, I’m sad to say that this is not an iPhone keyboard. I could type lightning fast on the iPhone. When I start to work up a head of steam on the Droid’s virtual keyboard, I notice that the virtual keyboard seems to acknowledge that I’m tapping keys; however, the letters themselves do not always make it into the text area that I’m editing. However, I don’t encounter this problem when using the physical keyboard.

Do I really need to tell you about Google Navigation? It’s awesome. Jaw droppingly awesome.

Otherwise, it’s an Android phone. However, that is not a bad thing, as it happens.

Customizing the Droid

Unlike Apple, neither Google nor Verizon put much in the way of restrictions on the Droid. Background apps? Check (although watch that battery, folks). Re-skinnable user interface? Check. Crappy Facebook app? Check (woops. Nice one, Facebook).

Quirks

I’ve had a few minor problems with the Droid in the first 48 hours.

Occasionally, the Droid has a difficult time connecting to my wifi network. That may be because I run an 802.11g network with a range extender; the Droid may occasionally have a difficult time selecting which access point to use.

Also, this morning, I noticed that the devices speaker volume dropped significantly. Rebooting the phone solved the problem.

A few times, I’ve had an app randomly open unbidden while I was in another app. The android revolution begins? At least it didn’t a suction cup, an eye stalk, and intone, “Exterminate!”

And then there’s the virtual keyboard issue that I mentioned above.

Overall

I’m extremely pleased. Yes, so pleased that I don’t miss my iPhone (although I do miss Cultured Code’s Things).

Now if only the API wasn’t pure Java and/or the Dalvik team would fix this damn bug so that I could write Android apps in JRuby (or pick your interpreted JVM language of choice that relies on reflection to get anything done).

In the meantime, it’s time to learn some Scala…

Posted by evan on Nov 08, 2009

A meditation for the (aspiring) Rubyist

You’re new to programming. You’ve got an idea that you’re aching to make manifest. You’ve heard of this awesome Ruby on Rails thing. You’ve even bought Agile Web Development with Rails [AWDR]. Now what?

Yes, you can probably take AWDR and try to use Rails right away. However, if you want to do anything the least bit different from the examples in AWDR, you’re in for some trouble.

Hold your horses there, cowboy. You’re just starting to learn how to walk, someone gives you an airplane, and you’re going to fly it?

Bad idea.

So where to begin?

First learn some Ruby

Over the past couple of months, I’ve given several informal introduction to Ruby classes – sometimes on a one-on-one basis and other times for small groups of five to ten people. In that time, I’ve received the same good question a couple of times: can you point me at a few good books and or blogs to read that will help get me started?

Well, maybe. The Pragmatic Programmers offer a book called Learn to Program which, as it happens, uses Ruby as its language of choice. Lacking firsthand knowledge of the book, I’m a little hard-pressed to recommend it.

Most of the technical books that I consume are targeted at programmers with at least a modicum of programming experience in some language. Even the the “Pickaxe” or the O’Reilly Matz-Flannigan (sp?) Ruby books are really aimed at, at a minimum, the somewhat experienced programmer.

Besides, we learn by doing, not reading. This is why several small businesses offer Ruby training. However, training is expensive. It’s short. It’s chock full of knowledge. And if you don’t use that knowledge right away, you lose it before it can become experience.

Where’s an aspiring Rails/Ruby developer to turn?

Meditate on it

Jim Weirich created a wonderful teaching tool called the Ruby Koans. The Koans come complete with the simple instructions necessary to execute them. Learning comes from solving each tiny problem, one after another, that Jim presents along the path.

While I haven’t discussed the Koans with Jim (maybe at Scottish Ruby Conf next year), I believe that the Koans may have been initially aimed at rounding out experienced Rubyists. However, I’ve found that they are so simple yet so informative that I recommend them to nearly every Rubyist, beginner and otherwise.

A side-effect and bonus resulting from the Koans being hosted on Github: several people who have completed the Koans have posted their work on Github as well. If you get stuck, you’ve already rifled through your “Pickaxe” or O’Reilly Ruby book, and are pulling your hair out in frustration, you can look at how someone else solved the particular Koan.

Just be sure to meditate on those easily acquired answers.

Posted by evan on Nov 07, 2009

Playing with Proc#bind

When I write internal DSLs in Ruby, I tend to do so by leveraging Object#instance_eval. #instance_eval is powerful because it’s yet another way that you can repoint self in Ruby. Object#instance_eval executes its supplied Proc in the context of the calling Object Below is a simple example.

  def car(&block)
    # self is "main" (an Object) here
    c = Car.new
    # self refers to Car instance when Proc is evaluated on the line below
    c.instanceeval(&block) if blockgiven?
    c
  end

class Car
def make(v); @make = v; end def model(v); @model = v; end def engine(v); @engine = v; end end

car do make "Ford" model "Fusion" engine :piece_of_crap end

You could implement the same code by replacing Object#instance_eval with calls to Proc#bind as follows:

  def car(&block)
    # self is "main" (an Object) here
    c = Car.new
    # self refers to Car instance when Proc is evaluated on the line below
    block.bind(c).call if block_given?
    c
  end
  

Remember, Procs are also closures. That is, they take the context within which they were created along with them. For example:

  def make_incrementer
    x = 0
    Proc.new { puts self; x += 1}
  end

inc = make_incrementer # Will print 1 to 5 interleaved with "main" 5.times { puts inc.call }

… gives us …

  # >> main
  # >> 1
  # >> main
  # >> 2
  # >> main
  # >> 3
  # >> main
  # >> 4
  # >> main
  # >> 5
  

Wherever you pass that Proc, when you call it, puts self would always say main (which is just the “root” Object of the Ruby interpreter).

So now we add the following code:

  class Foo
  end    

foo = Foo.new rebound_inc = inc.bind(foo)

5.times { puts rebound_inc.call }

We didn’t change the Proc. We just created a Method, rebound_inc, where self now points to our instance of Foo_. So our code, with the above additions, when executed, now returns:

    # >> main
    # >> 1
    # >> main
    # >> 2
    # >> main
    # >> 3
    # >> main
    # >> 4
    # >> main
    # >> 5
    # >> #<Foo:0x10019092>
    # >> 6
# >> #<Foo:0x10019092> # >> 7
# >> #<Foo:0x10019092> # >> 8
# >> #<Foo:0x10019092> # >> 9
# >> #<Foo:0x10019092> # >> 10

In the example above, reboundinc_ is still a closure over x, defined in make_incrementer, but it’s self now points to whatever object we like.

Posted by evan on Nov 05, 2009

Proc#Bind with Bobby Wilson

The Friday before I left Floyd, I had the opportunity to sit down with Bobby Wilson of Entryway. Bobby and I had been hacking earlier on a hypothesis of mine that ActiveSupport’s Proc#bind could be used effectively to write a DSL instead of somewhat more evil/ugly approaches using Object#instance_eval. Ironically, I found earlier this week that Shoulda already does just that. However, it was fun coming to the same conclusion on my own.

Proc#bind is a funny beast. It effectively converts a Proc into a Method object where self refers to the parameter passed to Proc#bind.

class Proc #:nodoc:
  def bind(object)
    block, time = self, Time.now
    (class << object; self end).class_eval do
      methodname = "bind#{time.to_i}_#{time.usec}"
      definemethod(methodname, &block)
      method = instancemethod(methodname)
      removemethod(methodname)
      method
    end.bind(object)
  end
end
  

Here’s how it works:

  1. Defines a method on self’s (a Proc) singleton class using the Proc itself as the method implementation
  2. Grabs a handle to the UnboundMethod representing the Proc
  3. Removes the method from the Proc’s singleton class (but we still have the UnboundMethod from step 2)
  4. Binds the UnboundMethod to the object passed to Proc#bind, returning a Method object

Afterward, Bobby and I sat down to BS for a bit about how much we needed beer (hey, it was Friday evening), discuss Proc#bind, and the merits of describing oneself to non-software craftsman as a software craftsman.

Interview with Bobby Wilson from Evan Light on Vimeo.

Posted by evan on Nov 04, 2009

Facebook Connect w/ Facebooker

Facebook Connect seems to be well on its way to becoming the most popular third party authenticator on the market. While Facebooker provides support for Facebook Connect, the Connect features are given only a light treatment in a blog entry by Mike Mangino (one of Facebooker’s authors). In this article, I will attempt to fill in some of the blanks left by that entry.

After following Mike’s example, I put _fb_logout_link in my template, clicked on it, but found that my web app was still convinced that I was logged into Facebook. That is, I still had the facebook_session object in my webap. Mike’s article show’s how to handle logging in to Facebook Connect; however, logging out was causing me frustration.

The below seemed to work for me:

In your ERB (for example), you will want:

<%= fb_logout_link "Logout", "/logout" %>

fb_logout_link will log you out of Facebook; however, it does not seem to nil out the the facebook_session object referred to in Mike’s example. As such, you’ll want to map “/logout” to an action that will do this for you. The logout operation should look something like:

def logout
  # ...
  clear_facebook_session_information
  # your redirect here    
end

clear_facebook_session_information is a method in the Facebooker::Rails::Controller module that will do exactly as the name says

Posted by evan on Nov 03, 2009

Interview with Jonathan Greenberg

As I wrapped up my time in Floyd, VA, I squeezed in a couple of interviews. I caught up with Jonathan Greenberg of Entryway who was previously interviewed by Corey Haines several months ago. After watching Corey’s interview of Jonathan, I thought it intriguing to see how Jonathan since Corey’s visit.

Interview with Jonathan Greenberg from Evan Light on Vimeo.

Posted by evan on Nov 02, 2009

Why you too should undertake a software craftsmanship road trip

I am finding my software craftsman road trip to be similar to an unconference experience but deeper and far more personal. I set the overall agenda. I am enriched by each fellow craftsman along the way and enrich in kind.

I cannot believe that this is unique to the Ruby community. And yet I have found that my shared love of Ruby has before, and now, lead me to places and people unexpected. Ultimately, I find that we are all the better for it: both the visitor and visited.

The long road between places is a uniquely solitary environment. In a busy world, where many of us constantly seek outward, the journey becomes a form of forced meditation. In the spaces between one destination and the next, I can only listen to so many podcasts and books before boredom ensues. I find myself drawn inward in a way that I have not experienced in years. The drive itself becomes a retreat, a respite from the world.

And I ordinarily despise long drives.

For those of you who spend many of your spare hours on the craft, I cannot recommend this experience enough. However, do be sure to share your learnings with the rest of us. Educating is part of what it means to be a software craftsman.

As someone who feels almost uniquely isolated from the world by the vagaries of life, the journey has reaffirmed my belief in the goodness of people. To those special few people who have opened their homes and lives to me, someone that they barely know, I am grateful.

Gustin Prudner, Andrea Goodrum, and their children Loic and Cedar, Geoffrey Parsons, and Brennan and Deborah Dunn: sincerely, thank you.

Posted by evan on Nov 01, 2009