Picking a Contact photo with Motorola Cliq

Some Motorola Cliq phones are having issues trying to pick a contact photo using something other than the Gallery app that comes with the phone. Motorola is aware of the issue, but I am trying out a workaround for it in my File Browser app. Basically, the problem is that an OutOfMemoryError could result from attempting to pick a large photo because the Intent being used does not specify the size to be returned. Normally, I would just use getIntExtra(“outputX”,defX) and getIntExtra(“outputY”,defY) in order to get what the caller wanted as a size, but since Motorola’s contact app does not provide those Intent Extras, it would return the full sized photo.

Instead of waiting for Motorola to modify their app, I decided to check the name of the caller and provide a default size for that particular app.

if (myActivity.getCallingPackage().equals("com.motorola.blur.contacts")) {
    outputX = outputY = 48;

Android Dialog Button onClicks

One practice I’ve come to standardize in my apps has been to take dialogs with buttons that perform some kind of action or processing and then dismiss the dialog and instead place that dismiss() call as the very first line within the onClick handler.

new View.OnClickListener() {
    public void onClick(View v) {
        Thread.yield(); //optional
        /* do my action here */

On some of the more sensitive operations (like file delete), I even put a Thread.yield(); after the dismiss so that the dialog will be sure to go away before any more processing is done. The reason you want to dismiss the dialog right away is so that you avoid getting occasional double presses in case the phone is slow to perform your process or action. Nothing is worse from a user’s perspective than to have the phone not react fast enough and so will keep pressing buttons in the hopes that it will finally do something. If you code your buttons to do something each time a button is clicked, then you can have potentially disastrous results. In my case, having multiple file deletes would be a disaster when the user only wanted to delete one file and the phone just hiccuped on the confirmation dialog. Immediately dismissing the dialog gets rid of the temptation to hit the button multiple times while it is doing it’s job.

Android Market vs. Drawable XML

Android drawable resources include the ability to provide and XML resource that specifies a different name for it’s bitmap resource.  It is an especially handy mechanism for library code to refer to a specific drawable resource that your app provides under a different name.

For example a drawable xml named “app_icon.xml” could contain:

<!--?xml version="1.0" encoding="utf-8"?-->
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"

If you used this kind of resource as your application’s icon resource inside your AndroidManifest.xml file, though, you have a problem. While technically, the app will function normally, the Android Market tries to check to make sure your app’s icon meets some guideline criteria and cannot handle an XML drawable. Android Market will refuse to upload your app and tell you “The icon for your application is not valid. Please use a 48×48 PNG.”

If you use XML drawables, please keep this limitation in mind and do not reference them inside your AndroidManifest.xml.

Android: Update to Postmortem Reports via email

With the addition of an Activity stack to my portmortem email reporter, it became apparent that relying on the garbage collector to restore the original exception handler was not an ideal solution. I have added a new method called restoreOriginalHandler() that should be called in your Activity class’s onDestroy() method.

public class MyActivity extends Activity {
    protected PostMortemReportExceptionHandler mDamageReport = new PostMortemReportExceptionHandler(this);

    protected void onCreate(Bundle savedInstanceState) {

    protected void onDestroy() {
        mDamageReport = null;

Original post, updated.

Updated code link (copied from original post):
Full Source

Android: Sharing Resources in Eclipse

The resources of an Android project are difficult to share between projects. In order to create a common library of widgets that reference resources is no simple task and yet is something quite desirable. Creating a “Save File” generic dialog and being able to share it amongst various Android projects not only as an Activity, but as a class ancestor that can be descended from and modified for various specialized cases is a highly desirable feature. I am used to having such a feature in the past with other languages (like Delphi’s Forms) and have been frustrated with Android projects in Eclipse. The various techniques available to potentially share resources all have their fatal flaws. Continue reading

findViewById slow inside ListView adapters

I was reading an article over on charlie.collins’s blog about using a ViewHolder class to cache the results of a findViewById() when used inside the getView() of a list’s adapter. I gave his recommendation a try and I did notice a speed improvement in my app so the observation that findViewById() is a performance hit has enough merit to go out of your way to enable some kind of caching mechanism.

While Charlie went the route of creating a class to hold the various views he was interested in, I decided to take a slightly different approach and make use of the alternative setTag(int, Object) function instead. Continue reading

Working with Android Libraries and shared code

One of the issues that has irked me for quite a while is the fact that there is no easy way to work with a set of shared code between apps in Eclipse that simultaneously gives me instant access to modifying the shared library and also the flexibility of including only the pieces of it that are needed while excluding the rest. Android Library Projects are a big step forward in helping to create a set of shared resources as well as code, but they still lack the flexibility of only including just what you need (not to mention Library Projects cannot use other Library Projects). Continue reading

Android 2.3 SDK and Formatted String Resources

The Android 2.3 SDK in Eclipse enforces the optional Argument Index if you use multiple arguments inside a string resource.

Still OK: 

"Hello %s."

Flagged as an error: 

"Hello $s, %d days have gone by."

Google is taking issue with implicit argument ordering on the grounds that it is not Best Practice to leave it up to the translators to place the argument specifiers if they need to shift around the order due to language grammar. While I feel that taking away Continue reading