Lots of little improvements and bug fixes along with a couple of new features. You can read about all the change details over in the changelog. The biggest changes are that  thumbnails are now being cached for 3 days and the new option to “Use Full Screen” which will hide the Notification Bar (aka Status Bar). The “Use Full Screen” option is only available to Android pre-3.0 since you cannot hide the Notification bar in 3.0 and 4.0+.

Thanks to all my translators for helping me with this update and a special thanks goes out to Raffaele Dell’Aversana for translating the entire app into Italian!

I hope you all enjoy using it as much as I do. =D

public void onCreateContextMenu(ContextMenu aMenu, View aView, ContextMenuInfo aMenuInfo) {
	AdapterView.AdapterContextMenuInfo theMenuInfo = null;
	try {
		theMenuInfo = (AdapterView.AdapterContextMenuInfo) aMenuInfo;
	} catch (ClassCastException e) {
		return;
	}
	File theFile = myActivity.getListItem(theMenuInfo.position);
	//...snip rest of code...
}

The only way that theMenuInfo would be NULL in order to cause the NullPointerException is that the passed in aMenuInfo was NULL — and that is not supposed to be the case.

I am not quite sure how such an event occurred. It could be a result of “right-clicking” on a spot where there is no list item shown, except that the behavior in that case should have not resulted in a context menu since there is no item there at all. While I should not have to protect my code against a NULL being passed in for the required ContextMenuInfo parameter, I have to live in the world that is, not the world of should. Who knows, maybe this is the start of a trend where “right clicking” on the “white space” of a list will pass in NULL for that parameter and cause a completely different menu to popup for quick actions that provide the same functionality as clicking on the Menu button and choosing some deeper submenu from that list. Then again, it is probably just a bug in the OS and will be fixed at a later point in time. Either way, it’s best to protect against NULL parameters even if they should never be NULL.

My new code:

public void onCreateContextMenu(ContextMenu aMenu, View aView, ContextMenuInfo aMenuInfo) {
	AdapterView.AdapterContextMenuInfo theMenuInfo = null;
	File theFile = null;
	try {
		theMenuInfo = (AdapterView.AdapterContextMenuInfo) aMenuInfo;
		theFile = myActivity.getListItem(theMenuInfo.position);
	} catch (ClassCastException cce) {
		return;
	} catch (NullPointerException npe) {
		return;
	}
	//...snip rest of code...
}

If you know why the ContextMenuInfo parameter is sometimes NULL, please feel free to share the reason as I know several developers that would be interested in it besides myself.

I was on the Google help forums this morning and I read a post by a guy who said he was getting a 16 gig class 6 memory card for his Nexus One so I figured I would come on here and explain why this individual is spending more money than necessary.

There are two things you need to consider when buying a memory card..

• Size
• Speed

I think most people understand size numbers. The bigger the number, the more music, pics, video, etc you can store on the card.

Speed on the other hand is a bit of a mystery to some.  While bigger numbers mean faster speeds, device limitations are much more severe than size limitations. The common speeds right now are 2, 4 and 6 (I think Panasonic just came out with a 10)

Here is a list what each speed is good for.

Class 2 : H.264 video recording, MPEG-4, MPEG-2 video recording
Class 4: MEPG-2 (HDTV) video recording, DSC consecutive shooting
Class 6: Mega-pixel DSC consecutive shooting, professional video camera

As you can see, Class 6 is beyond overkill for the nexus one. This is intended for high-speed high definition video. Class 4 is also not necessary as it is intended for high-def recording. The nexus one video camera specs: MPEG-4 SP, H.264.

So please, don’t waste your money paying for speed you will never need. If you want to cover yourself just in case you decide to use the card for something else in the future, get yourself a Class 4. Otherwise stick with a high quality Class 2 card.

I like SanDisk cards the best. Here are two: (at really good prices)

SanDisk 8GB MicroSDHC Memory Card

Sandisk 16GB Microsd Card

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!

First, some assumptions need to be made. The list contains m number of items. Each item contains a ViewGroup, such as a LinearLayout or RelativeLayout, consisting of n number of views needing to be found and populated. Small numbers of either list items or views will not show a significant difference, but once you start using more than a handful of either, the difference become noticeable.

findViewById() is O(n!)

The findViewById() Android API method requires an algorithm to search your view hierarchy every time you call it by traversing the entire structure looking for the ID of your view. Traversing the hierarchy to find all n Views will result in the algorithm having O(n!) efficiency at best. A very simple example would be a LinearLayout with 5 views and no subchild views to search through. The first findViewById() would find the first view on the first child; the second find will read the first view and then the second; the third find would read the first, second, and then return the third view; and so on. You can verify my take on this algorithm by researching the Android source code yourself. To help get you started, I will point you to the ViewGroup’s method that actually performs the find (in Android 2.3.4 r1).

ViewHolder is O(1)

The ViewHolder mechanism stores the results returned by findViewById() in a HashMap and subsequent calls search the HashMap for the view instead of using findViewById(). In general, a hash algorithm is fast because it “hashes” the key and turns it directly into the location of the bin where the value is stored, making it an O(1) operation. Since we are using an int for our key and we are using Java’s HashMap, we have an O(1) efficiency (some discussion about this can be found here).

O(m) is better than O(m n!)

Comparing the two methods, ViewHolder is the best case scenario with O(1) and findViewById() comes in second with O(n!), but the distinction becomes even more apparent when you factor in the fact that these methods are done for each item in your list. O(m) is noticeably more efficient than O(m n!) — depending on the values of m and n, this can sometimes be better or worse than O(m²), but it will always be worse than O(m) for lists with more than 1 item.

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.

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!

$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...
}

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

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);
            }
        });
    }

//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();
                    }    
                });
            }
        }
    }