DEV Community: Zuhaib Ahmad

Building a ChatGPT App with Flutter

Zuhaib Ahmad — Sun, 05 Mar 2023 06:49:00 +0000

Flutter is a state-of-the-art cross-platform mobile development framework owned by Google that allows developers to create visually stunning, high-performance native applications for iOS, Android, and web. On the other hand, ChatGPT is an AI model that utilizes the power of GPT to generate human-like responses to chat messages.

In this tutorial, we'll be putting both technologies together to create a ChatGPT application using Flutter. We'll be utilizing the Dart programming language and Flutter's widgets to communicate with ChatGPT API and display the chat interface.

Prerequisites

Before we start building our application, you'll need to set up your development environment. Here are the necessary prerequisites:

Flutter SDK installed on your machine.
An IDE, such as Android Studio, IntelliJ IDEA, or Visual Studio Code.
A working knowledge of Flutter and Dart.

Setting up the Application

Create a new project in your IDE of choice.
Add the http package and the flutter_dotenv package to your pubspec.yaml file using the dependencies property.

dependencies:
  flutter:
    sdk: flutter
  http: ^0.12.2
  flutter_dotenv: ^4.0.0

Create a .env file in your project's root directory and add your ChatGPT API key.

OPENAI_API_KEY=<YOUR_API_KEY>

Import the necessary packages in your main.dart file.

import 'dart:convert';
import 'package:flutter/material.dart';
import 'package:http/http.dart' as http;
import 'package:flutter_dotenv/flutter_dotenv.dart';

Create a ChatPage class that will display the chat interface and handle the user's input.

class ChatPage extends StatefulWidget {
  const ChatPage({super.key});

  @override
  ChatPageState createState() =&gt; ChatPageState();
}

class ChatPageState extends State&lt;ChatPage&gt; {
  // Map of messages and whether they were sent by the user
  final _messages = &lt;String, bool&gt;{};
  final _textEditingController = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('ChatGPT Demo'),
      ),
      body: Column(
        children: [
          Expanded(
            child: ListView.builder(
              itemBuilder: (context, index) {
                var isUserMessage = _messages.values.elementAt(index);
                return Row(
                  mainAxisAlignment: isUserMessage
                      ? MainAxisAlignment.end
                      : MainAxisAlignment.start,
                  children: [
                    Flexible(
                      child: Container(
                        alignment: isUserMessage
                            ? Alignment.centerRight
                            : Alignment.centerLeft,
                        padding: const EdgeInsets.all(16),
                        margin: EdgeInsets.only(
                          top: 4,
                          bottom: 4,
                          left: isUserMessage ? 40 : 4,
                          right: !isUserMessage ? 40 : 4,
                        ),
                        decoration: BoxDecoration(
                          borderRadius: BorderRadius.circular(8),
                          color: isUserMessage ? Colors.blue : Colors.grey,
                        ),
                        child: Text(_messages.keys.elementAt(index)),
                      ),
                    ),
                  ],
                );
              },
              itemCount: _messages.length,
            ),
          ),
          TextField(
            controller: _textEditingController,
            onSubmitted: _sendMessage,
            decoration: InputDecoration(
              hintText: 'Type your message',
              contentPadding: const EdgeInsets.all(8),
              suffixIcon: IconButton(
                icon: const Icon(Icons.send),
                onPressed: () =&gt; _sendMessage(_textEditingController.text),
              ),
            ),
          ),
        ],
      ),
    );
  }

  void _sendMessage(String message) async {
    setState(() {
      _messages[message] = true;
      _messages["..."] = false;
    });

    // Send API request to ChatGPT
    final response = await http.post(
      Uri.parse('https://api.openai.com/v1/chat/completions'),
      headers: {
        'Authorization': 'Bearer $openAiKey',
        'Content-Type': 'application/json',
      },
      body: jsonEncode(&lt;String, dynamic&gt;{
        'model': 'gpt-3.5-turbo',
        "messages": [
          {"role": "user", "content": message}
        ]
      }),
    );

    if (response.statusCode == 200) {
      final json = jsonDecode(response.body);
      setState(() {
        _messages.remove("...");
        _messages[json['choices'][0]['message']['content']] = false;
      });
    } else {
      print('Request failed with status: ${response.statusCode}.');
    }

    // Clear text field
    _textEditingController.clear();
  }
}</code>
        </deckgo-highlight-code>
1. Modify your `main.dart` file to display the `ChatPage` when the app starts.
<deckgo-highlight-code language="dart" theme="material" line-numbers="true">
          <code slot="code">final openAiKey = dotenv.env['OPENAI_API_KEY'];

void main() async {
  await dotenv.load();
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'ChatGPT Demo',
      home: ChatPage(),
    );
  }
}

That's it! You now have a fully functional ChatGPT application built with Flutter. Launch your app and start chatting with ChatGPT.

For suggestions and queries, just contact me.

Painless UI Testing with Kaspresso

Zuhaib Ahmad — Sat, 14 Mar 2020 11:00:00 +0000

A few months ago I wrote a blog post under a similar title about better Unit Testing for Kotlin with Kotest (formerly KotlinTest). The focus of that post was to demonstrate a more organized, boilerplate free and self-documenting TDD/BDD friendly testing framework for Kotlin.

I have been using Kotest for about a year now and it is safe to say that it has encouraged me to test more of my code. While frameworks like Kotest and Spek provide a good alternative for unit testing, the UI part still feels lacking. Most of us still use Espresso for writing UI tests that, even with its super clean API, feel very repetitive and verbose. For some time, I worked around this by extracting the repetitive code for reuse. It wasn’t very clean.

Caffeine Overflow

Part of my dev-wishlist was to someday establish this perfect loop of TDD flow with Android where all the features start with a failing UI test, followed by multiple unit tests to satisfy the business logic. At the end of which we have a solid well-tested and self-documented feature. So I started searching for other options which lead me to several frameworks, most of which were named after a coffee.

One of the great finds was Kakao by Agoda, it provides a more readable and reusable DSL on top of Espresso. The idea is to encapsulate the UI in Screen interfaces which can then be reused. Here is an example of what a form UI would look like:

The resulting tests are reduced to a combination of actions and assertions inside the screen:

But Wait, There’s More!

Kakao seemed like a pretty reasonable solution until I stumbled upon Kaspresso. It combines Espresso and UI Automator into single DSL based API. For the Espresso part, it just wraps around Kakao with some added features such as improved logging, built-in screenshots, ADB command execution, runtime permissions management and more.

Grade Calculator 2.0

