Small Mistakes....
Duncan James-Bell • Apr 11, 2020
I made a small error in setting up WWYS and I've only just worked it out!
WWYS is mainly written using SwiftUI. However there were quite a few gaps in SwiftUI when I started out. It was not clear how to get a set of Pages to work as SwiftUI doesn't provide a PageViewController. (I realise I could have written one, but that was slightly beyond me and not my focus when I started. Plus I still think it likely Apple will provide a standard control in the next version of WatchOS)
Anyway the way I set it up was to use a WKHostingViewController around each "Page" view and launch a set of pages using the reloadRootPageControllers, which I put inside applicationDidBecomeActive(). At some point a realised that one of the stability issues I was having meant this should have been out a DispatchQueue.main.async block, and that's how its worked ever since....
Coming to todays issue I had been aware for a while that every time you leave WWYS, next time to go back to it you are forced back to the top level. Most of the time this would probably be correct behaviour; if the app is left for prolonged periods then starting at the opening screen is more than likely what the user desires and expects. But if you are in the middle of entering a new Expense it definitely is not. Unfortunately this happens quite frequently to me as I get a notification of a contactless payment shortly after its made and usually whilst I'm in the middle of creating the Expense in WWYS!
I started work on looking at solving this problem by saving UI state so that on return the app could resume correctly. This turned out to be very complex as WatchOS doesn't provide the same framework as iOS and as I am using a mixture of SwiftUI and WatchKit, its much harder to roll your own solution. It was whilst I was tracing through the API calls of SwiftUI and WatchKit when you exit WWYS in every use case I could think of, that I noticed that of course applicationDidBecomeActive() is triggered EVERY time the app becomes active, even if the App has not been closed bu WatchOS. Hence all I had to do to solve the bug was move the reload out of this method...duh. I don't need to store UI state at all - just wish I could now get back the 4 evenings this week I've spent puzzling over this problem.
Duncan's Blog
After the disappointment of any better messaging API this year, I've been experimenting with better ways to export the data from the watch. In the end I decided the best way forwards was to bite the bullet and sync data to iCloud and write a dedicated iPhone App. The move to iCloud data storage has taken quite a lot of work because changing the data schema in the future becomes harder, so I first of all had to bring forward other features such as multiple account support that impact the data schema. So I am going to do this in two stages. Firstly the next version will come with multiple account support and iCloud data sync, then at a later data an iPhone App to improve data export. I've just completed my first beta version for WatchOS, but its such a big change that I will need to road test it for a few weeks before getting ready to release. I also need to update all the instructions on this web site as its a big change to the overall structure and flow for quite a few use cases. If anyone wants to help out with beta testing please get in touch!
WWDC has been a mixed bag in relation to WWYS. I had really hoped for more message API support on the Apple Watch so I could improve export to use iMessage or email, but unfortunately I can't find anything that might assist. On the other hand SwiftUI has made some big improvements on what is possible. This leaves a dilemma; WWYS was always intended to be based on SwiftUI as being the best way to have a good WatchOS only app, the the reality of the current implementation is that quite a bit of the "Outer Shell" had to be built with WatckKit. In the new WatchOS 7 this would no longer be the case, but removing and porting to full SwiftUI would make it very hard to be backwards compatible with Watch OS 6. Having given it some thought I've decided that my approach will be to first update the current App so that it better aligns with WatchOS 7 during the beta period, using its current architecture in a WatchOS 6 backwards compatible way. This is to support anyone on the beta program and ensure WWYS keeps working. In parallel a WatchOS 7 only port will take place to release as shortly after the official WatchOS 7 release as possible. At this point I will drop WatchOS 6 compatibility and so users will need to upgrade to keep up to date with new versions. However, this will be preceded by a final WatchOS 6 release that is backwards compatible.
