[Woo POS] UI: Reader connection presentation flow

[iamgabrielma]

The current app implementation of the card reader connection flow is through a series of modal alerts initialized through a common service provider. The specific modals for each stage of the connection flow conform to the CardPresentPaymentsModalViewModel interface, which are served through a CardReaderConnectionAlertsProviding implementation:

These need UIKit and Yosemite as dependencies, so we shouldn't just move them over, but a similar pattern could be used for the pos implementation, where we define a series of modal views that will be presented based on the observed connection state. At minimum we need:

• Searching for reader
• Found reader
• Connecting to reader
• Connected to reader

For the time being we can mock the different stages of the flow by forcing an update every x seconds. We should also be able to initialize the flow at any state from a testing perspective.

Handling the unhappy paths could be part of this issue, or tackled separately.

[dangermattic]

Thanks for reporting! 👍

[malinajirka]

@jaclync @joshheald Ignore me if you've already done this, but make sure to sync between each other. I noticed Josh is working on exploring our options on how to approach the card-reader section (pdfdoF-51h-p2 - ticket) and there is also this task which seems to be more code-oriented assigned to you @jaclync .

I'm all up for two devs working on the same section, actually I would even say I encourage it. But I just want to make sure we are not duplicating work or making decisions which are not easily reversible without a proper discussion.

Thanks 🙇

[joshheald]

@jaclync @joshheald Ignore me if you've already done this, but make sure to sync between each other.

I'm all up for two devs working on the same section, actually I would even say I encourage it. But I just want to make sure we are not duplicating work or making decisions which are not easily reversible without a proper discussion.

Thanks for the heads up @malinajirka, will do.

@jaclync In this case making connections actually may be a bit premature, as mentioned in the p2, because we haven't decided what payments code to reuse or how to reuse it yet – that's what I'm exploring.

If we use a mock as Gabriel mentioned, that can help us defer the decision, but that mock should probably be quite high level in this case, e.g. faking the whole card payment or connection, because having the POS manage its own connection might not even be desirable – from my exploration so far, I don't think it should have its own connection controller.

I'll try to keep across the tickets that are getting created to catch potential overlap as well.

[jaclync]

The goal of this issue that I'm taking on is to implement views for just the card reader connection flow based on the latest design. As we probably want to reuse the state machine that has a lot of complexity, I looked into how the reader connection works in the existing app and I think we can reuse the state machine with UI state as refactored and shared in #12723 / pdfdoF-51h-p2#comment-6122. I'm not looking at reusing other parts to achieve the payments, just the card reader connection.

Now that I know all the UI states in the card reader connection flow in the existing app, I'm working on the POS reader connection UI flow based on similar UI states.