- Added a mechanism to automatically scroll to the top in the TransactionsFragment when the difference between the old and new list of transactions is 1, which most probably means that a new transaction was detected.
- In ReceiveTransactionFragment, default the QR code to BTS in case the user has no balances so that he can easily show that QR to others and ask for funds.
- The create account transaction is paid by our faucet, for that reason we won't let users register premium account names for now. A couple of validations were added to make sure the account the user wants to create is not premium: account length has to be greater than 2 chars, account name has to start with a letter, and restrictions like having at least one dash, number or no vowels.
- Created the functionality to completely remove the current user account and its corresponding data from the database and the shared preferences, which will restart the whole application avoiding showing the License again.
- Created a Remove Account confirmation Dialog that appears when the user taps the REMOVE button. If the user has a PIN/Pattern selected, he must enter it successfully before showing the confirmation Dialog.
- Added a recurrent method that verifies every minute that the app is connected to the best node, and if that is not the case then it requests a reconnection.
- Moved the logic to generate the QR Code image from ReceiveTransactionFragment to its ViewModel (ReceiveTransactionViewModel), and used coroutines to send that process to a background thread to make sure this does not freeze the UI.
- The ReceiveTransactionFragment was using two ViewModels, which is not recommended. According to Google's MVVM guidelines, each activity/fragment should have only one ViewModel and that ViewModel should be coupled to only one activity/fragment. For that reason the methods used in the two ViewModels in ReceiveTransactionFragment were merged into ReceiveTransactionViewModel.
- The NetworkServiceManager expects a call to onActivityResumed after it has been configured to start the connection with the NetworkManager. But because we are using a single activity architecture, the call to onActivityResumed the first time the app starts is called before configuring the NetworkServiceManager thus leaving the NetworkService disconnected until another onResume activity lifecycle event is received. A fake call to onActivityResumed in NetworkServiceManager was added right after it has been configured in BitsyApplication to address this issue.
- Renamed the MerchantsWebservice to BitsyWebservice because it is now going to serve as a source of information of more than just merchants and tellers, but also the nodes the app is gonna connect to.
- Created new NodeRepository which will be in charge of accessing and updating the nodes database table with the information obtained from the webservice.
- Bitsy is now going to try to obtain the list of nodes it is going to try to connect to from the dabatase and use a hardcoded list as a fallback. The list of nodes in the database is updated regularly as well as their respective latency, so that in future app's startups it can use those latencies to immediately connect to the best node in the last app session.
- Added the library dependency to use Kotlin Coroutines with Room.
- Created the Node Room Entity, which will create the nodes database table.
- Created NodeDao, which will be responsible to access the Room entity (nodes database table).
- Created a Room database migration, to create the nodes database table in existing instalations updating to the new version.
- Enabled Kotlin's Parcelize annotation and used it to easily make FilterOptions Parcelable.
- Converted the ServiceGenerator class to Kotlin. This is a helper class that generates instances of Retrofit Services.
- The project had been stale for a couple of months, so a lot of libraries were outdated. I updated most of the outdated libraries and verified everything kept working correctly.
- Simplified the ServiceGenerator, removing some stuff that is not used.
- This crash was being caused when the user tried to filter the transactions in the Transactions screen, but the user has no balances (existent or downloaded). The app was not prepared to handle that case.
- The crash was happening in a very weird scenario, but it was good because it forced us to search an alternative to update the BalancesFragment when the user navigates back to the HomeFragment. The solution was to use the childFragmentManager instead of the fragmentManager to create the PagerAdapter used in the ViewPager that displays the BalancesFragment. Basically, because we are using nested fragments we need to use the childFragmentManager instead of just the fragmentManager, to use the correct LyfeCycle events.
- This is the adapter that populates the list of transactions in the TransactionsFragment, the crash was happening when the user tapped two or more items in the list at the same time. When that happens only the first item tapped opens its corresponding eReceipt correctly but the remaining ones throw an excpeption which was not being handled correctly and causing a crash.
- Avoided crash in SendTransactionFragment when trying to decrypt the WIF, but logged the exception to Crashlytics in case we find out this problem persists.
