#newtreyes
fluid marsh
dire raven
Please double check
Also, if we need to run it twice, can they run simultaneously?
Or do they need to run one after the other?
whole bramble
Yeah let me get you a 100% answer
dire raven
Thank you, Sir
sleek flower
you don't discover for Tap to Pay, right?
ah no I think I'm wrong, you do cause of the SCPDiscoveryMethodLocalMobile enum on DiscoveryConfig
so yeah cannot discover them at the same time and you'd have to do it serially, I don't think the SDK supports doing 2 discoveries in parallel
jaunty schooner
Hello again! You might be interested in this: https://stripe.dev/stripe-terminal-android/core/com.stripe.stripeterminal/-terminal/supports-readers-of-type.html
There's not really a reason to call discoverReaders twice like you're proposing.
dire raven
Well, what if we want to give our customers the opportunity to either use Tap to Pay or a Bluetooth reader?
We were thinking about allowing them to see ALL available readers and let them pick the right one if they have both of them.
jaunty schooner
Show them a UI that lets them select either, then run discoverReaders for the choice they make.
dire raven
Yeah... we won't be able to show them all in one UI
jaunty schooner
Why?
dire raven
that's one extra step in the process
They will have to pick either Tap to Pay or Bluetooth readers before actually scanning and showing them one type or the other
jaunty schooner
You can use supportsReadersOfType to determine if the device itself supports Tap to Pay, then run discoverReaders for bluetooth readers, then present a combined list of those choices.
If they select Tap to Pay then run discoverReaders for the Tap to Pay reader, which should return ~instantly with a single reader.
But there's no reason to run discoverReaders twice up front if you only have physical bluetooth readers.
dire raven
Correct me if wrong but supportsReadersOfType will only tell me if the device supports a specific type of reader (Ex. Tap to Pay). It won't give me the Reader required for connecting.
jaunty schooner
Correct.
That's why I said this:
If they select Tap to Pay then run discoverReaders for the Tap to Pay reader, which should return ~instantly with a single reader.
That's how you would get the Tap to Pay reader if they select that option.
jaunty schooner
You don't need to show more than a single option; a device isn't going to have multiple Tap to Pay readers built in.
And you only need to discover it if that's the selection the user makes.
dire raven
If they select Tap to Pay then run discoverReaders for the Tap to Pay reader, which should return ~instantly with a single reader.
But that means to discovery processes, correct?
One instant, one long running for Bluetooth
correct?
jaunty schooner
It only means two discovery processes if they make that selection. It avoids two discovery processes up front.