In the last article I described in detail how I designed and implemented my first Android app. In this article I’ll show the new app features and the core implementation.

First of all, I passed through play store comments and got a lot of feedback on the first version, and I’ll implement them in this version.

In this new version, I changed a little how the task are grouped. In the previous version, the user must create a task list before create new tasks. Now you can create single tasks, without need to nested it in a list, but the list features will be available.

New features

This new version will have some new features. I describe them bellow:

Tasks

In the previous versions, the concept of tasks were a named list contained other tasks nested on it. In this new versions, the task is considered an atomic entity, that can be included in a list or not.

Task Lists

This features is the same of the earlier version but now it's optional. On tasks list, the user can split a single task in another tasks.

Check lists

In the newer version, a task can contain a simple list of items than can be marked/unmarked as completed.

Archive tasks

if the user wants, he/she can archive a task to make it unshown on the screen, but without deleting the item.

Core implementation

After showing the app feature, let's explore the implementation. After analyzing the features, I chose clean architecture to implement the new version of the app. In clean architecture, the core features are placed in the most inner layer, and it must be platform independent. If correctly implemented, they can be used in any platform without any change.

The first step were creating a new Android Project, then, I added a new module called CoreApplication. In this module, I created the packages data and domain. The data layer is self-explained. It contains the entities and the classes definitions to manager the data. The domain package contain the Use Cases, here all rules will be implemented.

Data layer

In data layer I created the entities and repositories. The entities package contains the classes Task and TaskList. Task is a single task with all it's properties, and TaskList represents an Item with tasks nested.

Task:

data class Task(
    val id:String,
    var name:String,
    var completed: Boolean,
    var createdDate:Date,
    var notificationDate: Date?,
    var description:String?,
    var archived: Boolean = false,
    var checkList: List<TaskChecklist>?
)


fun Task.hasToNotify():Boolean{
    return notificationDate != null
}

Task List:

data class TaskList(
    val id:String,
    var name: String,
    var tasks: List<Task>?
)

In the other packaged, we have the repositories. They are interfaces with the definition of the classes that can manage task storage.

interface TaskRepository {

    /**
     * Get a list of tasks matching the following arguments.
     * If no arguments are passed, it will returns all task,
     * (completed or not) that wasn't archived
     * @author Eduardo
     * @param includeCompleted: if true all tasks will be listened. If false,
     * only retrieved uncompleted tasks
     * @param includeArchived: if true, archivedTasks will be included,otherwise not
     * @param betweenDates: pair of dates, indicating to returns the tasks created between
     * the period passed
     */
    fun listTasks(
        includeCompleted:Boolean = true,
        includeArchived:Boolean = false,
        betweenDates:Pair<Date,Date>? = null): List<Task>

    /**
     * Retrieve single task
     * @author Eduardo
     * @param id: the task id
     * @return the task found or null
     */
    fun getTask(id:String): Task?

    /**
     * @author Eduardo
     * stores a new Task
     * @param task Task do create
     * @return true if task was successfully created
     */
    fun createNewTask(task: Task): Boolean

    /**
     * @author Eduardo
     * edit the Task passed as parameter
     * @param task Task do create
     * @return true if task was successfully edited
     */
    fun editTask(task: Task): Boolean

    /**
     * @author Eduardo
     * delete the Task passed as parameter
     * @param task Task do delete
     * @return true if task was successfully deleted
     */
    fun deleteTask(task: Task): Boolean
}

These methods are pretty easy to understand. Probably the must complex is listTask because it's bunch of arguments.

Domain layer

In this layer, all the core feature are implemented. According clean architecture the use cases must have just one rule implementation, unlikely the previous versions that contains a single service class with a lot rules on it. The approach of clean architecture gives us the possibility of add new features, without have to know or editing the previous rules. Let's see some in detail bellow.

The first class to see is the simplest, List Task Use Case. This just receive some arguments and search in repository for the tasks matching the criteria. All search parameters is marked with nullable and with default values.

