Custom Toast


Toasts are the preferred Android mechanism to deliver short messages to users. But, they tend to be kind of boring. So, why not make them more exciting? Let’s build a custom toast and make it pop!

Custom Toast

Custom Layout

First thing we’ll need is a custom layout for amazing toast. Let’s start off with something simple, a TextView and an ImageView:

Custom Toast

Awesome, we’ve defined our Toast’s layout. Time to use it.

First thing we’ll need to do is inflate it and initialize its views:

Next, we’ll create a new toast and add our custom view to it:

We can customize it even further: to make things interesting, we can also define the Toast’s gravity – to control where it appears on the screen:


And we’re done, simple as that! This is what the final thing looks like:

And just call it with:


Get the full source code here.

Share this on:

Logcat Recorder


Logcat is an Android mechanism used to collect and view system debug output. This is extremely useful for debugging and QA testing, as it provides valuable information about what the apps are doing.

Under normal conditions, logcat is visible via Android Device Monitor or directly executed from the ADB shell via the logcat command. The purpose of this tutorial is to present a simple mechanism to programmatically capture and filter logcat entries.

Logcat recorder

First thing’s first, we need a nice way to handle the logcat recorder’s status (recording, new log entry, idle). As a result, we create a simple interface to define these events:

Next, we need to define a basic class and introduce our listener:

Now, we need a mechanism to start() recording the logcat. This will essentially create a new thread (to avoid locking the main UI thread), containing a Runtime Process to execute the logcat shell command and continuously record its output:

We first need to clear the current log via the “logcat -c” runtime process call. Once the log is clear, we can start recording it Runtime.getRuntime().exec(“logcat“) and, optionally, add a filter to our recorder Runtime.getRuntime().exec(“logcat | grep ” + filter)Whilst recording, we call our interface’s onNewLogEntry() method to pass on each new log entry.

To wrap this up, we also need a method to stop() the recording process:

In order to do this, we first check our recorder’s state and simply destroy the logging Runtime Process. Once the recording is done, our interface will serve the full list of recorded log entries via onLogcatRecorderListener.onStopRecording(log.toString());


We just need to add the LogcatRecorder to a new Activity. First, we define ../res/layout/activity_main.xml:

Finally, we define and add a new instance of our LogcatRecorder to it:


Get the full project on GitHub.

Share this on:

Creating a Compound View in Android


Often, when developing Android applications, groups of views tend to be used in multiple places. In order to make things easier, it is considered good practice to encapsulate them in a custom compound view. This allows the same custom view component to be reused throughout the app.

A compound view or compound component is just a view composed of a group of views. This tutorial focuses on building a very basic compound view and defining some methods that change its state.

Creating the Compound View

Creating a Compound View is, in some respects, somewhat similar to creating a new Activity. A new class is created which contains all the view’s children and some methods to manipulate them.

To get started, we’ll first create a new XML layout file in /res/layout/view_article.xml. This will contain the compound view’s children:

Next, we need a class to inflate our new Article View. For simplicity’s sake, we’ll extend a basic RelativeLayout and define our child components. When the view is added to an Activity, it will basically act as a RelativeLayout and allow developers to customize it accordingly.

It is considered best practice to handle the instantiation of our UI components in the onFinishInflate() method in order to prevent any NullPointerExceptions, especially when using ImageViews with large Bitmaps.

At this point, our new Article View doesn’t really do anything special except displaying its children components. As a result, we’ll add some custom methods to manipulate its states:


Now that the ArticleView is complete, we just need to add it to an Activity. We will first add it to the Activity’s layout XML file:

Finally, we initialize it in the Activity and make use of it’s methods in order to change the ArticleView’s state:


Get the full sample project here.


Share this on:

MVP for Android

Why use the MVP pattern?

One of the problems with traditional Android development is the tight coupling between Activities and business logic. This tends to make testing, extensibility and maintenance rather difficult.

The main idea behind using MVP is to take abstract away most (or all) of the business logic into separate entities (presenters) and only keep the UI logic in Activities.

There are many different types of MVP implementations for Android out there, this article only focuses on the basic principles behind them.


The presenter is a separate class that contains the business logic and a reference to its associated view.

The view itself is abstracted away through an interface. This is implemented mainly to allow the view to be mocked in a unit test or replaced with any other view that implements this particular interface.


The view is defined as an Interface which can be implemented by any Activity, Fragment or any type of Android View. This view contains methods that handle all UI logic.


The last step is to link everything together: a new Activity is created which holds a reference to the presenter and implements the View Interface.


Get the full sample project here.



Share this on: