Advanced BCH Monitoring with Tasker (Part 1: Refactoring)
"If life give you lemons, mint a token."
keepBitconFree.org (Circa 2019)
Previous series:
Monitoring a BCH address with Tasker
Sometimes projects just keep growing
What started being just a DIY project to be updated about your addresses transactions and crypto-to-fiat conversion, might be growing too much, is on those cases where you must stop and think about preparing your projects for growing up further.
Thousands of ideas are passing through my head: caching funded addresses to reduce bandwidth consumption, support to several REST API services for availability, error handling, SLP token support... But the last project structure is improvised and as an improvised structure, it does not scale well.
Planification for a new structure
So I've been scratching a structure that allows us to add more features in the future, but it's also ok, to begin with, the UML diagram is just pretending to follow the standard, but as long as it is understandable for a software developer, he'll be able to code this into any programming language that can work properly with this kind of structures.
The represented structure is made as if it was for C++ because it is the language I'm using every day but as I told before, it can be implemented in any other compatible language and, with several limitations, Tasker it's one of those.
The structure explained
What we can see on the structure is that there is a Class named as TaskerBchSdk
meaning "Tasker Software Development Kit (SDK) for Bitcoin Cash (BCH)" and it's methods are as it follows:
Configure(...)
: Will be the configuration method, we'll call it on the first run to prepare our software with the essential information to start working.LoadBalance()
: Will query the current balance for all our addressesLoadCurrencyValue(...)
: Will query how much is BCH on the passed currencyComputeCache()
: A new feature! To be explained on future episodes ;)CheckCache()
: Part of the caching featurenotifyChanges(...)
: Will notify for changes (ex: Push notification, Mi Band)
We also see three interfaces representing different blocks of logic:
IExchangeApi
: We'll code this interface to retrieve information from an Exchange or a Trade information REST API, mainly to get to know the market price of our assets (i.e: CoinGecko)IGui
: This one will be updated with relevant data and use it to notify the user (i.e: Tasker native push notifications, 3rd Party notification services)IBlockExplorer
: Finally, this interface will be used to retrieve information from the blockchain (i.e: Blockchair)
In the next part, we'll learn how to structure our Tasker tasks into programming interfaces so we don't have to deal with large lists of tasks.
Special thanks to Blockchair.com for providing an API key.
Don't forget to subscribe, feedback will be appreciated!
...and you will also help the author collect more tips.
Haha, thanks for the quote! Great article, will be interesting to see where this takes you.