Audit all dependencies
It appears one of our dependencies is not maintained, no commits for over 2 years. We only found out by coincidence (see #431). I wonder if there is an automated tool to do this? Surely other projects with hundreds of deps don't test this manually?
com.diogobernardino:williamchart:2.2 is now available in version 3.3.0.
I tried to build it. It is necessary to migrate to AndroidX and to increase the minSdkVersion to 16.
Unfortunately it still does not work: the library was written from scratch, so the GraphActivity.java module needs to be adapted. Unfortunately I could not find a help/wiki for the library.
I wonder i v2.2 is still supported? I'll see what I can find.
It appears not, so I asked in an already active issue if the new docs would be along soon. Let's see what happens.
increase the minSdkVersion to 16
If possible, I'd like to keep this as low as we can so we remain compatible with as many older phones as possible. We may need to re-evaluate that depending on the charting library we use.
Something just occurred to me: how bad an idea would it be for a Forecastie dev to fork and maintain the 2.2 branch of WC? That answer probably involves something like "WHAT, more code to look after?!"
increase the minSdkVersion to 16
If possible, I'd like to keep this as low as we can so we remain compatible with as many older phones as possible. We may need to re-evaluate that depending on the charting library we use.
Something just occurred to me: how bad an idea would it be for a Forecastie dev to fork and maintain the 2.2 branch of WC? That answer probably involves something like "WHAT, more code to look after?!"
From a code point of view, it would just an additional Android build type (I could do it). What I am not familiar with is, how to automate different build flavors in F-Droid.
The practical question is: "is it worth the effort", trading off the good will to support as much users as possible and the real API version user share at that time.
From a code point of view, it would just an additional Android build type (I could do it). What I am not familiar with is, how to automate different build flavors in F-Droid.
On the surface yes, but i think we should be actively maintaining it, making sure there are no security issue, etc. Who knows what that will entail.
The practical question is: "is it worth the effort", trading off the good will to support as much users as possible and the real API version user share at that time.
Absolutely, this is totally the deciding factor. "I don't know" is the first answer and we're unlikely to figure that out to any precision.
We're not able to collect stats on who uses forecastie, specifically which version of Android they have. That said, I will have a poke around on the f-droid site, perhaps they collect semi-anonymous stats on f-droid users.
It appears not, so I asked in an already active issue if the new docs would be along soon. Let's see what happens.
4 months and no reply. he's still actively developing, but writing docs is a different story of course.