- Purging invalid entries of the 'equivalent_values' table
- Displaying whathever currency the user happen to have selected *at the moment*. The previous implementation had a flaw that would have made the currency that was used to calculate the equivalent values in first stick, even if the user changed to another locale settings later.
- Increased the margin of the QR codes generated in the Receive Transaction screen, so that they are easier to read using low end devices, specially when the app is in night mode.
- Only inserting an equivalent value into the database in case the value is equal non-negative (negative values are a result of errors)
- Using USD as fallback equivalent value currency
- For some reason if we use a memo longer than 107 chars we get an error, to avoid that error we are limiting the memo length to 100 chars using TextInputLayout's counter options to show the current char count and the max char count. If the current char count exceeds the max the TextInputLayout turns to red and the Send button is disabled.
- Modified the method that fetches the tellers from the webservice to keep requesting the tellers list until nothing is returned, to make sure the whole list of tellers is obtained.
- Modified the method that fetches the merchants from the webservice to keep requesting the merchants list until nothing is returned, to make sure the whole list of merchants is obtained.
- Modified the time the app waits to update the merchants and tellers list from 24 hours to just 3 hours.
- The crash was happening because the dialog that verifies the automatic time was being created in onResume, so if the user leaved the application while the fragment was showing and returned to it later another multiple dialogs would be created. The first one to be accepted correctly navigates the user back, but the second creates a crash because references a no longer existing fragment. The dialog creation was moved to onViewCreated instead, so that only one dialog is created.
- Trying to send a transaction in SendTransactionFragment can fail if the date/time is not correctly synced. A Time Sync Error dialog was created to warn the user about that situation so that they can take action and be able to correctly send transactions from bitsy.
- Translated the strings used in the Time Sync Error dialog to all supported languages, and hand corrected the Spanish version.
- A user is having issues with its active private key, but we have not enugh information to solve the problem. A possible exception causing this issue will be logged to Crashlytics so that we can understand what is going on and solve it.
- Added the PDFjet library as a Java Library module to the project and moved all the logic to create the transactions PDF in the TransactionsFragment to use the new PDF lib instead of the old one.
- Fixed the time formatter that was being used to format the transaction's times in exported PDF/CSV files, it was printing months in the place of minutes.
- After a lot of search I found that the issue with the EditText in the PINSecurityLockDialog being hidden below the SoftKeyboard was due to a bug in the ConstraintLayout library.
- The crash was happening due to an unhandled exception, the problem was that the statement that was raising an exception was out of the try/catch block.
- Downgraded the appcompat library to v1.1.0-beta01, the v1.1.0 introduced a bug that causes a crash in the WebView in certain devices running Android L.
- The amount field in the SendTransactionsFragment wasn't prepared to deal with Locales where the decimal separator is a comma. In order to deal with that internally, the commas in the amount are first converted to points before trying to convert the amount string to a double.
- Updated a bunch of libraries, fixed a couple of issues, and tested everything else worked correctly.
- Updated both compileSdkVersion and targetSdkVersion to 29 (Android 10).
- 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.
