I am new to WP8 Aync tasks and have a query-
In WP8, on backbutton press, since it basically pops the last screen from the stack, then why are the Async tasks not cancelled when back key is pressed?
Also, if I am using the HttpWebRequest response, is using Abort() the only way of cancelling the async tasks?
The reason is because Back is a UI concept but things like networking are typically decoupled from the UI. As an example, imagine the user hit "Save" in an app and that started a web request to send their data to the cloud. Then they hit the Back button to go back to the previous page; it would be unexpected for the web request to be aborted and the data to potentially not be saved.
If you have a need to stop tasks when your UI changes (eg, because of resource consumption concerns) then you can try to do that, but I have a vague recollection that Abort is a no-op for Windows Phone 8 (but I could be wrong).
Related
I have implemented Fast resume in my windows phone 8 app and its working fine in every case except following scenario.
Steps:
1)Phone is password locked
2)Toast is received.
3)Tap on toast.
4)App is activated.
5)The page which was last on backstack opens up with reset state.
6)No more navigation
In Fast Resume app should receive one more navigation with deep link on tapping on toast which is missing in this case.
Please find sample here.
This feature of Windows Phone. If the reminder or toast to send from your lock screen (even without a password), the navigation application is limited. I think that there is no way now to fix this behavior ...
I got even more unpleasant situation with reminders of the applications:
1) If screen is not locked and you gave a reminder of the application, then click on the reminder will open the application, you can immediately take action in response to the reminder. All well and good.
2) when the lock screen (even without a password) and you send a reminder of your application, there is no ability to navigate the application by clicking the reminder. Reminder, you can only cancel or postpone for a while. Then the user must unlock the screen, open the program and try to understand what to do in response to this reminder.
At least toast is displayed in the notification center, and the reminder disappears without a trace and the user attempts to find what caused the reminder.
I do not understand why such inconvenient behavior for user application communicates with the lock screen.
Wrote a post on UserVoise, but without response.
Enable to open a task or an appointment directly by tap on the reminder
In my application hitting service call on every page navigation and showing MessageDialog to user.
My problem was when I hitting service call (await) on page navigation "Page1" to "Page2" whereas service call taking certain time to complete meantime user taps back to "Page1"
In that case user seeing "Page1" and await service call completed on "Page2" and showing that service response message in "Page1".
How can I avoid MessageDialog suppose user navigates back from that page.
First of all, you should avoid using MessageDialogs for this sort of information. You should think about using a ProgressBar or ring to indicate that your app is performing a task in the background (calling your service). This way, your users won't be interrupted in their interactions with the app, yet still be aware that something is going on in the background.
If you are using an MVVM pattern, your ViewModel or Model classes should be doing the heavy lifting of talking to the service. If your app absolutely must show MessageDialogs, I'd recommend creating an event in your back-end classes that will cause the UI to show the MessageDialogs on completion of the call. That way you can subscribe to those events when you load the page, and unsubscribe from them when you navigate away. In this way you can avoid messages appearing from Page2 when you are on Page1 of your app.
I would like to know what is the clean & correct way to notify my WP8 app that the ChannelUri has changed?
I read that i need to handle this in the ChannelUpdatedUri method. But i have a few queries here. Doesn't this require my app to be running all the time?
Second query is suppose i use ChannelUpdatedUri to listen for changes to the Uri. If there is a change will the app be notified as soon as it launches? Or will it be notified at a later time?
The trouble is if the app is not notified on launch then there is a possibility that it may re-register for a new channel uri before ChannelUpdatedUri is invoked. Isnt it?
Please help!
You'll only get notified of a change in the ChannelUri when you have the listener attached and the app running.
The best approach is to always check for the current Uri and pass it to the server when the app starts. You could leave the listener attached for the lifetime of your app and get a new one if it's lost while the app is running but in reality it's far more likely that the channel will be dropped/disconnected when the phone isn't in use.
There is, of course, the scenario where a channelUri may expire when the app isn't in use but the utility of the app is primarily around sending notifications. Obviously you need the user to restart the app to get a new connection but you can't tell them to restart the app.
This is a generic problem: how do you tell someone that you can't talk to them?
The reality of this situation is that if you really need to tell someone to launch the app again you'll need another way to do it.
Unfortunately, it's not possible to get an updated channelUri from a background agent, but you could query your backend to see if you need one and then raise a toast to the user to prompt them to reopen the app. Or you could just update the tile from the agent when this happens.
Alternatively you'll need to send them the prompt in another way (e.g. email or SMS?) but this is reliant on you capturing and securely storing these details.
There is no perfect solution to this scenario other than creating an app that the user opens regularly regardless of whether there are notifications or not and simply having the notifications as an extra feature.
According to MSDN, MPNS will put the notification requests in queue for delivery, so there is always time delay for them to get to device. My problem is that, sometimes, for example when the device goes to Temp Disconnected mode, the time delay is so long that the toast notifications become outdated when they arrive. Is there a way to discard/ignore these old toast notifications without renew the current push channel? If not, is it all right for me to renew push channel every time I open app?
As far as I know, it's OK to renew the channel every time you open the app. If your app is not running and you don't have a background task getting these notifications, you will automatically be discarding them anyway. Also, if my memory serves me correctly, should you use the channel request with an object that has been previously used to receive stuff from the channel, you can get the same channel (I might be wrong here). In this case, if you get old messages, you probably have to handle the local discarding manually.
I have a BackgroundTask which connects to a remote server and does some kind of action, download, upload, etc. This task runs every 15 minutes.
The UI associated to the BackgroundTask does the same and more.
However, the remote server allows only one session per login and I have only one login to that server. As such, I need a strategy to ensure that either one of these two are active and not both.
Currently, I store a value in LocalSettings which indicates if the UI is open or not. If the UI is closed, the BackgroundTask will do it's job as per normal. If the UI is open, the BackgroundTask will do nothing.
This works fine, except for when the BackgroundTask is in the middle of it's Run and the UI is launched. I need a way of cancelling this BackgroundTask immediately when the UI is launched, so that the UI can use the login to the remote server. Any tips or suggestions on how this may be achieved?
Thanks to Dave Smits for the solution.
In a nutshell:
Register for Cancellation event in Run method.
In the Cancellation event handler ensure connected sessions are disconnected.
When the OnLaunched event is raised in the App object, Unregister the
task which raises the task Cancellation event.