regmoraes/wallet-challenge

Wallet Android application for the Stone's Mobile Challenge

Crypto Wallet

Project for the Stone's Mobile Challenge

Screenshots

Project Structure

The application was created using the Kotlin language and sought to follow the concepts and practices of:

• S.O.L.I.D
• Component Based Architecture
• MVVM (Model-View-ViewModel)
• Reactive Programming

The project was divided into 3 modules, each one responsible for a software layer. The dependencies are unidirectional and non-transitive, from 1 to 3:

1. app: Android application responsible for accessing and manipulating Android classes and to provide a presentation layer that follows the MVVM pattern.

2. wallet-core: Java library responsible for providing methods and classes to manage transactions, wallets, and to query, purchase, sale, and exchange cryptocurrencies.

3. wallet-api: Java library responsible for providing methods and wrappers to query cryptocurrencies info provided by cryptocurrencies APIs.

The wallet-core module (along with its wallet-api dependency) was created to act as a component that provides classes responsible for accessing and managing data from a specific context (wallet, market, transaction etc.). To provide this structure, the wallet-core provides a WalletCoreCreator class, which provides the implementation of a WalletCore interface, which in turn has methods that return classes that operate on a defined context; These classes are called Managers.

To get an implementation of WalletCore you need to provide some repository interface implementations to the WalletCoreCreator.

Because the app module depends on the wallet-core, the above structure looks like this:

Dependencies Used (dependencies.gradle):

• Dagger2
• Reactive Extensions (RxJava2, RxAndroid)
• Retrofit
• Android Architecture Components (Room, ViewModel)
• Mockito
• MockWebServer
• Espresso
• (...)

Tests

Unit and instrumental tests were implemented. The tests were intended to deal with the majority of success and error scenarios of use cases of the following elements:

• Managers from wallet-core
• Concrete APIs implementations from wallet-api
• Transaction history, wallet and market Fragments
• ViewModels

Notes

1. By default all classes in Kotlin are final, however, this ends up generating problems to mock classes in instrumentation tests. There are a few ways to work around this problem, but due to the time, it was decided simply to change the visibility of some classes and methods to open.

2. No layouts were generated for bigger resolutions and some styles and resources were declared directly in layouts, not on its own files.