class ListTasksUseCase(private val repository: TaskRepository) {
    /**
     * List all tasks
     * @param completed: if has to include the completed tasks
     * @param archived: if include archived tasks
     * @param initialDate: first date of range to search items
     * @param finalDate: last date of range to search items
     * @return the list of tasks matching parameter
     */
    fun listAllTasks(
        completed: Boolean = true,
        archived: Boolean = false,
        initialDate: Date? = null,
        finalDate: Date? = null
    ): List<Task> {
        val dateRange =
            if (initialDate != null && finalDate != null)
                Pair(initialDate, finalDate)
            else
                null
        return repository.listTasks(completed, archived, dateRange)
    }
}

The CreateTaskUseCase is where a new tasks are created. Different from the following use cases, this specific don't receive a task object. Instead it receive fewer arguments, to avoid other layers and classes to deal with specific rules or insert inconsistent data, for example create a task with invalid creation date, or duplicated ids.

class CreateTaskUseCase(
    private val repository: TaskRepository,
    private val notificationService: NotificationService) {

    /**
     * Create a new task
     * @param name: the task names
     * @param description: the task descriptions
     * @param notificationDate: when this tasks should be notified to user
     * @param checkListItems: optional list of items to complete this task
     * @return true if task was successfully created
     */
    fun createNewTask(
        name: String,
        description: String?,
        notificationDate: Date?,
        checkListItems: List<String> = emptyList()):Boolean {

        val task = Task(
            id = newId(),
            name = name,
            completed = false,
            createdDate = Date(),
            notificationDate = notificationDate,
            description = description,
            archived = false,
            checkList = checkListItems.map { TaskChecklist(newId(), it, false) }
        )
        return repository.createNewTask(task).also { successfullySaved ->
            if(task.hasToNotify() && successfullySaved) {
                notificationService.scheduleNotification(task)
            }
        }
    }
}

The final step is scheduling notification to this task, if the user marked the notification option. The Edit and Delete are very similar, the just to their operations on repository and then deal with notification

class DeleteTaskUseCase(
    private val repository: TaskRepository,
    private val notificationService: NotificationService) {

    fun deleteTask(task: Task): Boolean{
        return repository.deleteTask(task).also { successfullyDeleted ->
            if(task.hasToNotify() && successfullyDeleted){
                notificationService.cancelNotification(task)
            }
        }
    }
}

class EditTaskUseCase (
    private val repository: TaskRepository,
    private val notificationService: NotificationService) {

    fun editTask(task: Task): Boolean{
        return repository.editTask(task).also {
            if(task.hasToNotify()){
                notificationService.scheduleNotification(task)
            }else{
                notificationService.cancelNotification(task)
            }
        }
    }
}

To avoid been too long, the last classes I wanna show is CompleteTaskUseCase. As shown bellow, this feature just edit the task, setting the property "completed" to true.

class CompleteTaskUseCase(
    private val repository: TaskRepository,
    private val notificationService: NotificationService) {

    fun completeTask(task: Task): Boolean{
        val taskToComplete = repository.getTask(task.id)
        if(taskToComplete != null) {
            taskToComplete.completed = true
            return repository.editTask(taskToComplete).also {
                notificationService.cancelNotification(task)
            }
        }else{
            return false
        }
    }
}

But why not just setting this property explicit and use "EditTaskUseCase" to update the task, it would works equally. This is true, but it breaks the concept of abstraction. We don't want that the presentation layer cares about the features implementation, for example.

I'm finish for now to avoid become so extensive, in the next article I'll show the implementation of the Repositories. You can check out all the source code on my github.

See you soon.

Until the year of 2015 I was working as a Java developer, but I was desiring to try new things. I always been so curious in terms of trying and building new technologies, and I decided to learn Android development, just because I had and Android phone and I wanted to build some app to integrate with my Arduino projects. In that time, the Android developer roadmap was kind of: learn Java, then learn the basics of Android SDK( Activity and it’s lifecycle, Fragments, resources, Broadcast receivers and etc), then build your apps and upload them to Google Play store (if you want). Since I currently know how to programming with Java, the learning curve was much easier.

After a lot of tutorials, videos, sample apps and so one, I was finally prepared to start my new journey, and for that I needed some portfolio to show my abilities to the world. I decided to build my first app and submit it to the store. I needed something that wasn’t too simple as a tutorial or exercise, nor so complex for a single beginner developer. After some brainstorm on my sketch book, I finally reached the first prototype, and something I realized that I’m not as creative as I thought. The chosen app was a… to-do task manager. This is very “uncreative” idea, but I decided to build this because it’s small enough to don’t take a lot of time to finish, and because there is no need for backend. But, no more talk, let’s see the app and the code.

The app features

The concept of the app was plenty easy. First you create your tasks, for example, “Cleaning the house” and then you split this task in another small tasks, like “Cleaning the kitchen”, “Organize the room” and how much you needed. After complete one task, you should mark it as completed, and the app shows to you how many tasks are reaming. I model the app in this way, instead of just simple list of random tasks, because this is the way I used to organize myself. Some other features was add date and time to some task, notify the user in some task in specific time, and backup your items to local storage.

The entire app were designed following the material design recommendations like toolbar, navigations menu, floating button and floating action button. This design was very beautiful in the past, but today it’s too simple and your app will look to basic. Bellow you can check some screenshots.

In addition, you have the option to add a reminder to your subtasks, and been notified some time before. On the settings screen, you can configure the option to manually backup your tasks and configure the order that task are showed.

Building the app

Since this app is to outdated, it’s no longer available on Google play store, because it’s not following the latests store requirements. The only option is getting this from the github.

After cloning from repository and trying to open in Android Studio, I got a several errors on Logcat. The whole projects was so outdated that I had to remake almost all configurations. The most important changes was update the gradle version from 2.10 to 8.6, the compile sdk version from 22 to 34 and the minimum sdk version from 16 to 25, and finally the java version from 7 to 17.

Some other adjustments are required, as adding android:exported=”true” tag in each activity and broadcast receiver on manifest file.

<activity
  android:exported="true"
  android:name=".view.activity.ListTasksActivity"
  android:theme="@style/AppTheme">
  <intent-filter>
      <action android:name="android.intent.action.MAIN" />
      <category android:name="android.intent.category.LAUNCHER" />
  </intent-filter>
</activity>

...

<receiver android:exported="true" android:name=".legacy.receives.StartupReceive">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />

        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</receiver>

And add PendingIntent.FLAG_IMMUTABLE to all PendingIntents

private boolean alarmUp(){
  return(PendingIntent.getBroadcast(context, 0,
          notificationIntent,
         PendingIntent.FLAG_NO_CREATE | PendingIntent.FLAG_IMMUTABLE) != null);
}

As expected, all dependencies are deprecated.

After 3 hours of adjustments, the app finally builds. The app is not working entirely, but the core features are woking well and I could navigate in it’s implementation.

The app overview

The app were built in the MVC architecture, witch was very common in 2015 but today we have a lot of better options. The main project structure was divided into the layers core, entities, persistence and views. Some other packages is wrongly placed in same hierarch.

Core layer

The core app contains the packages, backup, entities, utils and the feature classes.

The backups package contain just some Gson annotations, and it’s name was badly chosen. The entities and utils packages are self explained. The main classes are that in the root package. Lets see in details.

The first is the Backup class. This class contains methods to backup and restore Tasks. The implementation was basically, serialize all data in json format and save to the storage. After looking at the class I found the first big mistake: store reference to Context. It’s highly recommended that you don’t to this, because you can have several memory leaks.

public class Backup {
    private Context context;
    public Backup(Context context){
        this.context =context;
    }
//...

The Constants class just contains constants and the File class just methods to read and write files. The Settings class is simple, this just read/write some user preferences in SharedPreferences class, but I committed another newbie mistake, use hard coded strings.

    private Context context;
    public static Settings getInstance(Context context){
        return  new Settings(context);
    }

    public Settings(Context context){
        this.context = context;
    }
    public boolean capitalizeFirst(){
        return getBoolPref("preference_capitalize_first",false);
    }

