Design patterns for Android development. Part 1 - Introduction
Writing programs for smartphones is my hobby. It all started with the fact that I bought my first smartphone Nokia E51 on Symbian and I really liked that its functionality could be expanded through the installation of additional programs.
But once I did not find the necessary program and decided to write it myself. So began my passion for programs for smartphones.
After the head of Nokia said that the days of Symbian are numbered, I decided to explore the Android platform.
For better learning, I decided to write a useful program, at least for myself. But to write it is not childish, when pieces of primitive code are copied from the documentation, but on an adult with the development of architecture, and the use of modern programming technologies TDD, MVP and IoC.
')
My first Android app is T-Alarm. You can find it on the Android Market by name. At the moment, there is no design in the program and it looks a bit awkward, but soon the design will appear.
This is just an alarm program, but with one function that is not found in other programs.
I usually get up at 6:45 am, but a couple of times a week I have to get up at another time, for example, for a morning run. To do this, you need to change the time in the alarm clock for tomorrow, and also do not forget to return the schedule to the original one later. All other alarms on Android do not allow you to quickly change the time for tomorrow, for this you need to go a long way through the settings, and neither of them returns the time to its original state after triggered by the changed one.
Therefore, I decided that the main feature of my program will be the possibility of a one-time change of the next trigger time, as well as the general principle that to make changes to the schedule, you should spend as little time as possible wandering around the settings.
Moreover, the alarm clock is an excellent task to learn more about the Andorid platform. Here are affected such parts as:
- User interface. It is necessary to make several windows for setting.
- play music files. You can explore the capabilities of the built-in media player.
- Save the schedule in the database. Now I know how to use SQLIte database on Android.
- The implementation of services to work out the alarm. At the onset of the hour X, it is necessary to program the next moment of operation, taking into account several dozes (snooze), and play a wake-up call. A great reason to figure out what services are in Android and which one should be used.
- Receiving various signals from the OS. The alarm service should be triggered by the system alarm and when the smartphone is loaded.
With this article I open a number of articles where I want to share my development experience. And I want to focus on using MVP and TDD when developing my application. On the Internet, I found all this piece by piece and was able to put it all together. This allowed me to make an application in which all the basic algorithms were tested using UnitTest, as well as I provided several other goodies that would be of interest to Andorid developers.
From the very beginning, I wanted to figure out how to use modern approaches and design patterns when developing applications for Android, and therefore it took me a lot of time to study various frameworks. It seems that the Android SDK already has JUnit built in for organizing tests and there are many articles on the Internet on how to use it, but how it comes to a real project is the pitfalls immediately appear. I will talk about how to overcome them in this series of articles.
So, I decided to use TDD in order to be sure that all the basic algorithms of my application have been tested. So I settled on the MVP pattern when designing the user interface.
My sources are divided into two projects - the main project with sources and a test project with tests.
The source project consists of several packages. As a rule, one package is one architectural link, that is, one form or service.
Each link consists of a presenter (Presenter), a view (View) and, at times, of auxiliary classes, as a rule, for organizing several streams. I want to note that the presentation is not always the user interface, sometimes these are classes for working with system services, but in order to be able to simulate these system services, I carried them out to View, which has an interface, and this interface is easy to simulate in tests.
The project with tests is also divided into packages. Each package contains several tests for the corresponding application link.
Since my application is small, there are no layers in it, but there are only a few links:
1. Main window
2. Edit alarm window
3. Ringtone selection window
4. Window when calling
5. The data model, in my case, is a list of alarms, and a repository for saving the model in the database.
6. Service for processing system messages: the onset of hour X and the loading of a smartphone.
All windows and service work only with the model, which is obtained from the repository. This results in an architecture consisting of loosely coupled links. Each link can be tested separately from others by simulating a model.
Also, the model itself contains the complex logic of calculating the next alarm clock, but the model is also easily tested, since it does not depend on other links.
In this architecture, only views remain untested. But the code in them is usually extremely simple. This is just a mapping of method parameters to form controls. As a rule, this code is tested using the “gaze” method. And errors are easily detected when you see that some kind of control is not filled in the form.
In the following articles, I will focus more on the features of the implementation of individual links, as well as tell you what tools that facilitate the life of the developer, I also used.
- Introduction
- MVP and Unit tests. Jedi Way
- User Interface, Testing, AndroidMock
- Saving data. Domain Model, Repository, Singleton and BDD
- Server side implementation, RoboGuice, testing
- Small tasks, settings, logging, ProGuard
But once I did not find the necessary program and decided to write it myself. So began my passion for programs for smartphones.
After the head of Nokia said that the days of Symbian are numbered, I decided to explore the Android platform.
For better learning, I decided to write a useful program, at least for myself. But to write it is not childish, when pieces of primitive code are copied from the documentation, but on an adult with the development of architecture, and the use of modern programming technologies TDD, MVP and IoC.
')
Formulation of the problem
My first Android app is T-Alarm. You can find it on the Android Market by name. At the moment, there is no design in the program and it looks a bit awkward, but soon the design will appear.
This is just an alarm program, but with one function that is not found in other programs.
I usually get up at 6:45 am, but a couple of times a week I have to get up at another time, for example, for a morning run. To do this, you need to change the time in the alarm clock for tomorrow, and also do not forget to return the schedule to the original one later. All other alarms on Android do not allow you to quickly change the time for tomorrow, for this you need to go a long way through the settings, and neither of them returns the time to its original state after triggered by the changed one.
Therefore, I decided that the main feature of my program will be the possibility of a one-time change of the next trigger time, as well as the general principle that to make changes to the schedule, you should spend as little time as possible wandering around the settings.
Moreover, the alarm clock is an excellent task to learn more about the Andorid platform. Here are affected such parts as:
- User interface. It is necessary to make several windows for setting.
- play music files. You can explore the capabilities of the built-in media player.
- Save the schedule in the database. Now I know how to use SQLIte database on Android.
- The implementation of services to work out the alarm. At the onset of the hour X, it is necessary to program the next moment of operation, taking into account several dozes (snooze), and play a wake-up call. A great reason to figure out what services are in Android and which one should be used.
- Receiving various signals from the OS. The alarm service should be triggered by the system alarm and when the smartphone is loaded.
With this article I open a number of articles where I want to share my development experience. And I want to focus on using MVP and TDD when developing my application. On the Internet, I found all this piece by piece and was able to put it all together. This allowed me to make an application in which all the basic algorithms were tested using UnitTest, as well as I provided several other goodies that would be of interest to Andorid developers.
General project architecture and applications
From the very beginning, I wanted to figure out how to use modern approaches and design patterns when developing applications for Android, and therefore it took me a lot of time to study various frameworks. It seems that the Android SDK already has JUnit built in for organizing tests and there are many articles on the Internet on how to use it, but how it comes to a real project is the pitfalls immediately appear. I will talk about how to overcome them in this series of articles.
So, I decided to use TDD in order to be sure that all the basic algorithms of my application have been tested. So I settled on the MVP pattern when designing the user interface.
Project organization
My sources are divided into two projects - the main project with sources and a test project with tests.
The source project consists of several packages. As a rule, one package is one architectural link, that is, one form or service.
Each link consists of a presenter (Presenter), a view (View) and, at times, of auxiliary classes, as a rule, for organizing several streams. I want to note that the presentation is not always the user interface, sometimes these are classes for working with system services, but in order to be able to simulate these system services, I carried them out to View, which has an interface, and this interface is easy to simulate in tests.
The project with tests is also divided into packages. Each package contains several tests for the corresponding application link.
Application architecture
Since my application is small, there are no layers in it, but there are only a few links:
1. Main window
2. Edit alarm window
3. Ringtone selection window
4. Window when calling
5. The data model, in my case, is a list of alarms, and a repository for saving the model in the database.
6. Service for processing system messages: the onset of hour X and the loading of a smartphone.
All windows and service work only with the model, which is obtained from the repository. This results in an architecture consisting of loosely coupled links. Each link can be tested separately from others by simulating a model.
Also, the model itself contains the complex logic of calculating the next alarm clock, but the model is also easily tested, since it does not depend on other links.
In this architecture, only views remain untested. But the code in them is usually extremely simple. This is just a mapping of method parameters to form controls. As a rule, this code is tested using the “gaze” method. And errors are easily detected when you see that some kind of control is not filled in the form.
In the following articles, I will focus more on the features of the implementation of individual links, as well as tell you what tools that facilitate the life of the developer, I also used.
Read in other articles.
- Introduction
- MVP and Unit tests. Jedi Way
- User Interface, Testing, AndroidMock
- Saving data. Domain Model, Repository, Singleton and BDD
- Server side implementation, RoboGuice, testing
- Small tasks, settings, logging, ProGuard
Source: https://habr.com/ru/post/131369/
All Articles