Android & MVC Pattern

MVC (Model-View-Controller) is a design pattern that separates the user interface (View) and the business rules and data (Model) using a mediator (Controller) to connect the model to the view. All objects in the application must be Model object, View object or Controller object.

Model Object
Model objects model the things the application is concerned with. This is the data layer, responsible for managing the business logic and handling network or database API. For example, user, product, photo on a server, a television show. These objects have no knowledge of the UI and are just concerned with holding and managing data. Model classes are the custom classes the developer creates.

View Object
If you see it on screen, it is a view. View objects know how to draw themselves on the screen and respond to user touches. All the view objects in the application compose the view layer.

Controller Object
These objects tie the view and model objects. They contain the application logic. Controllers are designed to respond to various events triggered by view objects and to manage the flow of data to and from model objects and the view. In Android, controllers are usually subclasses of Activity, Fragment or Service.

Communication in this architectural pattern

Model and View objects do not talk to each other directly. The controller sits in the middle of everything, receiving messages from some objects and sending out instructions to other objects.

[1] Credits: Android Programming: The Big Nerd Ranch Guide


MVC makes classes easier to reuse. A class with restricted responsibilities is easier to reuse than the class with fingers in every pie. Views can be updated without any concern about what changes to make in model classes. The model can be separated and dealt with independently without having to do anything with UI components in the application. Even the application template can be exported as a library so that another developer can use it in their application or so that you can use it in your next app.


Since the user interface changes a lot compared to the business logic of the application, it is better to separate the user interface functionality from the data logic. Both View and Controller depend on the Model for getting the data and updating the data respectively. Model can be tested independently which makes it easier to maintain the application in the long run.

Next time when you create a file, always ask yourself: What component of the MVC pattern does it represent? If you can’t decide, you may need to refactor the code.

Activities & Intents

This post introduces Activities in Android and how Intents are used for any communication between activities or any other application components.


Activities are the fundamental building blocks of Android applications. An activity is an interface between the screen and the application. Activities, services, any application components must be declared in the AndroidManifest.xml file. If it is not done, the application considers that component of the application does not exist and often runtime exceptions are thrown when the application is being run.

This declaring of an activity, however, does not have to be done manually in the manifest file. But any kind of attributes associated with the activity can be added to the activity explicitly in the AndroidManifest.xml. For instance, an activity can be declared as the launcher activity (the first screen of the application that shows up on our screens as it runs) can be done by adding the line <category android:name="android.intent.category.LAUNCHER"></category> in the corresponding activity element in the manifest.

In any case, if an activity has to be declared manually, it can be done by creating an <activity> element in the manifest file. Next, the name and label of the activity can be specified using android:name and android:label attributes respectively. More can be learned about its attributes at

Communicating with intents

Intents are the glue between activities. Any communication between activities happens via intent. Intent holds the necessary information needed to perform an action. An intent usually has two pieces of information – action and data. In other words, intents carry information that the system uses to determine which component to start plus the information that the recipient component uses to act to perform an action properly

Intents are of two types –

  • Explicit: Explicit intents explicitly mention the component which should be called. The Java class is used as an identifier in explicit intent call.
  • Implicit: In an implicit intent, the action to be performed is specified and data is optional. Based on the type of action and data, the component that fits the most is started by the system. In some cases, if multiple components fit, the user is prompted with possible options and thus the user can decide which component to use to perform the specified action.

Explicit intent example

Intent intent = new Intent(this, SecondActivity.class);
intent.putExtra(Intent.EXTRA_TEXT, "sample text");

In the above example, the EXTRA_TEXT identifier is used as an identifier or any custom string can be used as well. The concept of key-value pairs is used when transmitting data using intents between two components. We use the same key to get the data out as the one we used to put data onto intent. getStringExtra() is used to fetch data from the intent. Intents are not just limited to sending String type data. Any basic Android data types can be transmitted between app components.

Implicit intent example

Intent intent = new Intent(Intent.ACTION_VIEW);

In the above example, an intent object is created by specifying ACTION_VIEW as what we want to do. A URL is specified in the data, since the intention is to view the website, the default browser is launched (different data could launch different apps). Intent resolution mechanism operates by matching the best intent from the installed application packages.

Complete running examples of starting a new activity from a current one using implicit intent call and switching between activities using explicit intent can be checked at and respectively.

More on activities like storing data persistently, returning results from an activity is coming up in the next post. Keep reading!

OAuth & OSM

The number of libraries, APIs available today to perform variegated tasks is profuse. Despite the abundance, sometimes alternatives are minimal and from these scarce resources, a solution that fits our specific needs are inconsequential. Lately working on OAuth for a project based on OpenStreetMap, I could not find a convenient guide to understand and implement. Persevering on making it functional, I authorized my Android application the access to OSM servers.

By the use of Signpost, things became a little simpler. Use of Twitter API, Facebook API with signpost is all over the web. A novice developer of Android like me cannot go on without a little fretting. Further in this post, I am sharing the screenshots of the authentication and authorization.

The screenshots are self-describing. In an upcoming post, I will write a tutorial on how to execute this task.

Change Main Activity in Android

Often we miss out adding splash screen of the application in the initial development phases, or for an instance you might want to change the main activity or the launcher activity at some later stage of development. In order to incorporate this change, a minor modification in AndroidManifest.xml file is to be done.

Say you have two activities A and B. Say initially A is the main activity and now you want to make activity B as the main activity. Open the AndroidManifest.xml file. Initially the entry for activity A in the manifest looks like:

<activity android:name=".A">
    <intent -filter>
        <action android:name="android.intent.action.MAIN"></action>
        <category android:name="android.intent.category.LAUNCHER"></category>

Either delete the lines in the intent-filter tag or replace the activity name with B and add a new entry for activity A.

Overall the activity B’s entry should be like:

<activity android:name=".B">
    <intent -filter>
        <action android:name="android.intent.action.MAIN"></action>
        <category android:name="android.intent.category.LAUNCHER"></category>

A single line entry for activity A will look like:

<activity android:name=".A"></activity>

It’s pretty simple and clear, all you have to do is replace the name or add a new entry.

Passing Data using SharedPreferences

Sometimes while passing data between two activities, we are just concerned with passing data and not launching the activity to which the data is passed. SharedPreferences make this data passing easier without necessitating launch of the recipient activity. The usage is discussed briefly below:

Say you have two activities A and B where A is the sender and B is the recipient. Use the following code in activity A.

SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(A.this);
SharedPreferences.Editor editor = prefs.edit();
editor.putString("string", "This is a string.");
editor.putInt("number", 50);

In activity B, use the following code to receive the variables from sender activity:

SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(context);
String s = prefs.getString("string", "hello");
Integer i = prefs.getInt("number", 0);

Default values should be set in the getString(), getInt() or any of the get methods used in the recipient activity. The variables in which the received values are stored can be used for further processing in activity B.

For further details on SharedPreferences, the official documentation can be checked at this link.