-
-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New protocol for displaying Siesta related UI to the user #265
Comments
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 I haven't thought much beyond what I typed above. If you want to investigate and take a crack at it, go for it! |
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 atResourceStatusOverlay
, 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?The text was updated successfully, but these errors were encountered: