question

Dan avatar image
Dan asked Jeffrey Blattman commented

Broadcast receiver on Flex behaves differently to C100/C300 - timing issue

We have code running fine on Clover Kitkat / Jellybean devices which launches our app within the 'payment processed' broadcast intent under certain conditions. I am trying now on the Flex, and although the broadcast is received, when I call `startActivity()`, it does not launch and instead sits underneath the Sale app. I know it's underneath the Sale app waiting to be created because backing out of the Sale app does indeed create our activity.

After calling startActivity();, we get the following system log, and then nothing:
`I/Timeline: Timeline: Activity_launch_request id:com.example.package time:9886254`

Another thing to note is the app works perfectly if I am running in debug mode, so this is some kind of timing issue.

I can't see if there was some Platform change with Lollipop that is causing this or if the Sale app on the Flex is behaving differently to the other devices. (perhaps aggressively reordering itself to the front when a payment is processed). What would you recommend we do?

Here is the code that launches our app from the broadcast:
@Override
public void onReceive(Context context, Intent intent) {
//...
Intent transactionIntent = new Intent(context, TransactionActivity.class);
transactionIntent.putExtra(Constants.Extras.EXTRA_CLOVER_ORDER_ID, orderId);
transactionIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);
context.startActivity(transactionIntent);
}
PaymentsClover FlexBroadcasts
9 comments
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

I'm not able to reproduce on my test app. I'm seeing the same behavior on Mini and Flex. What conditions do you decide to launch your app?

0 Likes 0 ·

Haha Miguel I know it is nearly one year later but this is actually still and issue for me. We abandoned Flex back then but are looking again. I'm going to try and make a reproducible sample. To answer your very old reply, our app launches when a payment is received with the payment manifest filter: "com.clover.intent.action.PAYMENT_PROCESSED"

0 Likes 0 ·

@Dan can you provide a MCVE (https://stackoverflow.com/help/mcve) that reproduces the problem?

0 Likes 0 ·
Show more comments

@Dan

Wondering if you can help me with my Emulator setup (Flex).
I cant seem to get API 22 to install all the apps
When I use 21 (KitKat) everything seems to work fine accept the order app crashes because its not sending the right token in the REST request.
I'm at a loss lol.
Thanks

Matt

0 Likes 0 ·

Sorry I can't help Matt, it seemed to just work for me on the emulator:

0 Likes 0 ·
capture.png (29.9 KiB)

Did you use the sandbox apks provided here:

0 Likes 0 ·
Show more comments

1 Answer

Jeffrey Blattman avatar image
Jeffrey Blattman answered Jeffrey Blattman commented
I got your sample, thanks. It is indeed a timing issue. Here's what's happening,

1. Sale transaction completes and it broadcasts PAYMENT_PROCESSED
2. Your receiver is called and starts your activity
3. Sale starts its receipt activity on top of your activity.

There are two completely separate processes calling start activity: yours and Sale. One or the other is going to win. Android doesn't say anything about the ordering of such events.

It's not clear to me what you are trying to accomplish. Sale has a mechanism for custom tenders. You don't need to try and insert screens in the flow like this, just use the custom tender mechanism.
2 comments
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks Jeff, I didn't realize we were both calling startActivity() and conflicting with each other like that. So really the only use case is to allow customers to collect a loyalty bonus (or merchants to load a gift card) based on the Sale amount when there is no concept of a LineItem.

If we immediately perform the transaction instead of intercepting a payment, the cashier can fraud their employer by just closing the Sale app and not putting through a traceable payment. Or, they could accidentally forget and walk away from the device. They have done both of these things to us :) and the result is a lot of top-ups with no matching amounts in Clover's reporting.

Tender redemption is not a problem here because setting an amount and finishing after a custom tender launch creates a traceable Clover payment.

So if intercepting payments like this is not a good solution, do you have any others or do you think this is a loop hole in the Sale app?

0 Likes 0 ·

Let me make sure I understand. You want to put up a screen that allows the merchant to load say a gift card inline with the sale of the giftcard itself. And the concern is that employees will load the giftcard, but not complete the sale. So you let the sale complete normally but ALSO throw up your screen to do the load. Is that right?

To be honest we've had the same issues with our giftcard app. It's a damned if you do... type of situation. If you load the card first, then people "forget" to pay for the load. If you load the card after, people forget to load the card at all and the customer walks out with a dead card.

Could you load after, and use ACTION_CLOVER_PAY to make a payment and get a result back, and then load based on that?

Could you load first, and record the employee that did the load? At least then there'd be a record of who "forgot" to pay for the load.

0 Likes 0 ·

Welcome to the
Clover Developer Community