AC:

• UI with databinding and View model class(es)
• Scrollable list of transactions

Display a scrollable list of transactions retrieved from our multiaddress API.

Each item should at least have a BTC value, some indication if money was sent or received and a transaction time.

Details

Retrieve the data via GET https://blockchain.info/multiaddr?active=xpub6CfLQa8fLgtouvLxrb8EtvjbXfoC1yqzH6YbTJw4dP7srt523AhcMV8Uh4K3TWSHz9oDWmn9MuJogzdGU3ncxkBsAC9wFBLmFrWT9Ek81kQ. You are welcome to use your own xPub or address if you so wish.

An example response can be found here.

Much of the information can be discarded for the purpose of this challenge. The information you’ll be most interested in is as follows:

“wallet” -> “final_balance” - the current balance of the xPub or address, in Satoshis

“txs” -> “result” - the amount sent to or sent from the xPub or address. Negative balances (“-123456”) are sent from the wallet

“txs” -> “time” - the timestamp of the transaction

“txs” -> “out” - an array of the outputs of the transaction. Transactions can have multiple outputs, but the majority only have two. One is a “change” output that is returned to the wallet and should be ignored if you’re planning on displaying the recipient’s address. A “change” output easily spotted because the output has an “xpub” -> “m” field which matches the xPub parameter in the multiaddress call

“txs” -> “hash” - a unique identifier for each transaction

“txs” -> “fee” - the total fee for the transaction

All values in the response JSON are in Satoshis. 1 BTC is found by dividing the Satoshi value by 1e8, rounded to 8 significant figures.

Hints

The challenge is deliberately quite open ended; you can do as much or as little as you see fit. However there are a few things that we’d like to see:

• Kotlin preferred, although please use Java if you’re more comfortable
• Some testing, Unit and/or integration and/or UI
• Some use of RxJava
• Some use of your preferred dependency injection framework
• A nice Material Design UI is a plus, as is handling loading/content/failure states
• Leave us notes! If you want to explain what you were thinking or trying to achieve, document it in code.

AC:

• Don't crash in any error, e.g. failure to connect to server
• Allow user to retry in event of any error

“txs” -> “time” - the timestamp of the transaction

AC:

• New module
• New Retro-fit and RX compatible interface
• Spike RX call to backend