I have a dispatcher timer in my windows phone app, issue is while user clicks on the center button (deactivated button) timer is stopping. I want to make this timer work when user again takes the app. I can save the stopping time in a isolated storage but getting confused while user again takes the app after the deactivated event occurs, timer getting stopped.
Basically i want a timer that runs when the application deactivating also.
You can't have running timer when application is deactivated. But what you can do is to save the exact time when user close app by saving it to isolated storage settings in deactivate event.
Then, when user activate app again, you need to get current time. Calculate how much time passed by and add it to your measured time variable.
Related
I used MediaCapture APIs in my App. Let's say I started recording and preview. During recording, I pressed Start key and quickly come back to the App by long pressing Back key and selecting my app (task swap). The result is that the preview is frozen either running on Emulator or 8.1 WP hardware. I don't find a better event to register for Start key. I understand that this.Resume can handle restoration when your APP is being deactivated. But here I mean I switch back from Start within 2~3 seconds and the Resume call is not get called. I am thinking that I can disable preview when Start key is pressed as a workaround. Then when App is brought back to foreground, user can restart recording. However, both scenarios I can't find a proper event. Of course if preview is not frozen when APP is swapped back, I don't need to do anything. Now it seems preview is not working after task swapped back from Start.
Here are the APIs I am using
_mediaCapture.StartRecordToStorageFileAsync(_profile, _recordStorageFile);
capturePreview.Source = App._mediaCapture;
_mediaCapture.StartPreviewAsync();
The issue you're hitting here has to do with the fact that as long as the debugger is attached, suspending/resuming won't work like it will once your app is running on its own.
See here: https://msdn.microsoft.com/en-us/library/windows/apps/hh974425.aspx
Try the same thing you're doing right now, except press the Suspend button in VS once your app is in the background. To bring it back, press the Resume button. Alternatively, try the same thing without the debugger attached.
As long as you're handling the Suspending/Resuming events correctly, MediaCapture lifecycle won't be a problem.
To learn more, have a look at the UniversalCameraSample on the Microsoft github repository: http://aka.ms/2015builduniversalcamerasample. It targets Windows 10, but a lot still applies to 8.1.
There are three events you can register for.
CoreWindow.Activated will be raised when you are no longer the foreground app. This can happen because the user switched away, or because something like a Reminder or Phone Call popped up on top, etc. Simply getting a toast notification does not raise the Activated event.
CoreWindow.VisibilityChanged will be raised when you are no longer visible. This happens when the user switches away, locks the phone, etc.
CoreApplication.Suspending will be raised when you are being suspended. The system doesn't suspend you immediately when the user switches away (in case they switch back quickly, eg they had accidentally hit the Start button). Instead it waits a few seconds before raising this event.
Due to the way that BackgroundAudio task and app lifecycle are built up, there doesn't seem to be a way to detect actual closing of the app and stopping its background task at this point.
This creates an odd situation for the user, where she can try to forcibly terminate the suspended-but-present app to "get rid" of the playing audio, yet the playback continues.
There is a possibility of reacting to the Suspending event, but that would just mean that the audio stops playing as soon as the user switches out of the app.
However, we are required to stop audio playback only when the user terminates the app via App Switch screen.
Is there any way of detecting that the app has been closed from its background task?
The BackgroundAudioTask is designed to continue even the main app has been terminated/suspended. There is no way to inform the BackgroundTask that the suspended app has been terminated.
After the app is suspended, no events are called or any code is run from your app. The last things what you can do is to put something into suspending event and/or window's events. You can save something in LocalSettings which will be inform the BackgroundTask that the app is inactive, it's also last chance to send a message to your task with information about UI status.
The above method is used in official MSDN sample.
I am looking to develop an application where i just need to detect whenever a call is picked up.
I do not need any details related to call log and just need the event to be fired which will manipulate the sensors and do some functionality.
Is it possible to have that kind of access. Is it available out of the box and if not, is there a way that I can request for access from Microsoft?
WP apps don't have this kind of access/functionality.
Only possible way would be to use the Obscured Event (http://msdn.microsoft.com/library/windows/apps/microsoft.phone.controls.phoneapplicationframe.obscured%28v=vs.105%29.aspx) Which requires your app to be launched all the time you want to capture the activity.
The problem here is that Obscured event is also fired in the case of alarm or lockscreen.
I doubt Microsoft will grant you access to more functionality.
When developing WP 8.1 Windows Runtime application, what’s the equivalent of the PhoneApplicationService.Activated and PhoneApplicationService.Deactivated events? It looks like PhoneApplicationService class is only available in Silverlight WP apps.
Application.Suspending event is not fired on Deactivated event (i.e. when I press Windows button).
You are right, under WinRT there is no Activated/Deactivated events. Your App can be Activated, but it's little different than in Silverlight. About the lifcycle you can read here at MSDN.
Your App will be Suspended just after you Navigate away from it. But - it's not working while you are debugging - more information here. When you run normally your App it will be suspended very fast after you hit Back/Start buttons.
About Navigation there is one thing you should be aware - when you Navigate away from the App, first OnNavigatedFrom is fired, then Suspended events (in the way you have subscribed them). But when you go back to your App - then Resuming events are fired, but OnNavigatedTo is not fired - reference:
Note On Windows Phone, OnNavigatedFrom() is called when the app is suspended. OnNavigatedTo() is not called when the app is resumed.
In some situations your App can be put into Not Running state. More again at Lifecycle at MSDN.
I recently received some code from another developer and there's one piece I would like to rework. It's a flash app that works with mic and webcam. When it is started you are prompted to press a button - after that the usual flash player settings windows appears asking you to allow access to mic and cam. The application needs to wait for user's response on this question. It was achieved in the code I received in a rather awkward fashion. Application progressed on mouse movement event, which would not be registered since the flash player settings popup block the area. Once it out of the way - any mouse move would make application to go on. I need to rework with in some better way, because this piece of code is also used in AIR application that doesn't ask for allowance and, therefore, if you click the opening button you would need to move your mouse in order to get things running. I believe there must be some decent way to notify the app that settings popup is gone. Could anyone advice on this?
The correct way to do this in Flash Player is to listen for StatusEvent.STATUS event which is dispatched after the user either allows or denies you access to their mic. See the documentation for Microphone.getMicrophone().
In AIR, however, you don't have to ask for user's permission to access their mic and camera, so this event is not dispatched when your application gets access to the input device. In that case, you can check through Capabilities.playerType property if your code is running in AIR and then proceed with doing what you would have done in response to receiving permission to access user's input devices.