Memory Android Engineer Interview Assignment
Hello and welcome to the Memory Android Engineer interview assignment!
There can be no demo app that doesn’t use the TMDB API so guess what API we picked this time?
Yeah you guessed it right: It’s TMDB.
- You can find the API docs here: https://developers.themoviedb.org/3/getting-started/introduction .
- You shall create a TMDB account and get an api key in order to complete this assignment.
- Please add your api key to the local.properties file as
tmdbApiKey=XXXXXXX, it won’t be shared
About the demo app:
- This demo app shows a list of trending movies grabbed from the TMDB trending movies API.
- Clicking on a movie in the list shows a detail screen which sports a bigger picture and adds
a textual overview of the movie.
- The codebase strives to mimic the structure of Memory’s Android apps, the goal is to give you a
feel at what it’s like to contribute code as an Android Engineer at Memory.
- The project uses Gradle’s new Dependency Catalog feature to manage dependencies:
- The UI is built with Jetpack Compose and driven by ViewModels using snapshot state variables,
you may use Flows instead if they suit you better.
- The business logic uses coroutines and Flows to manage asynchronous operations.
The app is comprised of several modules:
- An HTTP client module for the TMDB api in the /shared/httpapi directory.
- A local database module in the /shared/database directory built with SQLDelight.
- A prototypical business logic class named MovieRepo in the /shared/logic/movie module.
- A home screen showing the list of trending movies in the /shared/screens/trending module.
- A movie detail screen in the /shared/screens/movie module.
- An Android application that makes use of all the other modules in the /app directory.
- Currently only the first 20 trending movies are shown in the list: you should handle pagination
and display the full list of trending movies available from the API.
- Show a movie’s runtime in the detail view: it can be fetched using the
- Show runtime errors (e.g. network failures) in the UI.
- Tests are missing for the modules under /shared/logic and /shared/screens : write some.
- Add some embellishments to the overall UI.
- Try to use the database as a cache as much as possible: the more data the user can still see
without network access, the better.
Please try to complete as many of the above steps as you can: The further you get the better but
don’t worry too much if you can’t go all the way.