New site

Hi everyone, I must apologize for being so quiet for so long.  My blog account with Blogger got frozen by Google when they consolidated their services and accounts.  I tried to work with Google’s help forums (as they have no other kind of help….) in order to correct the issues I had, but to no avail — they don’t care about the little guy and my issues were completely ignored.  Since then, I have moved to a new Domain registrar thanks to GoDaddy’s stupidly backing SOPA and, with the help of a good friend, moved both my blog and my website into a combined whole.

The site is still a bit rough around the edges as I am still working on updating it, but the bulk has been moved over mostly intact and at least it’s not offline like it has been for a few weeks.  It will be nice to start posting again!

9/11 Boatlift

A friend of mine recently shared a link with me that was quite moving about 9/11 that I had not heard before.  The short, 12 min video was produced by Tom Hanks.

Orig Vid Link: http://biggeekdad.com/2011/09/boatlift/

Boatlift is the epic story of the 9/11 boatlift that evacuated half a million people from the stricken piers and seawalls of Lower Manhattan. I had no idea that the 9/11 boat evacuation was larger than Dunkirk and they completed it so fast. The video is narrated by Tom Hanks who I am a big fan of as usually whatever he has a hand in turns out to be a great production. If you’ve never seen Band of Brothers set aside a couple weekend nights and watch one of Tom Hanks finer productions.

[youtube]http://www.youtube.com/watch?v=MDOrzF7B2Kg[/youtube]

 

Android: Proof that findViewById() is slower than using a ViewHolder

I was recently asked to provide proof of why using a ViewHolder would be faster than just using findViewById() when populating the item views of each item in a ListView. A fair question since empirically stating “it seems faster” is hardly proof and my results may have been from other factors I had not thought of at the time. So, I delved into the Android source code and pulled a bit of research together to present proof Continue reading

Strange, But True

Sometimes real life is stranger than fiction.

First we have a man carrying a dead weasel being accused of assault. The victim asked, “Why are you carrying a weasel?” Police said the attacker answered, “It’s not a weasel, it’s a marten,” then punched him in the nose, dropped the carcass, and fled.

Up next, a friend of mine volunteers at her local rehab shelter where she meets all kinds of used and abused women.  This tale is one that actually happened… it’s a tale of ” redneck lovin’ ” to use the abused woman’s words (we’ll call her Marylou) as an example of how her ex-husband treated her.

Marylou used to be a housewife. One Christmas, she received two gifts from her husband: a toaster and a dildo. She gave him a confused look and that’s when he said to her, “If you don’t like the toaster, you can go fuck yourself.”

Last up, we have Titanic II sinks on maiden voyage.

Most people would think twice before buying a boat named Titanic II. And sure enough, when Briton Mark Wilkinson took the 4.8-metre cabin cruiser out for its maiden voyage, it promptly sank. “If it wasn’t for the harbourmaster, I would have gone down with the Titanic,” Mr Wilkinson, who had to be fished out of the sea at West Bay harbour in Dorset, southern England, told local media. One eyewitness said: “It wasn’t a very big boat – I think an ice cube could have sunk it!”

 

Android: Notification Icons

The Android notification bar has been white for a very long time. A great many apps that put up icons inside this bar create black icons with transparencies so they appear black on white when viewed against this white notification bar. Unfortunately, with Android 2.3.3+ and 3.0+, the notification bar is now black. Black icons on black bars do not show up well at all.

I highly advise against creating separate icons for the different versions and instead offer the tip of creating a white background for your black icons. In my apps that require a notification icon, I gave the icons a round, white background that used the alpha channel to fade the white from the center to the edge. The effect is that on the older, white notification bars, no difference is detected since white fading into white is the same thing as nothing at all. On a black background, however, the effect is that my black icon is visible within a white circle that fades to black, making it look like a modern, 3D rounded icon.

Example Notification Icon

Personally, I detest the current state of my 2.3.4 phone’s notification colors since most of the apps currently use black or dark grey notification icons (including stock apps) and as such makes it nearly impossible to see them at a glance when checking my phone for messages out in bright daylight. Whomever’s bright idea it was to push this change out to phones that have been using and expecting white notification bars for years now should be given a painful wedgie!

