(Apologies, I don’t have much detail because there isn’t anything in logs that I can tell and nothing happening visually)
I have a device that needs to support both Square and Stripe readers. I was running Square ReaderSDK v1.5.1 and Stripe Terminal SDK v2.0.0 and wanted to upgrade to v2.5.2. The issue arises after the upgrade when running startReaderSettingsAsync(). The Square modal pops up with the button to Connect a reader. Clicking on the button does nothing. No warning or info logs about anything broken, just nothing on screen, no swipe transition to the reader pairing screen.
We are also actively talking to Stripe devs to try and figure this out but I was curious if anyone here has heard of or run into a similar problem before?
Is there some check or prerequisite that occurs before the settings will navigate to the pairing screen?
This is with Android only. Sorry I’m a bit new to the Square dashboard, where can I find those other two pieces of info? (location_id and application id)
Click on + New Application (or click Open if you already have one, and skip the next step).
Name the application and click on Create Application .
By default, this should take you to the Credentials page of your application, where you can find the application ID. You can find your location_id by clicking the Locations link in the left navigation panel.
Need to bump this thread again; despite thinking the issue was resolved on Jan 24, turns out it wasn’t – we only saw the pairing modal appear ~5% of the time successfully. We split off to work on other projects, but are now revisiting this update.
I’ve subsequently been investigating the source of this issue, but wanted to loop you all in to see if you’d know if anything I’ve found has an obvious cause.
Some overall observations so far from my investigation:
No issue arises if we’re using Square Android SDK 1.4.4 w/ Stripe SDK 2.6 – however, we don’t want to (and can’t) downgrade from Square 1.5.1 to 1.4.4
Issues do arise as soon as we use Stripe SDK 2.2 w/ Square 1.5.1+
We’re using both SDKs through React Native (and use the square reader react native sdk); our app’s Java code is pretty minimal, and don’t ourselves have anything that obviously uses Kotlin (i.e.: our Gradle files don’t specify a Kotlin version). I only mention this as I believe we default build our app with the latest Kotlin version, though not entirely sure of this.
Looking at logs when we open up the initial Connect a Reader modal, one difference I saw in 1.5.1 that I didn’t see in 1.4.4 was a number of records of “dyr1026 : getActivityContext–>null”. More specifically, the logs show:
1.4.4 and 1.5.1: “dyr1026 : getActivityContext–>com.squareup.ui.main.ApiMainActivity@cf7de72”
1.4.4 and 1.5.1: “dyr1026 : getActivityContext–>com.squareup.ui.main.ApiMainActivity@cf7de72”
1.5.1 only: “dyr1026 : getActivityContext–>null” (shows up 4 times)
1.4.4 and 1.5.1: “1365 1457 I ActivityTaskManager: Displayed com.kiosk/com.squareup.ui.main.ApiMainActivity: +1s39ms”
We use Embrace for monitoring these devices, and noticed during this experimentation of getting ANRs, specifically in squareup.ui. Nothing super obvious came from the flame graph, though I did notice a lot of references to Kotlin Coroutines, and suspect that they’re related (considering 1.5.1 mentions conflict resolution with coroutines).
The few times (~5%) of times it does work, eventually the back button on the reader pairing modal doesn’t work (i.e.: go back and forth between the modal containing the “Connect a Device” button and the pairing modal itself).
My current hunch is that the Kotlin migration also involved something related to issuing activities with the ActivityTaskManager, but I admittedly don’t have much background with either React Native or Android. Would greatly appreciate your support on this!
If it’d be easier to connect outside of this board, can also chat on Slack (I’ll send a link to this post on the Square Dev Community Slack as well).
Yeah we did already the last time we attempted the update. Kevin mentioned it was resolved, but turns out he had hit the 5% case where the modal did show up. I can try it again, but very certain it’s the same set of issues on 1.5.5.
Now have a build with 1.5.5 and Stripe 2.6, and it does still happen, albeit it’s a bit better than before.
Before getting into some of the repros I’m finding, some product specific context of our app that’ll help in explaining the repros:
our “reader configuration” screen is the first thing that loads in our app. On that screen is a “Find a Device” button which, when clicked, loads the Square reader modal pairing.
once in the app, the only other avenue to our app’s reader configuration screen is via an admin panel that redirects back to it
Given that, the repros:
App Load → Our app’s “Find a Device” → Square Modal “Connect a Device”: Still doesn’t work consistently. Takes a few tries within app (i.e.: Close Square Modal → Click “Find a Device” to open modal again) for “Connect a Device” to move to the actual reader pairing screen.
Additional to above, eventually the Back Button from the actual reader pairing screen/modal to “Connect a Device” modal will just stop working, and end up stuck on the pairing screen.
If loading our reader config screen from the admin panel and opening the Square modal, it seems it works more often but inconsistently. Sometimes the initial modal works but the “Connect a Device” button doesn’t do anything, while other times it will navigate correctly to Square’s pairing screen.
Note, however, even in this case, sometimes the pairing screen’s back button will stop working.
I’ll take a look at our logs again under these circumstances; this is the first time it’s been “working”-ish within the same session. That said, would appreciate assistance on this one.
It seems like the “interference” theory would mean that Stripe and/or its dependencies is shadowing one or more of our classes (or our dependencies). Now that we know the version bumps did work, I would suggest pointing using our quickstart demo (which takes React out it) and add Stripe to that (including whatever initialization it needs) and see if it works or not. If not, then we have something small enough to work with.