FlickSlate

An Android app using the TMDB API.

The goal of FlickSlate is to showcase best practices and learn some new techniques.

It also showcases some of the techniques used in my articles about caching and architecture

🧩 Setup

Register an account here, and follow the instructions to get an API key. Add the API key to the gradle properties file. The project already has an empty value, but I recommend adding this to your global gradle properties file to avoid committing it accidentally. That's it! You are all set up!

📚 Tech stack

• Application entirely written in Kotlin
• UI developed in Jetpack Compose
• Following the Material 3 guidelines
• Asynchronous processing using Coroutines
• Dependency injection with Dagger and Hilt
• Database using androidx-room
• Some modules contain shared Gradle test fixtures modules
• Using Compose Preview Screenshot Testing to verify UI

🏛 Architecture

FlickSlate architecture is Clean(ish) Architecture as recommended by Google.

Let's take a look in each major part of the application:

• main - Contains the entry points to the application, plus Jetpack navigation.
• feature modules (and submodules for domain, data, and ui):
  • account
  • movies
  • tv
  • search
• Submodules within above features.
  • domain - Contains the shared domain model, the api interface, and optionally use cases. Domain depends only on itself and all interaction it does is via dependency inversion.
  • data - Contains the (db, network, etc) modules.
  • ui - Presentation layer
• shared - Shared domain, UI and data modules specific to this app, as described in this article
• base - Kotlin and Android base classes, reusable in any apps. Also described in the in above article

In my view this reflects the optimal structure of a medium app (25-50 KLOC, 15-25 features). This app is smaller than that, so this is for demonstration purposes and to facilitate future growth.

👀 Others

• Network calls are using caching strategies and fetcher functions as detailed in my Caching Strategies in Android article.

  • Since the article the fetch functions were changed, so they do not do the mapping anymore, and they do not need the Response versions either. This was extracted into newly introduced RemoteDataSource and safeCall functions.
  • These are the variations and usages among the fetcher functions currently:
    • safeCallWithMetaData + fetchCacheThenRemote w/CACHE_FIRST_NETWORK_SECOND (to extract the ETags)
      • UpcomingMovies (also paging)
      • NowPlayingMovies (also paging)
      • PopularMovies (also paging)
      • TopRatedTv (also paging)
      • Genres
      • GenreMovies (also paging)
    • safeCall only (no caching, no header)
      • GetFavoriteMovies (also paging)
      • GetFavoriteTvShows (also paging)
      • GetRatedMovies (also paging)
      • GetRatedTvShows (also paging)
      • GetRatedTvEpisodes (also paging)
      • Rate Movie
      • Delete Movie Rating
      • Rate Tv Show
      • Delete Tv Show Rating
      • Favorite Movie
      • Unfavorite Movie
      • Favorite Tv Show
      • Unfavorite Tv Show
      • Search Movies
      • Movie Details
      • TV Details
    • safeCallWithMetaData + fetchCacheThenRemote w/CACHE_FIRST_NETWORK_LATER
      • None, but I could use this where it's not important to display the latest data
    • safeCallWithMetaData + fetchCacheThenRemote w/CACHE_FIRST_NETWORK_ONCE
      • None, but I could use this to fetch data that is not changing, like the genres (which changes sometimes, so I could invalidate it from time to time)
    • safeCall + fetchRemoteFirst
      • None, but I could use this to fetch frequently changing data, where the cache is a fallback.
    • No

• Many calls are doing paging and caching at the same time. It uses custom paging, so do not use this in production yet.

💩 Known problems

• Paging might have subtle bugs due to the shortcomings of the TMDB API:
  • It returns the cached versions of the pages, which are retained for 7-8 hours, but regenerated at different times.
  • As a result, it can happen that two movies swap pages, but because only one of them is updated, one movie will be duplicated, the other will disappear.
  • I haven't tested it, but this could break paging, where we scroll to the end of a long list, but because more than the threshold number of movies are missing, the fetch is not triggered.
  • There are support tickets from years ago about the issues:
    • https://www.themoviedb.org/talk/596636379251410bfa130225
    • https://www.themoviedb.org/talk/5ee3abd1590086001f50b3c1

🚧 Under construction

• Adopt Metro for dependency injection
• Add coverage through Kover

📃 License

Copyright 2024 Zsolt Bertalan

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.