iOS Seeking Architecture Advice: A Shared Countdown Timer View

[dejo]

Okay, I'm going to put on my humility cap and ask for help from any big brain iOS developers out there who are willing to provide it.

Here's my situation: I have a countdown timer that I need to show as a subview as the user makes their way through the some purchase screens (nothing to do with IAP, mind you). If the timer expires before they are finished, each screen will need to do something slightly different in order to "cancel" the purchase.

So, what would be a good way to architect a solution?

I'm definitely thinking about setting up a protocol and delegate methods to respond to the timer-expiration. And then probably a singleton to hold onto the UIView subclass I'm putting together so that each screen can add it as a subview. The subclass would be responsible for counting down and updating the display. Or do I not share the view and just have some model-backed timer that instances of the view would work with? Or some other approach that would make more sense?

Thoughts, comments, suggestions?

Thanks in advance for any advice.

 

[Sykte]

Okay, I'm going to put on my humility cap and ask for help from any big brain iOS developers out there who are willing to provide it.

Here's my situation: I have a countdown timer that I need to show as a subview as the user makes their way through the some purchase screens (nothing to do with IAP, mind you). If the timer expires before they are finished, each screen will need to do something slightly different in order to "cancel" the purchase.

So, what would be a good way to architect a solution?

I'm definitely thinking about setting up a protocol and delegate methods to respond to the timer-expiration. And then probably a singleton to hold onto the UIView subclass I'm putting together so that each screen can add it as a subview. The subclass would be responsible for counting down and updating the display. Or do I not share the view and just have some model-backed timer that instances of the view would work with? Or some other approach that would make more sense?

Thoughts, comments, suggestions?

Thanks in advance for any advice.

Far from a big brain here but I know from personal experience kicking around ideas even if they are not ideal can help. What about skipping the delegate and going for notifications/blocks. It screen could register and handle their own expiration. This would allow for multiple screens down the road if that would ever be applicable.

 

[jnoxx]

I'd go for a SharedInstance of a Singleton, and then opt for NSNotificationCenter, to set all your views which need the notification to listen to the listener, that way you know for sure that every screen gets it.
Just a thought from another programmer

 

[chown33]

And then probably a singleton to hold onto the UIView subclass I'm putting together so that each screen can add it as a subview.

This seems like a bad idea. What do you hope to gain by sharing a subview?

No subview is shared when it's in use. It has at most a single superview. So if you share it by inserting it, it's removed from other views. What could the consequences of that be?

If the goal is to have code build the timer-view once, simply put that code in a factory method. Anyone who wants a timer-view calls that factory method. The returned view belongs to the caller. They can do what they want with it, which includes inserting it in another view, without regard to any other view or controller.

Each view built by the factory method has the same model timer object. That way all the views show the same state.

As to the timeout, a notification seems fine. It originates in the model, not the views. It can have any number of listeners, each of whom is responsible for their own actions when expiration is reached. It should be illegal to add a listener after the time has expired. Or if it's legal, there should be an immediate notification to the listener that the timeout expired.

 

[MattInOz]

Couldn't you take a leaf out of the Undo system?

So instead of each view know how to cancel. Each step as it does itself but also creates the reversing step as an NSInvocation and adds to a stack*. If the timer triggers it would only need to then process the items in the stack to cancel the purchase. Also if the user wants to back up you just pull out the items and run those for each step the user backs up.

*sorry if stack is the wrong word here.

 

[dejo]

Thanks Sykte, jnoxx, chown33 and MattInOz for your feedback.

I guess sharing the subview isn't a great idea (which I kinda suspected). Yes, the goal is to only build the timer-view once, so I will look at creating a factory method for it.

I'll let you all know what I end up with.