openhab-ios
openhab-ios copied to clipboard
openhab
[WIP] OpenHABTracker improvements and SSE monitoring of Main UI
Refactors the OpenHABTracker class to a singleton and unifies reachability logic. Implements Main UI SSE callback for application health, fixes small issue in drawer where the openHAB version is missed
Signed-off-by: Dan Cunningham [email protected]
HI @weakfl , @timbms
This PR started with adding support to help with https://github.com/openhab/openhab-ios/issues/687 . There is a change to core, https://github.com/openhab/openhab-core/pull/3086 and a change to the Main UI, https://github.com/openhab/openhab-webui/pull/1499 that is also required for this to work (although the client will work as is with older OH versions of course)
This also lead me down a path to clean up the tracker code, which was not really designed to have multiple views depend on it. I changed this to a singleton pattern, so there's only one running, and allowed it to have multiple delegates. I also moved all the code that detects the openHAB version to the tracker, which cleans up the code quite a bit and reduces a network call or two when loading .... although i would say there is still a lot of refactoring we could do to make it better. I would say this is an incremental change until maybe we can rethink this class.
If i have more time, i would like the tracker to be much more active in monitoring network connections and proactively track openHABs, right now it still needs a kick when a view loads.
Can we get this pushing to test flight ? I would like to start testing the tracker changes as they could have the biggest impact.
Thanks!!!
@digitaldan you can trigger a TestFlight build in the actions menu.
If we think about a bigger refactoring we might also look into using websockets?
@digitaldan just on my phone, so can't review this properly. But looking at the MulitcastDelegate I'm really wondering if it's time to raise the deployment target to iOS 13 to be able to use Combine.
Concurrency framework would be another bonus.
Hmm, i'm not that well versed in whats new with Swift, but Combine does look promising. We have this "AppData" object that we pass around thats kinda ugly, as well as a global Preferences object and probably a few other things where a reactive state manager would definitely be a big improvement!
sorry for going MIA on this, unfortunately IRL got in the way, hopefully have some time to pick up later this week.
If we think about a bigger refactoring we might also look into using websockets?
Sorry i missed this. What would use websockets?
@digitaldan isn't it possible to get item updates through a websocket instead of polling?
I thought that might be beneficial, especially once we move to SwiftUI.
There is not websockets support, but sitemaps can use Server Side Events (SSE) . There is a specific endpoint for subscribing to sitemaps, /rest/sitemaps/events/subscribe and /rest/sitemaps/events/{subscriptionid}, the classic UI as well as our android client are both using this if you want to check out an example.
The Main UI also uses SSE to receive the actual item state changes as they happen at /rest/events/states
I'm just building a testflight version now, once thats pushed out and verified I think this is ready to merge.
Shouldn't we lift the minimum target to iOS 13? Current version is 16.1.
I worry that there are quite a few users who use their old IOS devices as remotes and touchscreens around the house. I seem to remember the last time we did a version bump, this caused some frustration. I wonder if we have some statistics on IOS use of the app ? If legacy hardware users we're not an issue, i would absolutely say move to IOS 13 or later.
So here is our year to date (ytd) downloads by IOS version
| PLATFORM VERSION | TOTAL DOWNLOADS | % |
|---|---|---|
| iOS 15.3 | 2,864 | 15.77% |
| iOS 15.4 | 2,864 | 15.77% |
| iOS 15.5 | 2,799 | 15.41% |
| iOS 15.6 | 2,651 | 14.60% |
| iOS 15.2 | 1,979 | 10.90% |
| iOS 16.0 | 1,407 | 7.75% |
| iOS 15.1 | 1,124 | 6.19% |
| iOS 12.5 | 630 | 3.47% |
| iOS 15.7 | 376 | 2.07% |
| iOS 14.8 | 361 | 1.99% |
| iOS 15.0 | 226 | 1.24% |
| iOS 14.7 | 203 | 1.12% |
| iOS 14.4 | 137 | 0.75% |
| iOS 14.6 | 124 | 0.68% |
| iOS 9.3 | 92 | 0.51% |
| iOS 10.3 | 67 | 0.37% |
| iOS 14.3 | 32 | 0.18% |
| iOS 13.5 | 28 | 0.15% |
| iOS 14.2 | 28 | 0.15% |
| iOS 14.5 | 28 | 0.15% |
| iOS 13.3 | 27 | 0.15% |
| iOS 12.4 | 26 | 0.14% |
| iOS 14.0 | 20 | 0.11% |
| iOS 13.4 | 14 | 0.08% |
| iOS 13.6 | 11 | 0.06% |
| iOS 13.7 | 11 | 0.06% |
| iOS 14.1 | 11 | 0.06% |
| iOS 12.1 | 5 | 0.03% |
| iOS 12.3 | 5 | 0.03% |
| iOS 13.1 | 4 | 0.02% |
| iOS 13.2 | 3 | 0.02% |
| iOS 12.0 | 2 | 0.01% |
| iOS 12.2 | 1 | 0.01% |
| iOS 13.0 | 1 | 0.01% |
| Total | 18,161 | 100.00% |
The really only outlier there is the group of iOS 12.5 users with 630 downloads at 3.47%, that must be specific to some iphone/ipad model .
It's not like the few iOS 12 users can't use the app anymore, they just won't get updates.
Imho we have to draw the line at some point.
It's not like the few iOS 12 users can't use the app anymore, they just won't get updates.
Imho we have to draw the line at some point.
Precisely! Above statistics show that we still have downloads for iOS 9.3 while our current deployment target is iOS 12.0 I would therefore propose to follow the iOS releases: on every major iOS release we increment the deployment target.
I would say lets merge this and get it out with a minor revision bump, then go ahead an upgrade the target to IOS 13, and we can then start refactoring the code to utilize newer features.
I would therefore propose to follow the iOS releases: on every major iOS release we increment the deployment target.
Probably want to discuss this a bit to clarify how many previous versions we would support, last 3, last 2, etc...
Probably want to discuss this a bit to clarify how many previous versions we would support, last 3, last 2, etc...
I'd go with what makes sense, in this case 13 imho, as it offers a lot of nice frameworks and at least basic SwiftUI support. From my experience the next deployment target with major benefits would be 14.5.
If you're ok with it I'll make a PR targeting iOS 13.0 after this one has been merged?
I'd go with what makes sense, in this case 13 imho, as it offers a lot of nice frameworks and at least basic SwiftUI support. From my experience the next deployment target with major benefits would be 14.5.
If you're ok with it I'll make a PR targeting iOS 13.0 after this one has been merged?
Yeah, that sounds totally reasonable. We should probably open an issue to discuss and coordinate our ideas on refactoring targeting the IOS 13 SDK.
@timbms @weakfl I'm not sure how to promote a testflight build for review in the app store?
In AppStore -> Apps -> TestFlight -> iOS Builds -> Choose the build and click on "notify testers"
Right, but that is for test flight, but i did not see how to promote that build for general review in the app store. A little googling showed that under the "App Store" tab i needed to click "add version", add an arbitrary version string (i used the build version 2.4.54) and click ok. At this point it lets you select a test flight build. Having a button that says "submit for app store" in test flight would have made more sense to me, but oh well.
Can someone do a German translation for me?
- Improvements to network reachability logic
- Adds ability to clear web cache