I believe that the best way to learn how to do anything is to just do it. Overcoming the challenges you encounter while building something real is where you learn all the twisty little quirks that every platform has. The online Android developer guide and reference is fantastic. And I love books (any recommendations?). But, for example, in the last few days of actually building an an Android app I’ve learned:

• There’s a difference between a paused activity and one that’s just obscured.
• Trying to load Drawable resources in onLayout() of a custom component breaks the Eclipse WYSIWYG layout tool (“NotFoundException: Could not find drawable resource…”).
• SoundPool feels much more responsive than MediaPlayer for playing short sound effects.
• DatePicker uses the same internal representation as Calendar.
• Creating a custom component that extends a standard one and draws itself is actually pretty simple.

So far, developing on the Android platform (version 1.5 right now) feels solid and is very productive. The framework takes care of  a lot low-level junk for you so you can concentrate on app features. I feel like I’ve wrapped my head around the “Android way” of Activities and Intents and Listeners. Now it’s just a matter of becoming a little more comfortable with Java and learning the capabilities of the framework itself.

First, find a nifty little utility called jpeginfo and install it. jpeginfo is a command line program that attempts to quickly decompress a JPG file and tell you what happens. It’s not infallible, but I’m betting that if the JPG file decompresses successfully then the files are good.

Then you just open a shell, cd to your photos directory and run jpeginfo -c on all of your files. Like so:

    cd photos
    find -iname "*.jpg" -print0 | xargs -0 jpeginfo -c | grep -e WARNING -e ERROR

Any corrupted JPG files will be listed.

How it works: the find command lists all files ending with .jpg (case insensitive). It passes it to xargs which runs jpeginfo -c on each file. The grep command shows just the files that had a WARNING. Instead of grep WARNING you could also redirect the output to a file so that you can see all of the results.

I found 4 corrupted JPGs in my collection of over 35,000 photos. I knew about some of these. At least 2 I think were corrupted during transfer off the memory card. JPG images are surprisingly resilient. Even with bad data in the file a lot of the image could be decoded in 3 of 4 of the images. Here are the best and worst of the corrupted 4.

• Run gconf-editor
• Open desktop → gnome → applications → terminal
• Change the value of exec in the right pane to: gnome-terminal –geometry 132×40
  (Where 132×40 is whatever size you want.) (Use a real “x”, don’t copy and paste the multiplication symbol above.)

One test I recently added was an automated test for browser SSL warnings. SSL warnings appear in a browser when the browser requests an https page but some of the resources requested on that page are unencrypted. While a study has shown that most people will ignore the warnings, that still leaves a lot of people who take them seriously.

The test works by using wget to request SSL pages and test for non-encrypted resources. Here’s the relevant Bash:

wget --quiet -O - "https://bighugelabs.com/cart.php" | grep -P '(script|img).*?src="http://'
if [ $? -eq 0 ]
then
  echo "     *** SSL WARNING IN CART/CHECKOUT! ***"
  beep -r 3
else
  echo "     OK"
fi

wget requests the page and pipes it to stdout. grep scans the page using a Perl regular expression for tags that load http:// resources (rather than relative URLs or https://). $? -eq 0 tests that the exit status of grep is zero. The exit status is 0 if grep finds a match and 1 if it does not. For good measure the script beeps three times if there is a problem.

This isn’t fool-proof by any means. The regular expression isn’t all-inclusive, for one. It also ignores problems that can be caused by scripting. But it’s a start that should catch some problems caused by embedding resources directly into the page.

Too many interruptions in flow to consider paying money for the service. Which is a bummer because I really wanted to like it. Now I have to keep looking.

If you’re as frustrated as me by online note taking apps, you might want to check out Cloud Notes, a blog whose owner is on a quest to find the perfect online note taking solution.

This is my keyboard. There are many like it, but this one is mine.