What could be a better example than to revisit the grade calculator we built in the previous post? Let’s add some UI and this time build in a purely Test-Driven style.

Installation

Let’s create a simple Android project with an empty Activity. Then add the following test dependencies:

If you set up your project using the Android Studio wizard, then most of these dependencies should already be present. The only dependencies that we must add manually are Kotest, Mockk, and Kaspresso.

Kotest and Mockk are the same as last time for unit testing and mocking, while Kaspresso will be used for UI tests.

Adding The UI Test

Let’s add a UI test for the happy path of our calculator without touching the activity first:

If we try to run this test, it will fail because we have not added the GradeCalculatorScreen yet. This test serves as a blueprint of what we want to achieve for the happy path of grade calculation. Let’s break down each step:

TestCase - The first thing you might have noticed is that the test class extends TestCase, which is a base class provided by Kaspresso that gives access to most of its features.
Activity Test Rule - Next, we create an activity test rule for the grade activity. This part is the same as normal Instrumentation tests.
GradeCalculatorScreen Instance - This instance of the screen will be used in the Kaspresso DSL.
Test Body - For the test body, you might notice the chain of 3 separate blocks. You can use the block syntax instead of the expression body, but then it will add an extra indent to all the code inside the block which I do not like very much.
Before-After-Run - The before and after blocks are interceptors for anything you might want to do before or after the test respectively. For example, before can be used for mocking and after can be used to release resources.
Steps - Finally, the run block is where actual testing happens
- Every step is described with a step block. This part is optional, you can skip the steps if you want and directly write the encapsulating code. However, it is very helpful since not only it provides a comment on what is happening but this information also gets printed in the logs.
- In the first step, we launch the activity, this can be done directly with the test rule though.
- In the next two steps, we perform some actions on the GradeCalculatorScreen and then verify their results. Note that all the methods come from the library, we only provide view bindings in the Screen implementations.

Implementing The Kaspresso Screen

At this point, we cannot even compile the application due to missing classes. Let’s provide an implementation for our GradeCalculatorScreen.

As explained earlier, the screen class just binds the UI elements and organizes them into one place. Since we do not have these elements in the layout XML, the project won’t compile unless we add them too. So here’s a simple layout for it:

Now, the test will compile but the test will fail because we have not provided any business logic yet.

Adding The Business Logic

The next step is to provide the business logic to calculate the grade.

Since there is nothing new about this part, I will just copy the tests and resulting logic from the previous post. You can read the Kotest post to understand better.

Create a GradeCalculatorSpec class inside the test package and add the specs for grade calculation:

Once all the tests are passing, the resulting implementation would look something like this:

Binding It All Together

The final step is to bind the GradeCalculator with the UI. Let’s add a click listener to the button and use the user input to calculate the grade.

If all goes well, all tests should be passing now. Also, if you look at the logcat output, it will have a complete summary of all test steps.

Bonus: If there was no issue with permission, it should have also captured the screenshots for each step automagically! Look inside the gallery for them.

Here’s the pidcat output of my tests:

Using Kaspresso, you can also handle runtime permissions, change device state, execute ADB commands right from your code. The flexibility it provides for writing tests in truly amazing.

Conclusion

This is a very basic example that does not handle any edge cases. However, I hope it was enough to give you a taste of test-driven development with Android.

We started with a crude idea without any implementation details in mind and used tests to shape our logic. There are a couple of benefits to this approach:

We ended up with a minimum workable solution with 100% code coverage
As every part of our logic is backed by Unit and UI tests, the tests themselves serve as a documentation for the features.
Since both the architecture and the logic is shaped by the tests themselves, it is quite easy to freely refactor the code further without worrying about regression bugs.

You can find complete source code for this post here

For suggestions and queries, just contact me.

Painless Unit Testing with Kotlintest & Mockk

Zuhaib Ahmad — Sat, 07 Sep 2019 11:00:00 +0000

Testing is hard and not everyone likes to spend their time writing unit tests when they could be building shiny new features.

While almost every developer understands the value of testing their code, most of us fall prey of laziness in the face of approaching deadlines and the prospect of more exciting work.

In this post, let’s understand why unit tests serve as the backbone of successful products and learn a new way of writing tests that is much simpler, intuitive and appealing.

Why Testing Matters

Since I mostly work with Android applications. I’ll let you in on a little secret. More than half of the code bases you will come across will have little to no tests. Not just the crappy ones, but sometimes products with thousands of users.

This is often due to the complex and dull nature of old school JUnit based testing. Not only the process is quite boring, it also requires a lot of repetitive boilerplate code to be written for even the simplest scenarios, making testing a very time-consuming process.

Obviously, when you are in a rush to take the product out as soon as possible, testing becomes the least desirable practice.

More often than not, the end result is that the project becomes unmaintainable within a year. I have seen organizations rewriting already published products only because the code base has become unmaintainable due to spaghetti code that is rotten with bugs.

Obviously this is not a desirable situation. Testing your code for bugs and architectural flaws from the beginning solidifies your product to be manageable in the longer run.

“If you can not measure it, you can not improve it.” - Lord Kelvin

Testing As You Go

Laying the foundations of your project with extensive testing is not a new idea. Behavior Driven Development has been around for decades.

The practice is to turn feature specifications (or user stories) into a set of unit tests and then writing code that satisfies those specs via passing tests.

This results in co-development of both your features and their tests side by side. Coupled with a Continuous Integration solution, this setup almost guarantees that you will never have any regression bugs.

Specification Based Testing In Practice

Cucumber is the most widely used BDD testing framework right now. It provides a plain language parser called Gherkin which can be used to write tests in plain English that non-programmers can also understand. The framework turns these specifications into acceptance tests which also serves as the documentation for each feature. Here is what a test is written in Gherkin looks like:

Feature: Calculator
  As a user
  I want to use a calculator to add numbers
  So that I don't need to add myself

  Scenario: Add two numbers -2 & 3
    Given I have a calculator
    When I add -2 and 3
    Then the result should be 1

  Scenario: Add two numbers 10 & 15
    Given I have a calculator
    When I add 10 and 15
    Then the result should be 25

Neat! Isn’t it? This spec results in unit tests that run with Cucumber. Since this post is not about Cucumber, I won’t go into the implementation details. You can visit this tutorial for the full tutorial on BDD style testing with Cucumber. I used the same article to borrow the above example.

Some other popular BDD frameworks include Lettuce, Jasmine, SpecFlow, Spek, Behat, Jdave and Jbehave

Problems with JUnit