    public boolean vibrate(){
        return getBoolPref("preference_vibrate",true);
    }
    public boolean notifyAllTasks(){
        return getBoolPref("preference_notify_all",true);
    }
    public boolean manualBackup(){
        return getBoolPref("preference_enable_manual_backup",false);
    }

And then, the real app core, the Tasks class. This class contains all the main features of the application. And the main class contains the worse mistake: directly instantiates it’s dependencies. This is terrible because, the main features aren’t testable. Not only that, it’s also highly coupled with the storage layer.

package com.apps.esampaio.legacy;

import android.content.Context;

import com.apps.esampaio.legacy.entities.Subtask;
import com.apps.esampaio.legacy.entities.Task;
import com.apps.esampaio.legacy.persistence.DAO.Impl.SubtaskDAOImpl;
import com.apps.esampaio.legacy.persistence.DAO.Impl.TaskDAOImpl;
import com.apps.esampaio.legacy.persistence.DAO.SubtaskDAO;
import com.apps.esampaio.legacy.persistence.DAO.TaskDAO;

import java.util.List;

/**
 * Created by eduardo on 28/06/2016.
 */

public class Tasks {
    private static TaskDAO taskDAO = null;
    private static SubtaskDAO subtaskDAO = null;

    public Tasks(Context context){
        if(taskDAO == null)
            taskDAO= new TaskDAOImpl(context);
        if(subtaskDAO == null)
            subtaskDAO = new SubtaskDAOImpl(context);

    }

    public List<Task> getTasks(){
        List<Task> tasks = taskDAO.getTasks();
        for (Task task: tasks) {
            task.setSubtasks(subtaskDAO.getSubTasks(task.getId()));
        }
        return tasks;
    }

    public void addTask(Task task){
        taskDAO.addTask(task);
        for (Subtask subtask: task.getSubtasks()) {
            subtaskDAO.addSubtask(subtask);
        }
    }


    public void saveOrUpdateTask(Task item) {
        if(item.getId() == -1){
            addTask(item);
        }else{
            updateTask(item);
        }
    }
    public void updateTask(Task item) {
        taskDAO.updateTask(item);
        for (Subtask subtask: item.getSubtasks()) {
            subtaskDAO.addOrUpdate(subtask);
        }
    }

    public void delete(Task item) {
        taskDAO.deleteTask(item);
        for (Subtask subtask: item.getSubtasks()) {
            deleteSubtask(subtask);
        }
    }

    public void deleteSubtask(Subtask subtask){
        subtaskDAO.deleteSubtask(subtask);
    }

    public Task getTask(int id) {
        Task task = taskDAO.getTask(id);
        task.setSubtasks(subtaskDAO.getSubTasks(task.getId()));
        return task;
    }
}

Persistence layer

There isn’t much to talk about the persistence layer. It was modeled and built thinking about the Sqlite, so again, it’s very couple to this api.

Today, we have a lot of better solutions for storage, and even better apis to manipulate the Android’s Sqlite. Probably, if I had researched a bit more, I could found better options, and avoided some painful tasks, like write SQL instructions on my code.

public class SubtaskEntity implements Entity {

    private static final String createTableSql =
            " create table subtask (" +
                    " id integer not null primary key autoincrement," +
                    " task_id integer not null ," +
                    " name varchar(100) not null," +
                    " task_date date," +
                    " task_time date," +
                    " description varchar(1000)," +
                    " completed int, " +
                    " FOREIGN KEY(task_id) REFERENCES task(id)" +
                    ");";
//...

The view layer

Finally the view layer, contains all Android related stuffs, like Activities, Fragments, Dialogs, Notifications, Broadcast receivers, adapters and so more. There is no need to go deeply in this package, because it contains so many classes and this is not the goal of this article.

You can download the legacy version on my Github (this is now buildable).

The newer version

Once this project is so legacy, it will be a madness try to refactor this. Instead, I will create a new project from scratch, with the same package id, using modern technologies and techniques and replace the old version on Play Store.

In first moments, this will be the main changes (but can changes during the development):

• From MVC to MVVM or Clean Architecture
• From Java to Kotlin
• From Multi Activity app to Single Activity App
• From XML View to Jetpack Compose
• From Sqlite DAO to persistence libray
• From No tests to at least Unit Test
• From Material Desgin 1 to Material Design 3 or Custom Layout
• From Single Theme to Light/Dark Theme

In the next article, I’ll show the skeleton of the new version, with the new architecture, the key features and the reason why I chosen it. Se you soon.

checkout the part 2: https://medium.com/@eduardosoares_88255/rebuilding-my-first-android-app-part-2-05b1b0f6fed2