At the end of 2020, I published a post on displaying currency conversion rates on a LaMetric Time smart clock. That solution only worked when I was working in my home office because that’s where the LaMetric Time lives. So I decided to build something similar on Android for other times. The app I produced is not production quality, because of scalability. But I have no intention of releasing it through any app stores. However, it suites my needs perfectly. In this series, we’ll look at various aspects of the app.
Overview
The app isn’t production standard, as I’ve already mentioned. In this first post, we’ll look at why that is.
Before we do, let’s first understand the app and how it works. Those that have read the previous article will know that I want to track USD to GBP exchange rates. Although I used a Google Sheets instance for that solution, I opted to use the TransferWise APIs directly. This is to obtain the balance of my USD account, and also the current exchange rate. So that I can surface the UDS balance and the GBP equivalent at current exchange rates. I’ll explore why I made this decision in the next article.
These posts are not sponsored. I genuinely use TransferWise for accepting payments in other currencies than GBP.
TransferWise APIs
To use the TransferWise to their fullest potential, the flow would be to perform OAuth to obtain an authentication token. Then use that token to access the user’s accounts allowing them to select the account they wish to use. We can then call the API to obtain the account balance, once the account ID has been obtained.
However, I opted to vastly simplify this flow. By using my API token directly, I was able to bypass the OAuth flow completely. I hacked in a call to return a list of my accounts and obtained the account IDS. I was able to identify the ID of the USD account, and hard configured that into the app.
With the account ID and API key hard configured, I can call both the account balance and exchange rate APIS. These require no authorisation or account selection preamble. This saves a fair bit of logic to handle failure-cases, and also UI to handle these flows.
This is the biggest shortcut that I took in the app. For my needs, I only ever require the balance of one account. If I ever need to change it, it’s a small configuration change and a rebuild. That is significantly less effort than implementing the OAuth and account selection flows.
I have not stored these hard-configured values in the GitHub repo that will (eventually) accompany this series. It is a really bad idea to store auth tokens and sensitive information, such as account IDs, in GitHub repos. Even private repos.
Scaleability
If I were to ever consider making this app suitable for mass consumption, this is where I’d have to start. However, the app currently has a use-case for a fixed account, this serves my needs perfectly, for now.
Simplifying In Production Apps
Simplifying API flows can save work for projects such as this which have limited user scope. Although this can still be useful in production. When starting on a new project or feature, we can sometimes simplify the flows during feature development.
For example, in a production app this technique would enable us to complete a story to display an account balance. This could be done before stories to authenticate, and select an account have been completed. The ‘display balance’ story receives an auth token and account ID as inputs and is agnostic of their origin.
Obviously, the entire feature is not complete until all of these stories are complete. But finding ways to remove dependencies on other stories can speed up development. It can also mitigate issues which arise if there are dependencies and one story gets held up.
For example, if an auth token is required for both the display balance and list accounts stories. Unexpected complexity delays the OAuth story. This blocks both of the dependent stories. However, if we remove that dependency temporarily by hard configuring the auth token, then we can complete those stories independently. When the OAuth story is completed, then the entire flow can be wired together, and the hard configured values removed.
Conclusion
Bypassing API flows can provide benefits. For both limited scope projects, such as mine, but also when performing parallel development. However, if an app isn’t intended for production, we can’t always cut corners. In the next article we’ll take a deeper look at this.
Normally I like to include working code to accompany each article in a series of posts. However, in this case, the result will be a fully working app. This will be published along with the final article in the series.
© 2021 – 2020, Mark Allison. All rights reserved.
Copyright © 2021 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.