JUnit is an industry-standard at this point for all things Java. It has ruled the Java development for decades now and it works. But since it was built for Java, it brings with it most of the common pitfalls of Java-based technologies that feel backward, especially in the world of modern programming languages like Kotlin, JavaScript and Python.

Having said that, writing all styles of tests are entirely possible with JUnit. Mockito provides a BDD style extension in its core library that allows you to do similar Give, When, Then style testing within JUnit test cases.

Let’s take a look at some of the problems associated with it and why I believe vanilla JUnit is not a good combination for a powerful language like Kotlin:

Code Repetition

Like everything in Java, JUnit is also quite verbose. This results in too much repetition of similar contents with a slight change of logic to test different scenarios.

How many time have you had a test for a HAS and a HAS-NOT condition with all the same contents except for a boolean? For example, a testUserAccessWhenHasToken and then testUserAccessWhenNotHasToken.

Of course, you can stuff in all your assertions in one test at the cost of readability. However, a good test is supposed to be granular i.e. targeting one case per test.

Also, your test code is guaranteed to grow as your project gets bigger and at some point, your test code will surpass your application code. If you want to look at examples of this, try looking into the source code of any popular open-source projects such as RxJava, Retrofit, OkHttp, Picasso, etc. Almost all of them have 1.5x to 2x more test code compared to their business logic.

Lack Of Contextual Information

If you are like me, then one of the first things that you may have done while switching to Kotlin was to change your long JUnit test names like fun onTouchOutside_shouldDismissDialogAndResumeStreaming() with back tick notation. While a big improvement, it gave us a license to go wild with it in our attempts to provide more contextual information about each test case. So now our test case has evolved into something like this: fun `on touch outside, dismiss the dialog and resume streaming the paused song` ()

The real issue here is that these names are not enough to provide full context about the test. Unless you are willing to write an entire paragraph to define the pre and post conditions for the scenario.

Another problem here is with the organization of test cases. Most of the test cases have some shared code that can be logically structured into a hierarchy. However, because JUnit only allows you to write tests in the form of class methods. So you end up writing more tests, more code but with less context about the overall theme of the current group of tests.

A Better Way To Write Tests

The reason behind giving you a taste of Cucumber BDD was to show what it would be like to have such idiomatic tests.

Let’s define a set of specification that we want to build and test. We will be using two libraries Kotlintest and Mockk to help us write tests.

Feature

Let’s build a grade calculator that tells you your grade based on the marks you obtained. Here are the rules for grading:

When obtained marks are 90 or above, then grade is A.
When obtained marks are between 80 and 89, then grade is B
When obtained marks are between 70 and 79, then grade is C
When obtained marks are between 60 and 69, then grade is D
When obtained marks are below 60, then grade is F

Installation

First, create an empty Kotlin or Android project and add the following two dependencies:

testImplementation 'io.kotlintest:kotlintest-runner-junit5:3.3.2'
testImplementation 'io.mockk:mockk:1.9.3.kotlin12'

The first dependency is Kotlintest which is a testing library built on top of JUnit. It takes advantage of Kotlin’s DSL capabilities to support various type of testing styles.

Mockk is a Kotlin-based mocking library with a very clean syntax that blends really well with Kotlintest’s specs. It also provides a much more flexible API and a much wider set of feature compared to Mockito or Powermock.

Implementation

Let’s start by creating an empty GradeCalculator class and converting our specifications into a Spec.

class GradeCalculatorSpec : BehaviorSpec({

    Given("a grade calculator") {
        val calculator = spyk(GradeCalculator())

        every { calculator.totalMarks } returns 100
        val total = calculator.totalMarks

        When("obtained marks are 90 or above") {
            Then("grade is A") {}
        }
        When("obtained marks are between 80 and 89") {
            Then("grade is B") {}
        }
        When("obtained marks are between 70 and 79") {
            Then("grade is C") {}
        }
        When("obtained marks are between 60 and 69") {
            Then("grade is D") {}
        }
        When("obtained marks are below 60") {
            Then("grade is F") {}
        }
    }
})

This does not quite look like our traditional JUnit test. So let’s break it down and understand bit by bit:

BehaviorSpec - We are extending something called a BehaviorSpec which is basically a Spec written in BDD style (remember the Give, When, Then from Cucumber?). There are dozens of different other Spec styles available in Kotlintest.
Spyk - You may notice that I wrapped the GradeCalculator object with a spyk method. If you have used Mockito before than the concept is the same. Basically, a spy is a wrapper that lets you mock some methods and variables of the object while using the actual values for the rest. I did it to demonstrate the use of Mockk here.
Every/Returns - Similar to Mockito’s when/then style, this construct is used by Mockk to prepare mock values. All we are saying is to return a mock value whenever anyone in this code block asks for this value. The value we are mocking is total marks which are going to help calculate the grade.
When/Then - Finally, there are a bunch of Then blocks nested inside When blocks with some description. The When block is nothing but a way to organize tests in a logical fashion while each Then serves as the actual test where the assertion happens. So you can have a test with just a Then statement but then there’s no point of using it.

Next, let's add some functionality to the GradeCalculator class.

class GradeCalculator {

    var totalMarks = 0

    fun getGrade(obtainedMarks: Int, totalMarks: Int): String {
        val percentage = getPercentage(obtainedMarks, totalMarks)
        return when {
            percentage >= 90 -> "A"
            percentage in 80..89 -> "B"
            percentage in 70..79 -> "C"
            percentage in 60..69 -> "D"
            else -> "F"
        }
    }

    private fun getPercentage(obtainedMarks: Int, totalMarks: Int): Int {
        return (obtainedMarks / totalMarks.toFloat() * 100).roundToInt()
    }
}

Here I added a totalMarks field which we mock in our test. This value is used in the getPercentage method to calculate the percentage between total and obtained marks.

Finally, the getGrade calculates the grade by comparing the calculated percentage with different ranges.

You can build this class in a TDD fashion by running the tests first and adding the functionality to make the failing tests pass one by one. I believe the end result would still be somewhat similar.

In the end, let's add some assertions to test the specifications we just wrote. The final implementation would look something like this:

package com.zuhaibahmad.bddtestingtutorial

import io.kotlintest.shouldBe
import io.kotlintest.specs.BehaviorSpec
import io.mockk.every
import io.mockk.spyk

