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:

Password EditText


Ever wished that Android had a built-in Password EditText with a Show/Hide button? No? Well, here’s a tutorial for one anyway.

Password EditText


Building a custom Password Edit Text

In order to get a Password EditText we’ll first need to create a custom view extending a EditText. Let’s create a new class:

Next, we’ll need to define some custom attributes for our view. Let’s start off by defining its: action text, colour and size. To make things easier, we’ll need to be able to define these attributes in the view’s layout.xml file. As a result, we’ll need to define these attributes as styleables, by creating a new /res/values/attrs.xml file:

Next, we’ll need to associate these attributes with our custom view. So, let’s start off by giving them some default values:

We’ll now need to initialize them when our view is created:

Awesome, all we need now is the Show/Hide action text. The EditText (being an extension of TextView) has built-in Compound Drawables and we’ll use those to house our action text. Since the end goal is to insert an editable message (SHOW / HIDE) in our custom view, we’ll just need to find a way to convert a String into a drawable – this is where the magic happens. We’ll create TextView and style it with our custom attributes (text, colour, size). Once we’re happy with it, we just essentially take a screenshot of it, convert that into a drawable and assign it as a Compound Drawable:

Great, now we’ve got a custom drawable inside our view. We just need a way to handle touch events to determine what happens when users click it. To do this, our custom view will need to implement a View.OnTouchListener to handle this event. Then, all we have to do is get our drawable’s dimensions  and decide what happens when a touch event is registered within those coordinates:

Wrapping things up

And that’s basically it. We’ve created a custom Password EditText, defined it’s attributes, added a custom editable drawable and defined what happens when users tap it. This is how the final class looks like:

We just need to add it to res/layout/activity_main.xml and see it in action:

Notice that we’re setting our custom attributes in a XML layout file. We can also do the same programmatically:


That’s it. Check out 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: