New protocol for displaying Siesta related UI to the user

[jordanpwood]

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?

[pcantrell]

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, displayPriority and friends — and then have a protocol with showLoading etc. that ResourceStatusOverlay (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!