Consider the code below. It defines a single function for toast, that makes use of context object of Application. The class MyApplication needs to be declared in manifest.xml. The main advantage of such design is

• reduced footprint for activity’s context object.
• at any moment only one toast remains on screen
• reusing single toast object, rather than creating for each show.

public class MyApplication extends Application {

	private static Resources resources;
	private static Context context;

	private static Toast toast;

	/**
	 * Called when the application is starting, before any other application
	 * objects have been created. Implementations should be as quick as possible
	 * (for example using lazy initialization of state) since the time spent in
	 * this function directly impacts the performance of starting the first
	 * activity, service, or receiver in a process. If you override this method,
	 * be sure to call super.onCreate().
	 * */
	@Override
	public void onCreate() {
		super.onCreate();
		Log.i("MyApplication", "Starting app...");
		MyApplication.resources = getResources();
		MyApplication.context = getApplicationContext();

		MyApplication.toast = Toast.makeText(MyApplication.context, "", Toast.LENGTH_SHORT);
	}

	/** Returns the global resources object. */
	public static Resources getResourcesObject() {
		return MyApplication.resources;
	}

	/** Returns the global context object. */
	public static Context getContextObject() {
		return MyApplication.context;
	}

	public static void toast(String message)
	{
		MyApplication.toast(message, Toast.LENGTH_SHORT);
	}

	public static void toast(String message, int duration)
	{
		MyApplication.toast.cancel();
		MyApplication.toast.setText(message);
		MyApplication.toast.setDuration(duration);
		MyApplication.toast.show();
	}

}

Ever heard someone saying “this software sucks”… I love such moments. It makes me laugh, not for the user, but for the poor developer! Users are innocent, they are not concerned about technical details. A software is there to make life simpler and hide complications of a task. It’s your responsibility to make it intuitive and meet users expectation on first impression, rather showing unnecessary (modal) alert boxes or irrelevant (technical) details. You don’t need to be a Usability Engineer. Just,

• stand on users’ shoe and think what is annoying
• don’t take negative feedback as an attack on you and your beliefs.
  Rather it’s a feedback on your understanding about how much you understand your users. In short never reject/resist on feedback.

Nobody hates software more than software developers and nobody distrust software more than software developers. Scott Berkun has written a good post about why software sucks. ( I have heard software engineers saying that they don’t trust online money transactions. Heck !! Do you need President to meet you and ensure? )

Here is what I think you should target as first step:

• Any tasks that you think user should perform by reading Help/Documentation, MUST be automated.
• Even an single unnecessary alert box annoys. Features should be available with less no of clicks. Still this is very subjective matter to discuss. A simple guidelines is – only system errors or exceptions should raise alert-box, tiny information should be modal-less dialogs (or like balloon pop-up).
• users never read entire screen. Default values chosen or default selection of check-boxes makes big difference in a long run.
  E.g. while filling an online form a default selection of check-box “subscribe me for spam mails”. Who does read entire form before clicking submit? None. But it affects your reputation in long run.
• Never hesitate in picking a useful (cool, awesome, sexy, astonishing, amazing! ) feature from competitive software. Ask a simple question – Does it add value to your product? You won’t like this argument, but this is truth. The success of Web is a tiny ‘view source’ feature. Well, this is a fast moving industry where we learn from other, we improve over time. You never blame the world for borrowing tabbed browsing from Opera (originally by NetCaptor). It’s a matter of accessibility, and understanding what your users like and what they dislike is a key to success.
• Don’t recruit incompetent programmers, because a incompetent programmer creates two new jobs a year. If you have a few already, either trains them or fire them. (Sorry pals)

- ankit
( and finally, this is a 100th post on this blog. Happy Blogging! )

Of course you can write –

if( true )
   return;


What if you could simply write return. This helps in testing a function quickly. As a good programming practice we always remove all warnings from code, and such unconditional return statements can be rectified later.

a. Limit the code block. Attempt to wrap one or two statements within try.

b. If an exception is eaten, log details to some logging mechanism. In short never write empty catch catch(Exception) {}.

c. Never eat exception that indicates some bad behavior of code execution like – ArgumentNullException,

NullReferenceException,

ArgumentNullException,

InvalidCastException,

InvalidOperationException,

AccessViolationException, etc;

d. There is a big difference between throw and throw exeception statements. This is in terms of resetting stack trace which the later does. If you are writing a framework or want to hide your internal implementation use throw exception, otherwise use throw only.

- Ankit