Radar Reflectivity data comes from Rainviewer integration, yes?
A few minutes ago, nothing was showing up under radar reflectivity (appeared to be clear). There was though, moderate to heavy rain occurring. I knew it shouldn’t show as clear. I opened RainViewer independently. It loaded up and showed me the current conditions I expected.
When I went back to Flowx, rain reflectivity did then show the data expected.
At first glance, it appears that Flowx was not able to access RainViewer data until I opened RainVewer manually. Am I mistaken about tje radar reflectivity data source?
• Flowx should have had sufficient time to load the data (~10 minutes).
• I did try enabling and disabling radar reflectivity in the Flowx display using the toolbar.
• RainViewer integration seems correct (see attached image).
There was a bug with radar this week. The RainViewer coverage map is broken and it was stopping the radar data in Flowx from rendering. I’ve fixed this now by making the coverage map world wide.
Now in terms of data opportunities, I live in San Diego, so the precipitation event opportunities are as few and infrequent as anyone has in the US. But that also means I rarely if ever miss a dataset!
• As before, during a rainfall today I opened Flowx and the screen was clear (see image left).
• I opened RainViewer and it clearly displayed the current precipitation. (See image center).
• I went back to (did not close and reopen) Flowx, turned radar reflectivity display off and back on, et voila, there be rain (see image right).
I am wondering if perhaps it may be to do with Android app-specific battery optimization. I did turn that off on both Flowx and RainViewer, but I just did that so I won’t know the results soon, or possibly up to months down the road when it next rains. Yes, I do have another fixed location or two, including the rain-world Florida. But likelihood of my remembering to check those is, unfavorable. I’m not unwilling. I’m just vapid!
But, the fix you mentioned did not solve the issue.
I don’t think it’s the same issue. The fix I made in the first case is still in place and can’t really break since I removed the coverage.
This sounds more like a download/data checking issue. The app didn’t trigger the checking of radar - probably a bug somewhere. Battery optimization does not affect apps in the foreground (i.e., open) only background apps (paused or widgets or services).
I am slowly refactoring the code and tidying it up. Much code, especially radar code, is hacked around the original code. Now I’m generalising this so it’s simpler, hopefully this will fix things.
Not to disagree with you at all. I’m just not clear in my thinking about your reply. Wondering what I’m missing.
The app specific battery optimization was, at the time of the issue, enabled for RainVewer and RainViewer could have been, almost certainly would have been “slept”. Until I manually opened RainVewer, it would have remained in that offline state, would it not? Or, are you saying opening Flowx (with RR on or turning it on) would have had the same result as manually opening RainViewer?
I opened Flowx first, no rain data (RR), then I manually opened RainVewer, Flowx then has RR data.
I do not know the first thing about developing Android apps so, thanks for the Edu.
Battery optimization on Android only applies when the app, widget or service has been in the background for some time. There is absolutely no battery optimization if you have the app open on the screen.
Flowx only checks for RainViewer pro when you open the app after quitting.If you pause the app and return, it’ll maintain the RainViewer pro state, not check again. The Rain Viewer icon at the bottom should disappear if you don’t have access to RainVIewer data but here we see it so you have access to the RainViewer data.
It seems Flowx did not trigger a check for new data on the server when you opened it. Maybe the second time you opened Flowx it triggered the check.
You can see there’s a lot of moving parts in Flowx - and sometimes they don’t move in sync.