class GradeCalculatorSpec : BehaviorSpec({

    Given("a grade calculator") {
        val calculator = spyk(GradeCalculator())

        every { calculator.totalMarks } returns 100
        val total = calculator.totalMarks

        When("obtained marks are 90 or above") {
            val grade = calculator.getGrade(93, total)

            Then("grade is A") {
                grade.shouldBe("A")
            }
        }
        When("obtained marks are between 80 and 89") {
            val grade = calculator.getGrade(88, total)

            Then("grade is B") {
                grade.shouldBe("B")
            }
        }
        When("obtained marks are between 70 and 79") {
            val grade = calculator.getGrade(78, total)

            Then("grade is C") {
                grade.shouldBe("C")
            }
        }
        When("obtained marks are between 60 and 69") {
            val grade = calculator.getGrade(68, total)

            Then("grade is D") {
                grade.shouldBe("D")
            }
        }
        When("obtained marks are below 60") {
            val grade = calculator.getGrade(59, total)
            Then("grade is F") {
                grade.shouldBe("F")
            }
        }
    }
})

Outcome

I discussed above that JUnit tests lack contextual information and proper grouping of co-related tests. You can see how every test in the spec has a hierarchy which can be used to compose complex cases.

Furthermore, for this particular style of testing, kotlintest provides an additional And block to allow you to create even more complex tests without losing contextual information. For example, you may want to construct a test like this:

When("user list is fetched from API") {
    And("the internet is NOT available"){
        Then("Test something"){
            // Some assertions
        }
    }
    And("the internet is available"){
        Then("Test something"){
            // Some assertions
        }
    }
}

Finally, not just the tests are well organized, the test results in Android Studio have that nested style too. Here’s the result of our tests in the IDE:

Conclusion

Testing your code right from the start of the project provides a solid foundation for future development.
The idea of TDD and BDD is not new, it forces you to write your domain-specific code and the architecture itself to be testable. However, due to the verbosity of JUnit and tight deadlines, testing falls behind quite often.
Aside from code repetition, another big problem with JUnit is the lack of contextual information due to the flat hierarchy of tests. When every case is represented in the form of a class method, it becomes quite difficult to group and organize related tests.
Modern testing frameworks like kotlintest takes advantage of the flexibility provided by Kotlin to allow writing more intuitive unit tests.
The result is less boilerplate code and more meaningful tests.

You can find complete source code for this post here

For suggestions and queries, just contact me.

Inter-Process Communication in Android - Lessons & Learnings

Zuhaib Ahmad — Sun, 28 Apr 2019 11:00:00 +0000

Recently, I was tasked with building a solution for OTA (Over-the-Air) updates for one of our products at SodaLabs. Now for those of you who are not familiar with the concept, here’s a definition by TechTarget:

An over-the-air update is the wireless delivery of new software or data to mobile devices. Wireless carriers and original equipment manufacturers (OEMs) typically use over-the-air (OTA) updates to deploy firmware and configure phones for use on their networks. The initialization of a newly purchased phone, for example, requires an over-the-air update. With the rise of smartphones, tablets and internet of things (IoT) devices, carriers and manufacturers have also turned to over-the-air updates for deploying new operating systems (OSs) to these devices.

Basically, the updates you receive for your Android, iOS, Windows, Mac or Linux devices are distributed through the mechanism known as OTA programming.

Going the Sandbox Way

We had a couple of choices around how to build this OTA client, but in the end we decided to build it as a completely separate project. The reason was that both the main product and OTA client were equally complex solutions and we didn’t want to make it more complex by adding the OTA as part of the main project.

The OTA would essentially be just a service that runs as a background process and communicates with the main application (the product whose updates this OTA was supposed to manage) via AIDL i.e. the IPC mechanism used by Android.

This was the first time I was going to be working with IPC in general. So unsurprisingly, there was a lot of frustration, learning and fixing through trial and error involved.

My goal in this post is to write about the basics and share some insights from my experience so that you can avoid the confusions that I had to face.

Inter-Process Communication

Let’s start by understanding what Inter-Process communication is. Inter-Process Communication or IPC, in short, is a mechanism that allows multiple independent processes to communicate and exchange data.

This communication is often achieved through the use of some shared interfaces defined through Interface Description Language (IDL). What it does is basically establish a set of rules that all the interested processes follow. These shared interfaces serve as a common language that all the parties use to communicate with each other.

How IPC Works In Android

All the applications in Android runs in its own process in a sandbox environment. Which means that each application is independent of others. This isolation helps improve the performance of the overall system and in achieving better security through different levels of permissions and access privileges.

Android has its own version of IDL called Android Interface Definition Language (AIDL), which has very much a Java-esque syntax. You basically start by defining an interface (or multiple based on your use case) and then implement the interface in your application and in the client application that wishes to communicate our app.

Understanding The Architecture

One important thing to understand is that IPC communication in Android is also client-server based. Which means that one application has to act as the server while others can interact with it using the interface it exposes.

Generally, that Server application is the one you are writing and which you wish to be controlled from outside sources. Following are the components and steps involved:

An AIDL interface: You define an interface in your server application containing the API that you want to expose to your clients.
Implementation of AIDL interface: Rebuilding your project will generate a java interface from your AIDL file, which you can then use to write a concrete implementation of it.
Expose the interface to the clients: Now that you have a concrete implementation of your AIDL interface, it is time to expose it to your clients by binding it with a Service. This Service can be invoked by external applications and then used a communication channel.
Exchanging data via IPC: On Android, one process cannot normally access the memory of another process. So to talk, they need to decompose their objects into primitives that the operating system can understand, and marshall the objects across that boundary for you. This means that you can only exchange primitive type data through IPC in the most basic from.
Writing the parcelable implementations: Since in most real-world applications you cannot live off just the primitives. Android also provides a mechanism to exchange your Objects through IPC with the use of Parcelables.

These are the 5 main steps required to implement the IPC capabilities in an application. However, admittedly they are not simple and bound to give you a lot of trouble. Let’s look at the implementation now.

Off To The Code

Let’s build a very basic application that let’s you perform addition. To demonstrate the use of data exchange with both primitives and objects, instead of returning a simple integer value for result, we will return a made-up Result object.

Start by creating a simple project with two modules, one serving as a Client while the other as the Server. You can find the link to the complete code at the end of post.

The AIDL Interface

Now that you have a basic setup, let’s first define our very simple AIDL interface in which we want to expose a single method called performAddition which takes 2 integer values and returns a made-up Result object.



// IAddition.aidl
package com.zuhaibahmad.aidldemo;

import com.zuhaibahmad.aidldemo.Result;
// Declare any non-default types here with import statements

interface IAddition {
    Result performAddition(int numOne, int numTwo);
}

Now as I mentioned above, since we are using a custom object, we need to define a simple AIDL implementation for it as well.



// Result.aidl
package com.zuhaibahmad.aidldemo;

