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.
Related
When user opens Outlook email item, my Outlook add-in creates an new Inspector in Outlook.Inspectors collection. To fill out Inspector form region user controls, few long running async DB calls are called. Generally, user can close email/Inspector window at any time while the async calls are running. The problem is the form region Close event occurs before async call completion. As a result, when async call is completed, my Inspector code tries to update form region user control but, by this moment, the control is null and disposed in form region Close event. Hence, null reference exception is thrown.
I added some code in Inspector Close event where I set up an ad-hoc flag indicating that Inspector is closed. The flag value is checked up in a catch(NullReferenceException) block. If flag shows that email is closed, the null reference exception is ignored and a new OperationCancelledException is thrown to cancel other related running async calls. Although the code works, I am not sure that this is the best approach to handle the error this way. Firstly, although the flag indicates that email is closed, the null reference exception might not be neccessary related to disposed UI user control. Secondly, I need to add catch(NullRefernceException) block to try-catch block in all relevant methods.
If you've had a similar problem, would you be able to advise your solution, please?
Thank you.
Instead of throwing and handling exceptions, I'd recommend keeping a dictionary of opened items, so you could easily detect whether a particular window is still opened. For example, you may develop an inspector wrapper - see Implement a wrapper for inspectors and track item-level events in each inspector.
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'm making a app with using XF PCL.
I started to doubt that XF's timer is not good enough for UI routine.
for example, in iOS native app, If View is not showing some reason (new page's pushed or something), scheduler is stopped automatically. Because it's for UI.
But Xamarin's doesn't seem like that.
It's still doing his job.
I hope at least within "Device.BeginInvokeOnMainThread(() =>" will be skipped when it's disappeared.
Am I right?
Should I put extra logic for that?
(like stop and restart timer?)
(or declare variable to skip in it?)
Thanks.
In Andriod usually when you are in Page1 and then you navigated to Page2, although Page1 is hidden it is not killed therefore the worker threads would still working (in that case it is the timer)
My suggestion is to override the OnDisappearing method in the code behind of Page1 and place the code that would make the timer stop or being ignored.
If it is for me , I would also place a boolean flag and called _isPageShown so when you override OnDisappearing and OnAppearing you just put the value of _isPageShown to false or true accordingly. Then in the callback of the timer you check the flag if it is true or false and act accordingly.
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.
I have a Mac OS X application that is also a protocol handler (just as, for example, Safari is a protocol handler for the HTTP and HTTPS protocols). So when a user clicks a link of the form myscheme://some-kind-of-info in any application at all, my application launches to handle the link.
Now I need to be able to determine if the application was launched by such a link click, or if it was launched by any other method. In other words, it was launched by any method besides a link click. (In those cases, I want the app to stay open, but if it was launched by a link it should quit and ignore the link. This way it only operates when already running.)
Is there some way within the app at startup to introspect and find out that it was launched by a standard method rather than by an AppleScript GetURL event? I'd like to find out through a documented method, rather than - for example - just have my app only open these links after it's been running for a half a second.
You can register a handler for each of the possible Apple Events you'll get on launch, and make note of which one you receive first.
If the application is launched without documents, you'll get kAEOpenApplication.
If it's launched with documents, you'll get kAEOpenDocuments (or
kAEPrintDocuments).
If it's launched with a URL, then (obviously) you'll get kAEGetURL.
There's also kAEOpenContents, but I wasn't able to trigger it easily in my test app; it's probably worth supporting no matter what.
How Cocoa Applications Handle Apple Events documents all of this stuff.
There is one error in there, though; it says that AppleScript's "launch" will send kAEOpenApplication. It won't, it'll send ascr/noop (kASAppleScriptSuite/kASLaunchEvent, defined in ASRegistry.h). I couldn't get the usual Cocoa event handler mechanism to trap this event, so you may need to do some more digging there.
One way you can check if the event is sent at launch is to register the event handlers in your application delegate's applicationWillFinishLaunching: method; they should deliver by the time applicationDidFinishLaunching: is invoked. With that method, you could potentially only check for kAEGetURL.