PHP: Query Result Loops

Pro Tip: when you loop through the results of a query like this:

$theDatabase->getSqlData($theSQLtext);
while ( $theDatabase->getNextRow() ) {
    //... do a ton of stuff ...
}

I would like to point out that it will fail eventually. Why? Oh there’s nothing wrong with it, per se…

But if somewhere in all of that ton of stuff inside the while loop you ask the database for something else (like a small list of items for a drop down control), then when you get back to the “while” line, it will now either return the wrong data row or most likely just end prematurely — because of lazy coding!

All that is needed to avoid this hard to detect bug, is to save off the query result given in the first line and use it in the “while” line. No question now which row will be returned and everything will be correct no matter how many nested database calls you put inside the while loop.

$theQueryResult = $theDatabase->getSqlData($theSQLtext);
while ( $theDatabase->getNextRow($theQueryResult) ) {
    //... do a ton of stuff...
}

Android Dialogs and onContextItemSelected()

ListViews and GridViews are great widgets to use in an Activity for your app. Sometimes it is useful to also create smaller versions of them for dialogs within your app. There’s only one problem: Context Menus. If you have tried to put a context menu on a ListView inside a dialog, you may have found out that while onCreateContextMenu() is called, onContextItemSelected() is not. There is a workaround, though, because onContextItemSelected() is actually a convenience method called from onMenuItemSelected(int, MenuItem). If you add the following method to your dialog containing the ListView (or GridView), you will find that onContextItemSelected() is working again.

@Override
public boolean onMenuItemSelected(int aFeatureId, MenuItem aMenuItem) {
    if (aFeatureId==Window.FEATURE_CONTEXT_MENU)
        return onContextItemSelected(aMenuItem);
    else
        return super.onMenuItemSelected(aFeatureId, aMenuItem);
}

 

Android: Programmatically Show the Soft Keyboard, If Needed

If you are expecting user input, a polite app will check to see if there is a hardware keyboard and if one is not present, then automatically display one so the user does not have to click the edit box first in order to pop one up. This kind of behavior is especially nice if there is only one input box being presented. While there are a few methods available out on the net in various places, I wrote my own to be compatible with Android 1.5+ and works in all cases where a keyboard is not part of the physical device as well as does nothing if a physical device has a keyboard.

The source code provided is written from the perspective of a static utility class.

    /**
     * Show soft keyboard if device does not already have a hardware one available.
     * @param aView - the View that will receive the keyboard input
     */
    public static void popKeyboard(final View aView) {
        aView.post(new Runnable() {
            @Override
            public void run() {
                ((InputMethodManager)aView.getContext().getSystemService(
                        Context.INPUT_METHOD_SERVICE)).showSoftInput(aView,
                        InputMethodManager.SHOW_IMPLICIT);
            }
        });
    }

Android ListView and setSelection

Android’s ListView is a powerful class that is capable of presenting a list of whatever you wish fairly easily. One of the issues that has vexed me has been scrolling the ListView to a particular entry. While newer Android versions have provided better support in this area, trying to maintain backward compatibility with Android 1.5 presents some challenges. In light of this Google issue and it’s comments, I have come up with a decent method of scrolling a ListView to a particular position if it is not already visible. I clear the focus after setting the selection because users became confused at why an “orange box suddenly appeared” when they did not expressly tap a selection with their finger or scroll with the trackball.

//this method would be part of a ListView class
    @Override
    public void scrollToPosition(final int anItemPos) {
        if (anItemPos!=AdapterView.INVALID_POSITION) {
            int theFirstItemPos = getFirstVisibleItemPos();
            int theLastItemPos = getLastVisibleItemPos();
            if (anItemPos<theFirstItemPos || theLastItemPos<anItemPos) {
                getListView().post(new Runnable() {
                    @Override
                    public void run() {
                        getListView().setSelection(anItemPos);
                        getListView().clearFocus();
                    }    
                });
            }
        }
    }