parcelable Result;

Build the project and if no errors occur, then you should be able to find a java implementation of of your AIDL interface.

Once successful, make sure to copy both of your AIDL files to the client project as well.

Implementation Of The AIDL Interface

Next step is to provide concrete implementation of the AIDL interfaces. For the Result object, all you need is a parcelable POJO for it. However! You need to write it the old school java way.

I know you love Kotlin and must be thinking of using parcelize or at least take advantage of the simpler Kotlin code for data classes, but for some reason Kotlin based parcelables don’t work at the time of this writing.

So here’s your implementation for Result class in pure java style:

Make sure to copy this class into client’s source code as well since it is needed by client to interpret the Result AIDL interface.



package com.zuhaibahmad.aidldemo;

import android.os.Parcel;
import android.os.Parcelable;

public class Result implements Parcelable {
    private int numOne;
    private int numTwo;
    private int result;

    public Result() {}

    public Result(int numOne, int numTwo, int result) {
        this.numOne = numOne;
        this.numTwo = numTwo;
        this.result = result;
    }

    public int getNumOne() {
        return numOne;
    }

    public void setNumOne(int numOne) {
        this.numOne = numOne;
    }

    public int getNumTwo() {
        return numTwo;
    }

    public void setNumTwo(int numTwo) {
        this.numTwo = numTwo;
    }

    public int getResult() {
        return result;
    }

    public void setResult(int numResult) {
        this.result = numResult;
    }

    @Override
    public String toString() {
        return numOne + " + " + numTwo + " = " + result;
    }

    @Override
    public int describeContents() {
        return 0;
    }

    @Override
    public void writeToParcel(Parcel parcel, int i) {
        parcel.writeInt(numOne);
        parcel.writeInt(numTwo);
        parcel.writeInt(result);
    }

    public static final Parcelable.Creator<Result> CREATOR = new Parcelable.Creator<Result>(){

        @Override
        public Result createFromParcel(Parcel parcel) {
            Result res=new Result();
            res.numOne = parcel.readInt();
            res.numTwo = parcel.readInt();
            res.result = parcel.readInt();
            return res;
        }

        @Override
        public Result[] newArray(int size) {
            return new Result[size];
        }
    };
}

Anyways, let’s now provide the implementation for our IAddition AIDL interface in the server application:



package com.zuhaibahmad.aidldemo

import android.app.Service
import android.content.Intent
import android.os.IBinder
import android.util.Log

class AdditionService : Service() {

    override fun onBind(intent: Intent?): IBinder? {
        Log.e("server", "Binding Service")
        return object : IAddition.Stub() {
            override fun performAddition(numOne: Int, numTwo: Int): Result {
                return Result(numOne, numTwo, numOne + numTwo)
            }
        }
    }
}

While we are at it, let’s also register this service in our manifest file. With that our server application will be ready:



<service
    android:name=".AdditionService"
    android:enabled="true"
    android:exported="true" >
    <intent-filter>
        <action android:name="com.zuhaibahmad.aidldemo.AdditionService" />
    </intent-filter>
</service>

Hooking The Service To The Client

Last step is to bind the AdditionService in the server application to the client app and starting it remotely. I have a very basic activity with the following UI for client app:

Let’s implement the activity now:



package com.zuhaibahmad.aidldemo

import android.content.ComponentName
import android.content.Context
import android.content.Intent
import android.content.ServiceConnection
import android.os.Bundle
import android.os.IBinder
import android.support.v7.app.AppCompatActivity
import android.util.Log
import kotlinx.android.synthetic.main.activity_main.btEquals
import kotlinx.android.synthetic.main.activity_main.etNumOne
import kotlinx.android.synthetic.main.activity_main.etNumTwo
import kotlinx.android.synthetic.main.activity_main.tvResult

class MainActivity : AppCompatActivity(), ServiceConnection {

    private var isBound: Boolean = false
    private var iRemoteService: IAddition? = null

    // Called when the connection with the service is established
    override fun onServiceConnected(className: ComponentName, service: IBinder) {
        // Following the example above for an AIDL interface,
        // this gets an instance of the IRemoteInterface, which we can use to call on the service
        Log.e("client", "Service connected!")
        iRemoteService = IAddition.Stub.asInterface(service)
        isBound = true
    }

    // Called when the connection with the service disconnects unexpectedly
    override fun onServiceDisconnected(className: ComponentName) {
        Log.e("client", "Service disconnected!")
        iRemoteService = null
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        bindService()

        btEquals.setOnClickListener {
            onPerformAddition()
        }
    }

    private fun onPerformAddition() {
        val numOne = etNumOne.text.toString().toInt()
        val numTwo = etNumTwo.text.toString().toInt()

        tvResult.text = if (isBound) {
            val result = iRemoteService?.performAddition(numOne, numTwo)
            result.toString()
        } else {
            "Service not bound!"
        }
    }

    override fun onDestroy() {
        unbindService()
        super.onDestroy()
    }

    private fun bindService() {
        Log.e("client", "Attempting to bind service")
        val serviceIntent = Intent()
        serviceIntent.setClassName(PACKAGE_NAME, SERVICE_NAME)
        serviceIntent.action = ACTION_REMOTE_BIND
        bindService(serviceIntent, this, Context.BIND_AUTO_CREATE)
    }

    private fun unbindService() {
        if (isBound) {
            // Detach our existing connection.
            unbindService(this)
            isBound = false
        }
    }

    companion object {
        @JvmStatic
        val PACKAGE_NAME: String = "com.zuhaibahmad.aidldemo"

        @JvmStatic
        val SERVICE_NAME: String = "com.zuhaibahmad.aidldemo.AdditionService"

        @JvmStatic
        val ACTION_REMOTE_BIND = "$SERVICE_NAME-remote-bind"
    }
}

If all goes well, you should be able to compute your additions through the server app using AIDL interfaces.

Things To Remember

In the end, as you may have realized that this mechanism is not very robust and prone to error. So here are few tips from what I learnt working with Android’s IPC about the things that could easily go wrong and make you waste a lot of time.

Be very careful about the intent that you use to trigger the service, a minor typo will lead to service never starting.
On the same note, if you face a situation at the start where you are not getting the results, verify your service bindings first before diving into debugging. It could just be a faulty service binding and will save you a lot of effort.
Remember that ONLY primitive types are allowed, so always make sure that you are not accidentally accepting or returning a non-primitive object.
One of the biggest pain was with threading, I never realized that thread would affect IPC as well. Basically, calls made from the local process are executed in the same thread that is making the call. If this is your main UI thread, that thread continues to execute in the AIDL interface. So be very careful if you are using RxJava or any other async mechanism.
Remember, Kotlin classes does not work for parcelable implementations with AIDL. At least not at the time of this writing, and what’s worse is that it does not give you any error.

