Repository navigation
New protocol for displaying Siesta related UI to the user #265
Description
I have a bug in my code (not Siesta!) where I am not properly handling all the cases that a ResourceEvent can return, and it got me to thinking. Since I'm using this code to show and hide a spinner, and potentially an error result, I looked at ResourceStatusOverlay, which is doing almost the same thing. However, I want to use the spinner that the rest of my app uses, which takes care of its own rotation and other view related issues, and I want any errors to use a different class.
It seems like the proper thing to do is to split ResourceStatusOverlay into a protocol and implementing class. The protocol would have default implementations for the Siesta specific methods, leaving the display-related methods for a class to implement. Do you think this is the right approach, @pcantrell?
Activity
pcantrell commentedon Sep 23, 2018
Belated reply: yes, I like this idea, and have thought along similar lines in the past but never did anything about it.
One could split out just the logic pieces — i.e. no UIKit dependencies, but just
observedResources,displayPriorityand friends — and then have a protocol withshowLoadingetc. thatResourceStatusOverlay(and custom resource state indicator views) would implement. Is that more or less what you're thinking?I haven't thought much beyond what I typed above. If you want to investigate and take a crack at it, go for it!