Grigoriym / Cashier

My pet project where I learn and test eveything. Such a sandbox for me

A Cashier App backed up by my own backend

This project is under active development and refactoring. And this is a sandbox for me as well. This is why some parts of code may look as overengineered, bad, strange, etc.

"Wtf is this app about?" - you'll ask.

Imagine your local groceries where sellers at the cash register scan your products and eventually ask you to pay. Well, this app actually does this. You can choose products, you can sell them, you can scan a product by a barcode. There is also such a feature as Waybill, this is needed for sellers when some new products are shipped to this grocery and a seller has to add them to the database of products and to their grocery. I do this because I had an experience with an app of such functionality.

Login	Select stock

Edit Product	Sales

Project structure

Here you can see the app flow

Refactoring History

1. Hilt -> Dagger (because of multi-modular architecture)
2. Gson -> Kotlin Serializable (why not?)
3. Android Navigation Component -> Cicerone (because of multi-modular architecture)

Build With

• Kotlin
• Jetpack Compose - is Android’s modern toolkit for building native UI.
• Retrofit - A type-safe HTTP client for android and Java.
• Coroutines
• Hilt - A dependency injection library for Android that reduces the boilerplate of doing manual dependency injection in your project.
• Pagination - helps you load and display pages of data from a larger dataset from local storage or over network.
• ViewModel - is designed to store and manage UI-related data in a lifecycle conscious way.
• WorkManager - is an API that makes it easy to schedule reliable, asynchronous tasks that are expected to run even if the app exits or the device restarts.
• Room - provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite
• StateFlow, SharedFlow - StateFlow and SharedFlow are Flow APIs that enable flows to optimally emit state updates and emit values to multiple consumers.
• Chucker - A simple in-app HTTP inspector for Android OkHttp clients.
• Coil - An image loading library for Android backed by Kotlin Coroutines.
• Android Debug Database - A powerful library for debugging databases and shared preferences in Android applications
• Scabbard - A tool to visualize and understand your Dagger 2 dependency graph.
• Cicerone - is a lightweight library that makes the navigation in an Android app easy.

TODOs

• Remove excessive emit(Try.Loading) from repos. Check flow use cases
• Remove base useCases, otherwise it is problematic to test

Roadmap

• Move all UI to compose, (only scanner is left without any changes)
• Google Sign In, Firebase Authentication
• Add tests and all that stuff (In progress)
• Make full integration with my own backend solution
• Learn proguard and somehow do something with it here
• Enhance navigation, abstract navigation (kinda made it with the help of Cicerone)
• Some modules are kinda useless or a bit messy: core, extensions, app
• Add CI and all that cool automated features
• I don't know the right way to integrate communication between composeScreen and viewModel, especially when there are many data to send
• Make usable caching of data
• Is SingleLiveData a good choice? But I have no other options with compose, at least for now. (Changed it for SharedFlow)
• Compose has problems with the soft keyboard.
• I do not have a general ui kit, And I need a designer
• Structural and navigation anti-patterns in multi-module and modularized applications
• In perspective, Dagger 2 is better for multi module app.
• Using Dagger2 try to remove all inject lateinit
• Refactor repositories, they are all app-scoped
• Feature flags
• Guest Mode
• Show sth if there are no products/categories etc.
• Settings screen
• android.nonTransitiveRClass=true
• some gradle build enhancement, like in aag 2, also there dagger2 tips on scope lifecycle and their holders
• what is api and impl modules and how do they work
• abstract image loader (coil)
• refactor all stuff connected to the workManager
• make it more convenient RequestWithAuthToken
• make workers' logic on some timestamp or sth like that
• Debug panel
• Biometrics
• GridLayout possibility in products
• SafetyNet attestation API
• Firebase services
• Publish app to googlePlay, appGallery, galaxyStore
• Analytics
• Add online receipts

Thanks to

1. Dmitry Akishin - Logging in a multi-module Android project - for implementing logging in android modules and pure koltin/java modules
2. Dimitar Dihanov Android Multimodule Navigation with the Navigation Component
3. Vladimir Tagakov for his videos on Dagger2: this one, a video No 8 from Podlodka Android Crew#1 (you can buy it here)
4. Android Broadcast - Dagger2 course
5. Android Academy Global

Some duct tapes

1. rememberLazyListState() in some compose functions where we have LazyList() and Scaffold's bottomBar. It is done so that list's bottom has been constrained to the top of Scaffold's bottomBar.