An open-source Android app for viewing Movies / TV information.
MovieMan is the materialization of how (I think) the Architecture of a good Android Application should be
MovieMan is my sandbox project, where test my ideas, ideal architectures and play around with libraries.
It's pretty close to a full-fledged application, complete with Network Requests, Local DB, Material Design and Test Cases.
It contains some bells and whistles like Kotlin, Coroutines, Jetpack & AndroidX.
It's Modular, has Dependency Injection, and closely follows DRY and SOLID principles.
It's also backed by CircleCI to build and run test cases.
MovieMan is built to look good. I'm no designer or UX expert, and will borrow inspiration from common Google applications. You will find Fade / Material Transitions at some places, just cause they're easy to do and maintain :)
I’ll keep adding features based on what the TMDB API provides.
Writing duplicate screens and code for API-completion purposes is nowhere on my TODO list
The aim is to make MovieMan feature-complete in terms of a variety of features, all while learning new things and implementing useful cases.
Screenshots & Gifs:
Clone the Project
Grab an API key from TMDB and add 'TMDB_API_KEY' to your Environment variables. Instructions can be found in Properties.kt
Add the following to your Environment variables after generating a keystore. Or optionally, remove the signing config from app's build.gradle.kts
Gradle Sync and Rebuild
Design Decisions & Dependencies:
JetPack - Architecture Components & AndroidX:
Would be a loss to build an application without these libraries. With Google advocating MVVM, and these libraries working so flawlessly with each other, it really leaves you no choice.
Room - Database Layer
ViewModel - Data Preservation across configuration changes
Lifecycle - Handling annoying issues with Activities / Fragments namely when pushing data during false states
Navigation - Handling Intent / Fragment Transactions, isolating sources from destinations and easy argument passing!
AndroidX, Material Components - For embracing Material Design and backporting API features to minSdk
Koin - Dependency Injection:
Sick and tired of Dagger in Production, and annoyed by it slowing down my build, I turned to a substitute. Kodein seemed to be the recommended (and a more established) library for Android, however I chose Koin for it's sheer simplicity. It also made strides in performance in v2.0, which makes it my current choice for DI without code generation.
A very simple choice when it comes to using REST APIs. I prefer Moshi over Gson because Moshi throws correct exceptions, and has good support for Kotlin. It also doesn't come with a Date Formatter by default, forcing you to handle UTC yourself.
See Moshi vs Gson for more info about this decison.
A gold combination for unit testing and mocking dependencies. Since the app follows SOLID, dependent layers can be easily mocked and tested in isolation.
I'm using Mockito-Kotlin for a simpler DSL (and not writing
when because ‘when’ is a Kotlin keyword)
CircleCI - Continuous Integration:
I chose CircleCI because of it's easy setup and configuration. Also because it provides free build times (1000 minutes) per month. I use CircleCI to build the app and run all it's Unit Test Cases.
Separation of Concerns and eventually supporting Instant Apps and Dynamic Delivery.
Modules are split by feature, with some base modules like core and data. Multi-modular applications force you to isolate components and prevent easy imports / dependencies between them.
Such applications can build faster too, since Gradle caches the unchanged modules, and will only build the changed ones (and the modules dependent on the changed module if a public API is touched)
See How Yelp Modularized the Android App
Contributions in any form are welcome.
Just make sure to have fun and learn new things :)