When running either a Robo Script Recorder or Espresso Test Recorder, when clicking on a custom view, the click action is not being recorded. I've checked to make sure that the custom onTouchListener is calling performClick() when Action.UP is called. Is there something else that needs to be done as well to make sure the recorders pickup the click actions from custom views?
For those that might run into this issue in the future, if you have a custom OnTouchListener that is being assigned to the view, make sure that the listener doesn't consume the event (i.e. return true). It should always return false. Also if you call performClick() as part of the ACTION_UP, make sure you break out of the switch for this case and not let it fall through to the bottom if you have another action case to be handled after it.
If you consume the events, then you interrupt the PerformClick#run() flow for the view, and th Espresso Recorder and Robo Script recorders can not register the events.
This information came from the Firebase Slack channel.
Related
I'm looking for some help with regards to the drop-in checkout integration.
https://developer-eu.elavon.com/docs/opayo/integrate-our-drop-checkout
In particular I'm following ‘custom flow’ example - see first code example for the Custom Flow section. https://developer-eu.elavon.com/docs/opayo/spec/api-reference#section/Custom-flow
In summary how can I programmatically determine if the sagepay 'card details' form which is injected into the sp-container (hosted in an iframe) is not valid for submission/tokenisation, when a call ‘tokenise’ link is used?
For example when the user has not completed all the required fields; Name, Card Number, Expiry or CVC.
I'm following the flow calling sagepayCheckout.tokenise() when the user clicks our 'Complete Payment' button (referred to as the tokenise link in the custom flow example).
NB: Implementation is part of a SPA app in my particular case I'm not submitting the (outer) form rather handling things using javascipt and calling the tokenise method.
Normally the onTokenise call back method is called on success or when wrong card details have been entered or merchantKey has expired. But when the injected sagepay form fails its own validity the onTokenise call back is never called.
NB: Due to browser security I can't check the state of the fields inside the iframe.
Ok some good points to note:
The sagepay form does feedback to the user about errors that required fields need to be completed.
And sagepayCheckout.tokenise() doesn't try to submit my (outer) form when these errors exist.
But there doesn't seem to be a programmatic way to know if the required fields need to be complete (or the onTokenise call back wont be called).
The main reason I need to know when the form is incompleted or tokenise has failed would be to re-enable our 'Complete Payment' button. Currently our button is disabled as soon as the user clicks it to prevent multiple clicks.
I am having this exact same problem. The only way I have been able to think of to get around this is to use the message event listener on the window. The sagepay.js library registers a 'message' event on the window object probably when the sagepayCheckout method is called.
Side note: this method is also poorly implemented as anything else that uses the window message event will cause the sagpay.js library to throw errors.
I think the only purpose of sagepay.js' message event hander is to resize the iframe window when its content changes. If you were to assume the content of the iframe will only change when validation fails you might be able use that to reset the state of your 'Complete Payment' button.
I would also suggest making a complaint to Opayo. This library is clunky and in desperate need of improvement.
I'm having a problem where when I click on submit in a dialog box the resolve event on the dialog box is supposed to call a function. The dialog closes when the button is click but the api function is never called (as seen from dev tools). If I stop the tests and manually do the action in the cypress browser it will work call the function. I'm not sure why the manual click is acting different than the test runners click?
Sometimes you need a hard ms wait(should be avoided)...
You may have a wait issue. Add a cy.wait(1000) 1000ms hard wait and see if that fixes it. If it does, you will want to identify what hasn't loaded fully when the button is pressed. While hard waits should be strongly avoided, I find myself using them sparingly with the smallest amount of milliseconds(x2 for safety) that I can get by with. Animations are one such example that comes to mind.
Make sure all subscriptions are ready
I am working on a meteor app that using websockets(tricker to wait on than xhr events). I call a method that returns true/false for all subscriptions. This helps wait for any events that cypress doesn't see in the network layer. Ask your devs if there is a method in your application that returns true/false depending on the ready state of the application.
Review for Race condition
This could be a legitimate race condition. I would review it with the devs just in case.
I have a Finder Sync Extension that will display a badge on a file based on the state of a local database. It's straightforward enough to query this database in the requestBadgeIdentifierForURL function, but what if I want the badge to change for a Finder item that's already visible if the state of that database has changed (which can be via a notification through any variety of mechanisms). The documentation (https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Finder.html) would seem to imply this is possible with this statement:
You might also want to track these URLs, in order to update their
badges whenever their state changes.
The only ways I can imagine this would be possible (and most seem wrong) would be:
call setBadgeIdentifier:forURL from another application that is aware of the change
Launch a thread in the init function of my extension which listens for notifications and calls setBadgeIdentifier:forURL when it receives them
Call some OS API that prompts Finder that the extension should be triggered via requestBadgeIdentifierForURL.
Only the last one seems feasible, and could be managed via the extension informing the outside resource what needs refreshing via the beginObservingDirectoryAtURL/endObservingDirectoryAtURL callbacks, but i don't know what mechanism could do this.
is there any way to handle the Windows button keypress within the *.Xaml.cs especially when the app is busy getting a request processed using an Asynchronous BeginGetResponse. is there a override handler like OnBackKeyPress?
What's the appropriate way to handle this use case? i'm already handling Application_Activated and deactivated in the App.Xaml.cs file for tombstoning.
You can't stop this from happening. When this happens the current page will get its OnNavigatedFrom override called so you could clean up your page and save state from this method.
Bear in mind that it won't be possible to tell whether this is due to the hardware Start key or if the user just navigated away by say pressing the Back key or tapping a button.
Update:
If you're trying to avoid a crash due to Fast App Switching interrupting your networking call you should rather handle this when you return to the application. Your WebRequest will be cancelled and you should handle this case as shown in this MSDN blog post.
Is it possible to stop the back button from working during a data call? For instance, when registering, I don't want someone to press the back button otherwise they may register for my service and not know it (other than confirmation email)? (And the registration will fail the next time they try)
Handle the BackKeyPress event or override the OnBackKeyPress method in your page class, and then set e.Handled = true; when you want to prevent backwards navigation.
Note that if you do this, then you should provide the user with a way to cancel your long-running process so they can back out if they want to.
Please note that if you stop the Back button from working your application will fail marketplace submission.
See section 5.2.4 Use of Back Button.
If a user has the situation where they try to reregister (becuase they don't realise they have registered previously) then you should handle this in your app as the situation may come up anyway.