This version of the app is called todo-mvp, and provides a basis for the other samples in this project. The purpose of the sample is:
- Provide a basic model-view-presenter (MVP) architecture without using any architectural framework.
- Serve as a reference point for comparing and contrasting other samples in this project.
pay attention: It uses the following naming convention across all repository branches, to differentiate between the Project View class and the MVP View:
- “AndroidView” refers to the android.view.View class.
- In MVP the view that receives commands from the presenter is called a “view”.
what you need
Before exploring this sample, you may find it useful to become familiar with the following topics:
The todo-mvp sample uses the following dependencies:
- Common Android Support Libraries – Packages in the com.android.support.* namespace provide backward compatibility and other features.
- Android Testing Support Library – A framework used to support UI tests using both Espresso and AndroidJUnitRunner.
- Mockito – A mocking framework used to implement unit tests.
- Guava – A set of core libraries for Java by Google, commonly used in Android apps.
All versions of the Android Blueprint app include the same general features in a simple to-do type app. The app has four UI screens:
- Tasks – Used to manage the list of tasks.
- Task Description – Used to read or delete a task.
- AddEditTask – Used to create or edit tasks.
- Statistics – Displays statistics related to tasks.
In this version of the app, as well as other versions based on it, each screen is implemented using the following classes and interfaces:
- A contract class that defines the relationship between the view and the presenter.
- An Activity that creates Fragments and Presenters.
- A fragment that implements the visual interface.
- A Presenter that implements the Presenter interface in the corresponding contract.
A Presenter typically hosts the business logic associated with a particular feature, and the associated View handles the Android UI work. There is almost no logic in the scene; It converts the presenter’s commands into UI actions, and listens for user actions, which are then passed on to the presenter.
implement the app
Each version of the app implements similar features, using a different approach to display and contrast different types of architectural designs. For example, this version takes the following approach to solving common implementation questions:
- This sampler uses product flavor to replace modules at compile time, providing mock data for both manual and automated testing.
- This version uses callbacks to handle asynchronous tasks.
- The data is stored locally in a SQLite database using Room.
Also note in the following illustration that this version of the app uses fragments, and this is for two reasons:
- The use of both activities and fragments allows for better separation of concerns which makes this implementation of MVP complete. In this version of the app, the Activity is the composite controller that creates and links the views and presenters.
- Fragments are used to support tablet layouts or UI screens with multiple views.
This version of the app includes multiple unit tests covering renderers, repositories, and data sources. The sample also includes UI tests, which rely on mock data, and are facilitated by dependency injection to provide mock modules. For more information about using Dependency Injection to facilitate testing, see Leveraging Product Flavors in Android Studio for Hermetic Testing.
maintaining the app
This sample includes classes and interfaces, such as renderers and contracts, that increase the number of lines of code compared to more traditional projects that do not use a particular architecture.
The table below summarizes the amount of code used to implement this version of the app. You can use this as a basis for comparison with the similar tables provided for each of the other samples in this project.
|Language: Hindi||number of files||blank lines||comment lines||lines of code|