Thanks @David Marginian. This is definitely one part of the problem. However there still is some undocumented expectation of some other state or expectation of delay. We see that if we call the .sale() immediately after onDeviceConnected, its still unreliably launches. We could launch the payment screen with 100% success only if we introduce a roughly 800ms delay after the onDeviceConnected is called. If we call it with less than 800 ms delay, it still has the unreliable behavior (most unreliable if less than 500ms). The waiting for onDeviceConnected is a precondition otherwise its success rate is non existant.
//Async Wait for device connected SystemClock.sleep(800); //800 seems to give apparent 100 % success rate. paymentConnector.sale(saleRequest);<br>
I can't reproduce the problem you are describing. I tried it around 20 times on both a Flex and a Mini and it worked every time. I am choosing "Read Card Data", which fires a sale (via your Activity), then I am canceling out of the sale and hitting "Read Card Data" again. My code is:
final IPaymentConnectorListener ccListener = new IPaymentConnectorListener() { ... public void onDeviceConnected() { runOnUiThread(new Runnable() { @Override public void run() { showMessage("SilverSky: PaymentLib Active & Ready!", Toast.LENGTH_SHORT); CheckLaunchOperation(); } }); } <br>
public void sale(final SaleRequest request) { try { if (request != null) { request.setVersion(2); // this version supports validation } if (paymentV3Connector != null) { if (paymentV3Connector.isConnected()) { paymentV3Connector.getService().sale(request); //***** Does not launch **** } else { this.paymentV3Connector.connect(); waitingTask = new AsyncTask() { @Override protected Object doInBackground(Object[] params) { try { paymentV3Connector.getService().sale(request); //***** Does launch **** } catch (RemoteException e) { Log.e(this.getClass().getSimpleName(), " sale", e); } return null; }
@David Marginian - We were also able to reproduce this issue when we moved our simplified implementation to native-android-example-pos example. We have sent a patch that will reproduce this to semi-integrations@clover.com. Please let me know if you able to access the patch.
I ran your example and was able to reproduce the behavior you describe. However, I also saw a warning in the logcat - "Skipped 181 frames! The application may be doing too much work on its main thread". I didn't look at your code much, but it looks like you may have a problem:
D/InputTransport(12285): Input channel constructed: name='424ab660 com.clover.example/com.clover.example.CloverPaymentActivity (client)', fd=60 I/Choreographer(12285): Skipped 181 frames! The application may be doing too much work on its main thread. D/ (12285): onServiceConnected com.clover.connector.sdk.v3.PaymentV3Connector@422e7c60 D/ (12285): appTracking = {"developerAppId":null,"applicationVersion":"1.0","sourceSDKVersion":"1.4.0","sourceSDK":"com.clover.connector.sdk.v3.PaymentConnector","applicationID":"com.clover.example"}
It could be as we are connecting to payment, order, display connectors? But skipped frames itself can't block the clover payment screen right?
I got the patch, hopefully I can take a look next week.
1 Person is following this question.