Helpful Resources

This awesome post by DevArea.
Detailed guide about IPC in Android on Official Android Resources.
Also, this Medium Article.

You can find complete source code for this post here

For suggestions and queries, just contact me.

Pythonic Imports in Kotlin

Zuhaib Ahmad — Sat, 01 Dec 2018 16:00:00 +0000

If you have been working with Kotlin for some time now, you might have encountered issues with name conflicts with Kotlin’s reserved keywords. A common example is with the popular mocking library Mockito, where the when method which is now used by Kotlin for its switch-like construct. So you end up doing something like this:

`when`(messenger.getMessage()).thenReturn("Hello World!")

Another scenario is when you want to name the imported class or extension function something more meaningful and readable. Which can be acheived to some extent with the use of a typealias. However, there’s a better solution available right into the Kotlin standard library.

Pythonic Way of Handling Imports

One the most flexible things I find in Python is the ability to name the imported classes almost anything you want, just like a variable. So you would simply import a class with a name that suits your style e.g.

import matplotlib.pyplot as plt

Now, you can use plt as a variable throughout your script.

Kotlin’s Import-As Alias

I wished to have this for Android development after I ran into some ambiguity issues with a recent project. Upon some searching, I was surprized to find that Kotlin had this feature all along. Just like Python, you can simply add imports with an as keyword.

Let’s look at how our Mockito problem is resolved now:

import org.mockito.Mockito.`when` as whenever

You can now use whenever in place of the less pleasant 'when' througout the class.

whenever(messenger.getMessage()).thenReturn("Hello World!")

So that was it. Another reason to love Kotlin (and Python as well)! ;)

For suggestions and queries, just contact me.

Parcelize: Boilerplate Free Parcelization With Kotlin

Zuhaib Ahmad — Mon, 20 Aug 2018 12:25:00 +0000

Serialization is the process of converting an object into a stream of bytes for ease of use for different I/O operations. Examples include writing to a database, memory or a file. In context of Android, the most common usecase is to pass an object around Activities and Fragments.

The main idea is to be able to preserve the state of the object in the most primitive way and be able recreated it when needed. The reverse process is called Deserialization.

Java Serialization & Android

The way our old boy Java used to handle serialization was very simple - You would only need to implement a marker interface i.e. java.io.Serializable and objects of that class would be automagically serializable.

public class MyObject implements Serializable {
    private int data;
}

This looks perfect, let’s leave it here and use this awesome interface everywhere.

But wait! This oversimplification comes at a big cost. The process involves reflection and creation of tonnes of helper objects behind the scenes. Which results in excessive garbage collection and poor performance.

In order to solve this problem, Android came with its own mechanism - Parcelable. Although it is more robust, it sacrifices the simplicity of Serialzable to acheive that. This results in more boilerplate code but which is completely reflection free.

They key to acheiving that, is that we have to explicitly define the serialization process using the writeToParcel method. Here’s what your ordinary parcelable class with a single field looks like:

public class MyObject implements Parcelable {
    private int data;

     public int describeContents() {
         return 0;
     }

     public void writeToParcel(Parcel out, int flags) {
         out.writeInt(data);
     }

     public static final Parcelable.Creator<MyObject> CREATOR
             = new Parcelable.Creator<MyObject>() {

         public MyObject createFromParcel(Parcel in) {
             return new MyObject(in);
         }

         public MyObject[] newArray(int size) {
             return new MyObject[size];
         }
     };

     private MyObject(Parcel in) {
         data = in.readInt();
     }
 }

We have been using this for years now, but if you have been using something like Parceler or if you are used to minimal Kotlin code now, then your reaction would probably be something like:

Kotlin To The Rescue (Again?!)

The release of Kotlin 1.1.4 added experimental support for generating Android Parcelable implementations using the @Parcelize annotation. It brings back the simplicity of Serializable but without reflection. It instead uses annotation processing to acheive that.

Setup

Since it is an experimental feature right now, you will need to enable the support for it by adding the following snippet to your gradle file:

androidExtensions {
    experimental = true
}

Also, add apply plugin: ‘kotlin-android-extensions’ to your gradle file if it isn’t there already.

Usage

The process of making any class parcelable involves adding only two things - a @Parcelize annotation and marking the class with Parcelable implementation.

Here’s what our MyObject class would look like:

@Parcelize
data class MyObject (val data: Int) : Parcelable

And that was it! When combined with data classes, we ended up with even simpler code than Java’s Serializable.

For suggestions and queries, just contact me.

Why Reactive Should Be Default for Mobile

Zuhaib Ahmad — Sat, 04 Aug 2018 01:10:00 +0000

In the early days of software, the way code was written was pretty straight forward. You would start at a single entry point in the program (typically a main function), execute the instructions sequentially and end the program gracefully. It was simple and easy to conceptualize.

Due to the linear control flow, it was not only easier to manage the state of the program but also to test and debug it because all the possible outcomes were predictable. The success of this imperative approach contributed to the way programming mindset established in the years to come. Today, most of us like to think in imperative fashion regardless of the platform or technology we work with.

Imperative Approach Fails With Modern Systems

“All modern systems are asynchronous.”

This may seem misleading at first but if you think about it, almost every system today requires us to code in non-blocking fashion. What I mean by non-blocking is that, you need to eliminate waiting periods from the system as much as you can. For example, it’s not ideal to display a loading indicator to the user while a network request is being processed. Although many still follow this pattern but from user experience standpoint, this is a recipe for disaster.

“Nobody likes to wait and they’ll leave if they are not served instantly.”

The situation worsens with mobile platforms where the OS itself is a source of a countless external changes. You could just flip your device and it’ll break your app unless you have added 3x more code than required just to handle a rotation scenario. What is surprising though, is that almost all of these popular mobile platforms were not designed to be reactive despite them being asynchronous by nature.

Reactive Programming

Hmmm… So what exactly is Reactive Programming? Let’s take some help from Wikipedia:

“In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change.”

Never mind! So, consider you have a program in which we have a Button and Label. They are defined as classes, like any other thing in an object oriented system. All this program does is updates the Label’s text to “Clicked!” when the Button is clicked. So we can say that the Button can somehow affect the text inside the Label, right?

