Added BitcoinAverage as a provider

[BitcoinMitchell]

Q	A
Bug fix?	No
New feature?	Yes
BC breaks?	No
Deprecations?	No
Fixed tickets	#8

Hereby a draft pull request that implements the concept of multiple providers. Sadly, I had to add it to both the front- and backend, since the device itself doesn't have enough memory to store the full response of CoinGecko's available coins and I couldn't find a way to resolve that.

If you like my current solution, I can mark it as ready to be reviewed. If you have a better idea, let me know.

[tmlee]

@BitcoinMitchell have you tried our simple endpoint, as it is more lightweight giving you only what you need
https://www.coingecko.com/en/api

[BitcoinMitchell]

@tmlee The simple endpoint only has a supported_vs_currencies call available, which is great, but I would need one for the supported coins as well.

After some testing with a JSON array that only contains the ID's of the coins, the PaperLedger can load about 2700 before it's too much and returns a size of zero after initialization (which is around nzed).
The PaperLedger just doesn't have enough capacity (which is probably why @AIFanatic is grabbing the data from CoinGecko in the frontend in the current master-branch).

---

@tmlee, if you could add an endpoint that returns the 100 or 200 most popular coins (you could make this configurable with a maximum_coins variable) that would help a lot to get it all to the backend. Assuming @AIFanatic isn't fully against that idea. 😉

[AIFanatic]

@BitcoinMitchell I like the approach, specially from the frontend side but I still believe the backend should be more abstract and just parse any json into a meaningful ticker.
I came across this: bblanchon/ArduinoJson#821 which essentially uses JSONPath, or a string, to process JSON.
This would cause a smaller footprint on the device resources which would propagate to easier implementation of future functionality such as the battery.

After I address some issues with the battery itself I will look into this heavily and come up with a design which I will run through you so we can share thoughts.

As always thank you so much for your contribution

@tmlee Thank you for your contribution to the project :)

[BitcoinMitchell]

@AIFanatic I'm not sure how you would make this even more abstract. We already have a provider which just gives you a generic object that you can use. At some point you have to parse the vendor specific response. 🤔

I'm excited to see what you can come up with and I'll be using this branch for now! 😁

[AIFanatic]

@BitcoinMitchell It would be something around the lines of the backend only storing fixed generic data about providers by following a simple standard.
For example all providers need to have a url, title, currency, price, volume and last_change.
The device would only store something like this (coingecko):

[
  {
    "url": "https://api.coingecko.com/api/v3/simple/price?ids=bitcoin&vs_currencies=usd&include_market_cap=true&include_24hr_vol=true&include_24hr_change=true&include_last_updated_at=true",
    "title": "Bitcoin",
    "price": "$.bitcoin.usd",
    "volume": "$.bitcoin.usd_24h_vol",
    "last_change": " $.bitcoin.last_updated_at"
  }
]

This method would work with any endpoint and the backend is completely abstracted from what is parsing, allowing to show crypto prices, stocks, weather etc (a similar method can be applied to the actual display/layout in order to generalise even further)

Of course it has its quirks, one of them being how to handle different types of requests for example if OAuth is needed but for now it seems to suffice :)
Another one is that the frontend still has to implement the providers and since the frontend is flashed into the backend it would require an upgrade of the device. But its easier to query a list of the providers from the frontend (from github for example)

[BitcoinMitchell]

That does look pretty interesting (and relatively simple as well), so I'm all for JSONPath. However, I still would like to do all the calls in the backend and remove the provider classes I added in the frontend. It's too much coupling if you ask me.

If CoinGecko gives us a way to limit the amount of coins they return (like the most popular 200, which would more than suffice if you ask me), we could keep the frontend totally oblivious to what the backend is actually doing.

Storing a list of providers on GitHub seems like a decent idea, until you drop this project and remove the repository (extreme example, but you get the point).

[tmlee]

 if you could add an endpoint that returns the 100 or 200 most popular coins (you could make this configurable with a maximum_coins variable) that would help a lot to get it all to the backend. Assuming @AIFanatic isn't fully against that idea.

Are you referring to 100/200 popular coins in simple form or like the markets API?
Some examples would be clearer

[BitcoinMitchell]

@tmlee I was thinking of something like this:

curl -X GET "https://api.coingecko.com/api/v3/simple/popular_coins?maximum=100" -H "accept: application/json"

[ "bitcoin", "ethereum", "dash", "ripple", ....]

[BitcoinMitchell]

@AIFanatic I've started working on an alternative implementation of the providers using JSONPath. Sadly, the implementation that is available in the linked issue (bblanchon/ArduinoJson#821) does not have search capabilities so I had to be a bit creative. You can see the progress over here: https://github.com/BitcoinMitchell/PaperLedger/commits/providers-jsonpath

Not sure if I'll be keeping the add function, might just be handier to have the full provider JSON stored in the variables.h for now.