#demodian_api
scenic sirenBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1404877484956188762
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- demodian_api, 20 hours ago, 72 messages
- demodian_react-native-terminal, 4 days ago, 105 messages
- demodian_terminal-update, 5 days ago, 21 messages
digital horizon
i know it's kind of a stupid question, but considering i WANT to cancel Discovery, why is it a user error?
solemn gust
hello! acknowledging your question and will get back to you asap!
digital horizon
sure
solemn gust
to be completely honest i don't know off the top of my head why it's defined as an error, but i can dig around to see if i can find historical context on it
digital horizon
i cannot even see in the sdk source how the message is even fabricated...
and there's only one reference to USER_ERROR in the source for the sdk
and that is in dev-app/src/screens/DiscoverReadersScreen.tsx
(beta-26 btw)
i've searched the source for any error messages, but zilch for "DiscoverReaders was canceled by the user."
must be magic or something
solemn gust
are you running this on android?
digital horizon
yes. have not gotten to iOS yet
solemn gust
ok cool, i can see that error string in our internal android SDK codebase so it looks like that's where it's coming from at least
just checking, is this blocking anything for you? or are you mostly just wondering why we're calling it an error
digital horizon
wondering why it's popping up as an error condition and not a regular log level
because with RN/Expo I get an annoying banner at the bottom of the screen that requires extra dismissal. If I actually have an await cancelDiscovering(), I do not want the error level notice
and i guess a followup would be: does timeout actually work when starting a discovery process?
(otherwise, discovery keeps going without ending, it seems in my observation, unless i explicitly cancel it)
solemn gust
can you explain what you mean by your last question? are you setting a timeout and calling cancelDiscovering after that?
(spinning up my own test app at the moment so i can double check some things)
digital horizon
i disabled (commented out timeout) to run the test that prior support asked me to implement when I was just trying to test connecting (by connecting to the first reader found when discovering, which is not the final behavior that I want)
i wanted discovery to timeout after 15 seconds when started. when our app is used at an event location for POS duty, there may be multiple readers present, so the user needs to launch discovery, let it find the list of available readers, and allow the user to select theirs from the list (and not grab the first one automatically like in the test)
which means we need discovery to actually stop somehow (either automatically after some time or if i call cancelDiscovering() without an error)
solemn gust
hmm yeah i don't think there will be a way to stop it from throwing an error period, i would probably just set up a handler for that error case in your app
it should also stop discovery once you connect to a reader
also fyi i have to step away for just a couple minutes but i'll be back soon!
digital horizon
that's fine and dandy, but if they didn't have the reader close enough when they started, i don't want to say "nothing found, so restart the app to try discovering again"
solemn gust
hmm, you shouldn't need to restart the app entirely, you can also just restart discovery
digital horizon
without canceling the discovery, if I try to restart it, it will complain about being busy discovering
solemn gust
i feel like i'm missing something so let me take a quick step back to make sure we're on the same page
in my test app i have separate buttons - discover readers, cancel discovery, connect to [any of a list of readers], disconnect from reader, etc. i can do all of these without needing to restart the app.
are you saying that in your app if you cancel discovery you need to restart the app entirely?
digital horizon
i do not have a cancel discovery button (screen real estate)
discovery is started with:
const { error } = await discoverReaders({
discoveryMethod: discovery,
simulated: false,
//timeout: 15000,
});
solemn gust
makes sense, but in effect my cancel button is just doing what your timeout is doing. do you have an error handler for your discoverReaders call?
digital horizon
discovery is usually 'bluetoothScan'
I wait until I receive a onUpdateDiscoveredReaders with the reader list
I save the list for a drop-down component. i also initiate cancelDiscovering()
the user will then open the drop-down list and select their desired reader
if the reader is not in the list, they have to start the discovery again once they make sure the reader is close by and powered on. they will have to hit the discovery button again.
at that point, if I haven't already canceled discovery, if it is still running, i get an error saying that the sdk is busy discovering. things usually get stupid after that which means i would have to restart the app for testing, so cancelDiscovering() is important to be called without generating an error (thus my original question of why it needs to be an error and not a notice)
(either that or i'd really like to use timeout)
solemn gust
makes sense. i am still unsure of exactly why it's being handled as an error, but i am still confused as to why the cancellation being an error is an issue for your app. for example if you're doing something like this:
// The list of discovered readers is reported in the `onUpdateDiscoveredReaders` method
// within the `useStripeTerminal` hook.
const { error } = await discoverReaders({
discoveryMethod: 'bluetoothScan',
simulated: true,
});
if (error) {
Alert.alert(
'Discover readers error: ',
`${error.code}, ${error.message}`
);
}
};```
the error handler will just display a notice that discovery was cancelledI started this app while the sdk was beta-25, but it's updated to beta-26 currently, so i'm not sure if the current version will actually timeout okay. it was hit or miss with 25...
i'm getting this red-flagged message with the cancelDiscovering():
(NOBRIDGE) ERROR Reader discovery error: {"code": "USER_ERROR.CANCELED", "message": "DiscoverReaders was canceled by the user."}
without the cancel, I get:
(NOBRIDGE) ERROR Reader discovery error: {"code": "READER_ERROR.READER_BUSY", "message": "Could not execute discoverReaders because the SDK is busy with another command: discoverReaders."}
that would happen if they hit the button a second time without trying to connect to the reader
i'd rather not require another button to stop discovering, because people using this will not be the brightest of individuals, so keeping it as automated as possible will be ideal
plus the app has a feature that once you select a specific reader, it will try to automatically reconnect on app startup to the last known reader in the background
so they do not have to re-select it every time the app is used
solemn gust
i did just run a quick test and it looks like timeout is in seconds, so that might be why you're not seeing that work
but it's worth noting that the timeout still throws an error, so your app will still need to handle that
digital horizon
that is an important detail... ugh. thought it was milliseconds like everything else javascript
how best to do catch that then?
solemn gust
(just for the record i was also confused by this đ )
solemn gust
makes sense. i am still unsure of exactly why it's being handled as an error, bu...
this example catches it appropriately
i think the example code in the docs does too, you just need to set up an if (error) handler in your function where you're calling discoverReaders
digital horizon
this is mine:
const handleDiscoverReaders = async () => {
const locationid = getAppdata('locationid');
if(locationid === '') {
Alert.alert("Warning!", "You must select a location before discovering readers.");
return;
}
if(discoveryRunning)
await cancelDiscovering();
try {
// Discover readers
setDiscoveryRunning(true);
const { error } = await discoverReaders({
discoveryMethod: discovery,
simulated: false,
timeout: 15, // in seconds
});
if(error)
console.error("Reader discovery error:", error);
setDiscoveryRunning(false);
} catch(e) {
console.error("An unexpected error occurred:", e);
setDiscoveryRunning(false);
}
};
using the uncommented timeout now that I know it is seconds
solemn gust
are you hitting that console.error("Reader discovery error:", error); line? if so you would just take whatever action you want here (probably just displaying a little notice to the user that the discovery timed out)
digital horizon
testing now. (another caveat: RN/Expo sucks on restarting testing on an actual device without restarting expo entirely)
so yes, it's me throwing the error because of the cancel. removing it to see what a timeout does
and that's a new error that i can see for the timeout
but now the connectReader isn't returning... hrm
will it connect if the reader is charging?
solemn gust
it should still connect if it's charging, yes
as long as the reader is on
also silly question but is there a reason why this line isn't wrapping the console log in curly brackets?
console.error("Reader discovery error:", error);
setDiscoveryRunning(false);```because i abhor unnecessary braces (personal preference)
i write the code for myself
solemn gust
haha fair
digital horizon
cool, i got the reader connected.
solemn gust
i'm realizing i wasn't quite following, is it hitting that console.error line as expected?
it sounds like yes
digital horizon
yes
scenic sirenBOT
digital horizon
now to check if the app restart actually auto-connects to the reader
it does if i tell expo to restart metro. now checking from a clean (force stop)
nope, gotta debug that automatic discovery
but that's my code
digital horizon
yeah
solemn gust
awesome! sorry it took us a bit to get there
digital horizon
thanks for the assist
solemn gust
of course!
digital horizon
maybe the docs can make sure the timeout is listed as seconds, i never saw where it was such, so dealing with javascript, i made the (wrong) assumption for milliseconds
solemn gust
yeah i agree, that part is very confusing. i will submit an update request to our team that manages the SDKs
digital horizon
great. fyi, i've been dealing with this app project for the past 4-ish months. i've really come to hate RN... lol... the Stripe integration was pretty much the last major component, so now it's just cleanup
solemn gust
yep! i think i've actually worked with you in the channel before (can't remember if it was RN specific though)
that's good to hear that you're nearing the end though!
solemn gust
â¨
digital horizon
anyhow, i'm good as far as the original issue
solemn gust
sounds good! do you need anything else at the moment?
digital horizon
nope. all done
solemn gust
i need to go grab lunch but i can try to find someone else to step in if so
digital horizon
same