So the case is simple, Button can be clicked and Label can be updated, both can be defined as a function in their respective classes. Now, here’s a question! If you were to code this interaction, where would you put the logic for updating the label when the button is clicked? Is it inside the Button itself or the Label?

Let’s say you go with the button, which btw is how we normally do it, then in this case you’ll need a reference of Label inside your button which you can update whenever the button is clicked. This essentially is Proactive way of programming. We basically delegated all the responsibility of state-management to the Button and let the Label stay passive i.e. don’t care about what is going on outside. Just follow the instructions when interacted.

The class Button would look something like this:

class Button (val label: Label) {
  public fun onClick() {
    label.setText("Clicked!")
  }
}

The alternative to this approach is Reactive programming. We basically just invert the roles so that the state owner has the ability to change itself, letting the Button call for change and Label react to it.

In this case, the Button class would be similar to this (notice how there’s absolutely no trace of label or any outside dependency):

class Button {

  interface ClickListener {
    fun doOnClick()
  }

  var listener: ClickListener? = null

  public fun onClick() {
    listener?.doOnClick()
  }

  public fun addOnClickListener(l: ClickListener) {
    listener = l
  }
}

While the Label will carry all the code for state its management along with list of all the registered clients.

class Label (val buttons: MutableList<Button>) {

  private var text = ""

  init {
    buttons.forEach {
      it.addOnClickListener { 
        this.setText("Clicked!") 
      }
    }
  }

  private fun setText(text: String) {
    this.text = text
  }
}

But why reactive? What changes with this approach?

First, the Inversion of Control i.e. Label class is now completely responsible of managing its own state and can easily hide away all the implementation details from outside world.

Second but related, is that now we have only one source of change. What I mean by that is how previously we had to make setText method public and all the clients could call it whenever they wanted, which means increased complexity. Now we have a hidden setText method that is called from only one place i.e. inside Button’s doOnClick callback and you can attach as many clients to it as you want using the addOnClickListener callback. This leads to Separation of Concern and simplified codebase.

Reactive Extensions

As described in the previous section, Callbacks are key enablers of reactive programming. However, this way of doing things can lead to a very uncomfortable situation known as Callback Hell. Reactive Extensions (abbreviated as RX) is a framework that helps address such issues.

The basic building blocks of the library are Observable , Observers and Operators. If you are familiar with the Observer Pattern, this is essentially the same pattern with some enhancements. You make things Observable and let some other things Observe these observables, during the process where Observable produces some data and the Observable receives it, you apply some Operators to mold the data in the form you like to have at the receiving end.

To learn more about the framework, checkout this talk by Kaushik Gopal or the guide by André Staltz.

Mobile & RX Movement

Now that we know about Reactive Programming and its helper framework. The question is how that solve problems associated with mobile platform that I mentioned at the start of this post?

Instead of giving long explanations of my own, I’d rather direct you to this awesome talk by Jake Wharton where he discusses these problems in context of Android and their solution with use of RxJava.

The crux is basically don’t hate yourself, go async and let the world handle their own problems instead of making your code rely on outside changes in proactive fashion.

Conclusion

State management is hard, especially on mobile platforms. While ideally SDKs should themself be reactively designed, we shouldn’t let that be a source of unreliability in our applications. Thanks to RX movement, we have reactive extensions port for almost every well known language. In context of Android specifically, the rise of Kotlin has provided a great opportunity to finally start writing our applications in functional and reactive manner.

Image Source - ReactiveX.

For suggestions and queries, just contact me.

Going Clean With MVP | A Guide To Model-View-Presenter On Android

Zuhaib Ahmad — Sun, 21 May 2017 03:10:00 +0000

Let’s face it! All of us wrote tons and tons of code inside MainActivity.java, many still do…

Writing code that “works” is fine and acceptable as you start working with a new language or framework. After all, the whole point is to get the work done, right? Not exactly!

We all start from the same place where every “hello world” marks an accomplishment. However, as you grow as an experienced developer, you start to realize that object-oriented programming is more than just writing the code that works.

Almost every project requires some level of testing and maintenance throughout its lifecycle. This makes it a strict requirement to write modular code that is easy to read, modify, test and maintain for future collaborators.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John Woods

Obviously, our "I love MainActivity" guy won’t find this an easy task. Why? Because when you write every single piece of code in the class where it is needed. You end up with a codebase which of course, gets the job done, but makes it almost impossible to test and maintain in the longer run.

Model-View-Presenter

MVP is an architectural pattern that attempts to decouple the business logic from the views by providing simpler activities with all the important work behind separate presentation layers. This results in a highly readable, maintainable and most importantly testable code.

Some might argue that MVP is not an architectural pattern per se as it is only responsible for managing the presentation of the data. However, we leave the debate here and move on to the “why?” aspect.

Need for MVP?

Android activities are cluttered with closely coupled components where everything is structured in a “throw the code on the wall” manner. This makes it an intrinsic problem for android code to be hard to test and extend. Anyone who went through the pain of learning android application testing can tell you that in the beginning it almost feels impossible to test android activities due to unmockable (is this even a word?) SDK components and lifecycle management complexities.

When you separate the business logic away from the activity in a separate presentation layer, it automatically makes it trivial to mock and test your code the way you would test any other java class.

The other difficulty apart from code testing is the maintenance of existing codebase. If you are reading this post and understand what I have said so far, I am assuming that you are at that point where you are familiar with the SOLID principles of object oriented design by Robert C. Martin a.k.a Uncle Bob. The last part of the five principles refers to the Dependency Inversion Principle (DIP) which encourages the programmers to write code in a way that it depends upon abstractions instead of the concrete implementations.

The way MVP is implemented nowadays (or at least they way I learned to) is through Contract interfaces that describes the responsibilities of Views and the Presenters, making the maintenance of code as simple as adding a new method to the interface and its implementation in the corresponding class. Note that this decoupling also allows us for interchangeable views for the same business logic.

Now let’s put a full-stop to the theoretical stuff and explore the implementation details of Model, View and Presenter by building a very basic hello world MVP app.

Before we go ahead, it’s important that you understand that there is no “ultimate” or “best” way of implementing MVP. Most people use their own implementations with some modifications, which is completely acceptable as long as the end goal is achieved. Which is to structure your code to decouple the implementation logic from the presentation layer. The way I’m doing it is only the way I like it, if you find another variation of it, don’t confuse and use the style that suits you.

The Model

Model is an interface responsible for managing data. Model’s responsibilities include using APIs, caching data, managing databases and so on. The model can also be an interface that communicates with other modules in charge of these responsibilities.

For the sake of simplicity, I’m not using any model classes in this example but I hope you got the idea.

