代码拉取完成，页面将自动刷新
Showcase is a sample project that presents a modern, 2020 approach to Android application development with up to date tech-stack.
The goal of the project is to demonstrate best practices by using up to date tech-stack and presenting mod ern Android application Architecture that is modular, scalable, maintainable, and testable. This application may look quite simple, but it has all of these small details that will set the rock-solid foundation for the larger app suitable for bigger teams and long application lifecycle.
This project is being maintained to match current industry standards. Please check CONTRIBUTING page if you want to help.
This project brings to table set of best practices, tools, and solutions:
Min API level is set to 21, so the presented approach is suitable for over
85% of devices running Android. This project takes advantage of many
popular libraries and tools of the Android ecosystem. Most of the libraries are in the stable version unless there is a
good reason to use non-stable dependency.
Feature related code is placed inside one of the feature modules. We can think about each feature as the equivalent of microservice or private library.
The modularized code-base approach provides few benefits:
This is a diagram present dependencies between project modules (Gradle sub-projects).
Note that due usage of Android dynamic-feature module dependencies are reversed (feature modules are depending on app module, not another way around).
We have three kinds of modules in the application:
app module - this is the main module. It contains code that wires multiple modules together (dependency injection setup, NavHostActivity, etc.) and fundamental application configuration (retrofit configuration, required permissions setup, custom application class, etc.).library_base module containing common code base that could be reused in other projects/applications (this code is not specific to this application) eg. base classes, utilities, custom delegates, extensions.library_x modules that some of the features could depend on. This is helpful if you want to share some assets or code only between few feature modules (currently app has no such modules)Clean architecture is the "core architecture" of the application, so each feature module contains own set of Clean architecture layers:
Notice that
appmodule andlibrary_xmodules structure differs a bit from feature module structure.
Each feature module contains non-layer components and 3 layers with distinct set of responsibilities.
This layer is closest to what the user sees on the screen. The presentation layer is a mix of MVVM (Jetpack ViewModel used to preserve data across activity restart) and
MVI (actions modify the common state of the view and then new state is edited to a view via LiveData to be rendered).
common state(for each view) approach derives from Unidirectional Data Flow and Redux principles.
Components:
LiveData) state changes to the view and deals with user interactions (these view models are not simply POJO classes).NavHostActivity (instead of separately, inside each view)This is the core layer of the application. Notice that the domain layer is independent of any other layers. This allows to make domain models and business logic independent from other layers.
In other words, changes in other layers will have no effect on domain layer eg. changing database (data layer) or screen UI (presentation layer) ideally will not result in any code change withing domain layer.
Components:
domain layer independent from the data layer (Dependency inversion).Manages application data and exposes these data sources as repositories to the domain layer. Typical responsibilities of this layer would be to retrieve data from the internet and optionally cache this data locally.
Components:
Repository is exposing data to the domain layer. Depending on application structure and quality of the external APIs repository can also merge, filter, and transform the data. The intention of
these operations is to create high-quality data source for the domain layer, not to perform any business logic (domain layer use case responsibility).
Mapper - maps data model to domain model (to keep domain layer independent from the data layer).
RetrofitService - defines a set of API endpoints.
DataModel - defines the structure of the data retrieved from the network and contains annotations, so Retrofit (Moshi) understands how to parse this network data (XML, JSON, Binary...) this data into objects.
Below diagram presents application data flow when a user interacts with album list screen:
All the external dependencies (external libraries) are defined in the single place - Gradle buildSrc folder. This approach allows to easily
manage dependencies and use the same dependency version across all modules. Because each feature module depends on the app module
we can easily share all core dependencies without redefining them in each feature module.
CI pipeline verifies project correctness which each PR. All of the tasks run in parallel:
These are all of the Gradle tasks that are GitHub Actions:
./gradlew lintDebug - runs Android lint./gradlew detekt - runs detekt./gradlew ktlintCheck - runs ktlint./gradlew testDebugUnitTest - run unit tests./gradlew connectedCheck - run UI tests./gradlew :app:bundleDebug - create app bundleRead related articles to have a better understanding of underlying design decisions and various trade-offs.
The interface of the app utilizes some of the modern material design components, however, is deliberately kept simple to focus on application architecture.
Checklist of all upcoming enhancements.
There are a few ways to open this project.
https://github.com/igorwojda/android-showcase.git into URL fieldgit clone https://github.com/igorwojda/android-showcase.gitThis is project is a sample, to inspire you and should handle most of the common cases, but please take a look at additional resources.
Other high-quality projects will help you to find solutions that work for your project:
Jetpack sample covering all
librariescommon state approach together witch very good
documentationktlint import-ordering rule conflicts with IDE default formatting rule, so it have to be disabledWant to contribute? Check our Contributing docs.
MIT License
Copyright (c) 2019 Igor Wojda
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial
portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Flowing animations and are distributed under Creative Commons License 2.0:
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手