Right now project has build types but not product flavors. It'd be nice to demonstrate them.

Right now repository only fetches 10 responses statically defined. Introduce paging with paging library.

Current state has multiple activities. Goal is to introduce single activity approach with deeplink navigation.

Right now core uses api to provide repository as usable to other modules that include it. repository should be included exclusively instead.

Extract query processing logic and reduce complexity

A good approach might be using gradle as in here: https://jeroenmols.com/blog/2019/06/12/modularizationtips/

Right now repository is a single module using persistence and network. Network and persistence can be separate modules.

Right now fetching rockets are sequential:

Fetch -> Save -> Return

This should be async. It's good to take al ook at Room's LiveData support. flow can be replaced with liveData builder in BaseInteractor in this case.

Create example use cases with using new material library components

Update library versions. Room's new Flow support might be option to replace suspension.

Need to add search functionality that runs on different feature, that will present query results in a separate list. We should use https://launchlibrary.net/1.4/launch method - there are examples under section.

Documentation: https://launchlibrary.net/docs/1.4.1/api.html

Setting adapter to null would fix this leak

Ticket here -> https://issuetracker.google.com/issues/139793883

Boradcasting might be an idea to worth looking, just need to experiment.

Classes such as Api, ApiImpl, daos etc. are public. They should be internal and closed off from outer access.

AppModule contributes activities of features. This contribution should be moved to corresponding module.

This is due to translationY

It's com.melih.list, should be com.melih.launches.

NetworkInfo is deprecated. Should check how to achieve same functionality with ConnectivityManager.

Right now feature module & fragments inside are not scoped. Add scopes for dependency hierarchy.

Adding CONTRIBUTING with descriptions and current state.

Possibly move it to base for handling errorData out of the box. This may require introducing a new generic for viewModel in base.

Use material library to apply styles and themes, make use of attributes that platform uses for better effect.

Some modules depend on concrete classes that are in other modules. This can be a good case to apply dependency inversion.

Righ now it's com.melih.list somehow. Should be com.melih.detail.