The View

Do not confuse this with your XML views. Views in MVP are simply the components responsible for managing the user interface. This includes all the UI manipulation operations such as setting text to some TextView, toggling visibility of Views, displaying animations etc. Basically, everything that has to do with the User Interface, goes into this place.

Keep your views as dumb as possible.

The idea is to keep your Presenters unaware of “how” to present data to the user. All they have is a View instance that takes this data as input and performs the presentation tasks. So if you were to display an error to the user in case he forgets to fill a field in the form, all your presenter has to do is call the view.displayError(errorMessage) method on the View instance.

Now realize that the Presenter doesn’t know what happens next, whether the error is displayed as a Toast, or as a Dialog or a Snackbar or what color is the message etc. The View on the other hand does not know anything about the data it is provided and its origins, it is only interested in accepting the supplied data and manipulate the UI accordingly. This makes it very easy to mock Views while testing your business logic so you can focus on the stuff that is important.

The way I like to define my Views is through a View interface which resides inside the Contract Interface for that particular activity.

interface View extends BaseView<Presenter> {

    void displayMessage(String text);

    void displayResult(int result);
}

Now all I have to do is create a new class and make it implement this interface and we have a candidate that can serve as View for our activity. I guess you might have guessed that we can provide multiple implementations of View as well for different use cases.

public class MainActivity extends AppCompatActivity implements ContractMain.View{

    @BindView(R.id.toolbar)
    Toolbar mToolbar;
    @BindView(R.id.container)
    CoordinatorLayout mContainer;
    @BindView(R.id.numberOneEditText)
    EditText mNumberOneEditText;
    @BindView(R.id.numberTwoEditText)
    EditText mNumberTwoEditText;
    @BindView(R.id.resultTextView)
    TextView mResultTextView;

    private ContractMain.Presenter mPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this);
        setSupportActionBar(mToolbar);

        mPresenter = new MainPresenter(this, this);
        mPresenter.start();
    }

    @Override
    public void displayMessage(String text) {
        Snackbar.make(mContainer, text, Snackbar.LENGTH_LONG).show();
    }

    @Override
    public void setPresenter(ContractMain.Presenter presenter) {
        mPresenter = presenter;
    }

    @Override
    public ContractMain.Presenter getPresenter() {
        return mPresenter;
    }

    @OnClick(R.id.addButton)
    public void onAddButtonClicked() {
        String numberOne = mNumberOneEditText.getText().toString();
        String numberTwo = mNumberTwoEditText.getText().toString();

        mPresenter.performAddition(numberOne, numberTwo);
    }

    @Override
    public void displayResult(int result) {
        mResultTextView.setText(String.valueOf(result));
    }
}

The Presenter

Think of the presenters as the Boss here. Similar to how you used to manage everything from your activity in the I Love MainActivity era, Presenters now handles all the management tasks and keeps your activities/fragments less busy. So instead of throwing your DatabaseHandler, ApiHandler, PeanutButterMaker and instances of whatnot in the activity class and make it look like a huge pile of crappy code, you just provide it with the Presenter instance and place all the other important stuff inside your Presenter.

Now just like the Views, presenters are also defined through a child interface inside the contract interface of the activity that owns it.

interface Presenter extends BasePresenter {

    void performAddition(String numberOne, String numberTwo);

    boolean isEmptyInput(String numOne, String numTwo);
}

Now all I need to do is to make my activity/fragment implement this interface and provide implementations for the defined operations.

class MainPresenter implements ContractMain.Presenter {

    private final ContractMain.View mView;
    private final Context mContext;

    MainPresenter(ContractMain.View view, Context context) {
        mView = view;
        mContext = context;
    }

    @Override
    public void start() {
        // Do your initialization work here
    }

    @Override
    public void performAddition(String numberOne, String numberTwo) {

        if (isEmptyInput(numberOne, numberTwo)) {
            // Display error message if any of the inputs is empty
            mView.displayMessage(mContext.getString(R.string.error_empty_input));
        } else {
            // Compute and pass the result to view for display
            final int firstNumber = Integer.parseInt(numberOne);
            final int secondNumber = Integer.parseInt(numberTwo);

            final int result = firstNumber + secondNumber;
            mView.displayResult(result);
        }
    }

    @Override
    public boolean isEmptyInput(String numOne, String numTwo) {
        return numOne == null || numOne.length() == 0 ||
            numTwo == null || numTwo.length() == 0;
    }
}

Outcome

So you might be wondering what did we achieve apart from dividing our activity into 3 pieces?

The first benefit of using this approach is that we achieved a more modular and scalable architecture. If you were to add subtract functionality to this activity, all you would do is define a new method void performSubtraction(String numberOne, String numberTwo) in the Presenter interface and provide its implementation. Your contracts are the documentation for your code itself.

The second and most important change is that our activity is now fully testable. You could simply mock the View and test all the application logic using your Presenter. Below are a couple of tests for the activity we implemented earlier. I’m using Mockito for mocking dependencies.

@RunWith(MockitoJUnitRunner.class)
public class MainTest {

    private static final String EMPTY_INPUT_ERROR_MESSAGE
        = "Please Provide Both Numbers!";

    @Mock
    private ContractMain.View mView;
    @Mock
    private Context mContext;

    private ContractMain.Presenter mPresenter;

    @Before
    public void setUp() throws Exception {
        mPresenter = new MainPresenter(mView, mContext);
    }

    @Test
    public void performAddition_shouldReturnResult() {
        final String numberOne = String.valueOf(2);
        final String numberTwo = String.valueOf(3);

        mPresenter.performAddition(numberOne, numberTwo);

        verify(mView).displayResult(5);
    }

    @Test
    public void performAddition_shouldDisplayErrorMessage() {
        final String numberOne = String.valueOf(2);
        final String numberTwo = null;
        // Mock error string because our mock context
        // wouldn't be able to return it
        when(mContext.getString(R.string.error_empty_input))
            .thenReturn(EMPTY_INPUT_ERROR_MESSAGE);

        mPresenter.performAddition(numberOne, numberTwo);

        verify(mView).displayMessage(EMPTY_INPUT_ERROR_MESSAGE);
    }
}

Conclusion

At this point, it may make sense to your or it won’t, but sooner or later, you’ll realize that you need some level of modularization in your code if it requires proper testing and be able to remain maintainable for long-term. If not MVP, you might go with one of the several other architectural patterns that are available. For me, MVP makes more sense than any other in the context of Android.

Image rights belong to macoscope.

Source Code is available at GitHub repository.

For suggestions and queries, just contact me.