I have a simple xaml form which, when LoadState is called, enables a Dispatch Timer. When the dispatch timer fires, it checks a service for new items. If a new item meets a certain criteria, it adds the message to a local variable (which ends up being bound to a listview), and we use the ToastNotification framework to create a new toast. However, one thing I've noticed is that the ToastNotifications appear only to work when the app is focused (which, of course, defeats the point). I think this makes sense, in part, because my app is suspended when not focused.
However, I know my DispatchTimer is executed when the app is suspended, because I see the web requests firing off to the service. It must mean that my call to send the notification is deferred somehow. I guess conceptually, how do I get the toast notifications to execute if my app is suspended? I have read up on BackgroundTasks, but those only respond to system events. What I really want is for my app to poll for messages regardless of its suspended state, update the UI when it can and update notifications whether the app is supended or not.
Unfortunately the only reliable way to achieve your scenario is with a BackgroundTask, that you can run every 30 minutes. DispatcherTimer requires the UI thread, which will only run if your app has focus. If you are seeing web requests go out it may be due to some other anomaly, but effectively when your app is suspended no further user code is guaranteed to run - including popping a toast.
It sounds like you might be looking for something more like push notifications. Would these work for you? You could use them to display toast notifications, update your live tile etc.
Notification Platform Development on Windows
Mobile Push Notifications to Any Client with Azure Notification Hubs
Get started with push notifications in Mobile Services
Related
I am new to .NET and seeking help for the Windows Service Updates Notifications.
I have a use case that is somewhat similar to "https://stackoverflow.com/questions/41232170/c-sharp-show-notification-prompting-a-update".
The application is developed in C#.NET and is deployed and running as Windows Service.
However, the application is not using any MSI installer to install it. I am using a batch script that configures the Windows Service application.
Now, I want to show the notifications about the updates about the Windows Service to the user, when the system gets restarted.
I came across about the usage of WCF or by using the Task Scheduler, but not sure which one would be the better solution.
Please advice.
Ok, there are (were, because MS disabled the first one that I'm going to explain) two ways to notify your user about updates from a service.
First, the bad, ugly (and non-working in recent versions) way: interactive services.
You can configure a service as interactive, if you add the SERVICE_INTERACTIVE_PROCESS flag the service will be able to create a GUI that will be attached to Display_0. This presents a ton of problems (trying to show a GUI when there's no user session, if you have two sessions open only the first one will show the GUI and so on) but it's a cheap dirty way to show data to the user. Avoid it.
Second, the right way: a standalone GUI program.
In this case you create a secondary program that will show the data to the user, you can start it with the user session or let the user decide if he wants to receive info by opening manually this application. This program needs to receive the updates from the service in some way, which is better is up to you but I would use UDP for this, in this way your service doesn't needs to care if any GUI app is connected or not, you broadcast an UDP message and everyone listening will receive it, you don't need to mantain a server that handles connections, you don't need to have an storage in order to maintain the event data and it will support any number of instances of the GUI (if more than one user has started a session in the machine all of them will get notified).
But as I said, that would be my preference, you can do it as fancy as you want, you can use Pipes, use a file that contains the event and use a FileSystemWatcher to get notified when changes happen in it, you can even host an ASP .net web app which implements a SignalR hub and then you can create your GUI in html. It's up to you decide which mechanism is the best for your scenario.
I have Win32 desktop bridge application that uses background task to receive push notifications from WNS. I use UWP background task APIs over C++-WinRT
I'd like to be able to receive push notifications even when OS is in sleep so that it wakes up and the app handles push notification. By default OS does not wake up. It did only after manually changing settings value in System->Battery->See which apps are affecting your battery life->Click my app ->Uncheck Let Windows decide option (by default it is always checked) and check Allow the app to run background taks. Now I'd like to do this is manual work on code for better user experience.
RequestAccessKindAsync API allows to let user to change above setting value by showing popup notification to the user and I could do it without any problem in UWP C# sample app. But same code does not show pop notification from my desktop bridge over C++-WinRT. It simply returns false value for below code
auto result = co_await BackgroundExecutionManager::RequestAccessKindAsync(BackgroundAccessRequestKind::AlwaysAllowed,
L"App needs to use background to catch push notifications while device is in sleep");
Can anyone confirm that RequestAccessKindAsync API works from desktop bridge? If not then how I can make sure OS and the app will always be able to wake up from sleep when it receives push notification?
UPD: Raised request to enable this API from desktop brige here
This is a missing feature. When we designed this API a couple of releases ago we didn't consider desktop bridge apps would be calling it - but clearly there is a use case for supporting this. I have notified the team about this gap, but I'd also encourage you to log a feature request here: https://wpdev.uservoice.com/
Two possible workarounds:
(1) you could add a dummy/empty UWP foreground app to your desktop bridge app. You can then launch this on startup and request the background access from there. This will be a bit ugly, but you could make it look like a splash screen :-)
(2) you can instruct the user to go into the Settings app to set your app to always allowed. You can help them do that with a deep link to the battery save settings, but they will still need to manually flip the switch.
We're writing a cross-platform C# "Xamarin" application; right now we're just targeting the iPad. The application has two features relevant to this question:
The app requires that the user authenticate to the app (in addition to logging onto the iPad)
The app connects to a remote device over Bluetooth
So the question becomes, what happens when the user switches to another app, which results in our app's OnSleep() being called. In OnSleep() we could immediately disconnect Bluetooth and log out the user, but that seems like poor usability, especially if they are just quickly checking some alarm that triggered or an instant message that came in.
For the sake of usability, we're thinking to have a 1-minute timeout; if the user does in fact pop out and quickly pop back into the app, we'd like things to simply continue on without any loss of communication or re-authentication.
If, in OnSleep(), I set up a timer using Xamarin.Forms.Device.StartTimer(), that timer does not fire while the app is "asleep".
What does it take to have a small background task/thread/process execute, even while the app is asleep? Something that simply waits 1 minute, and then shuts down the Bluetooth communication and sets a flag indicating re-authentication is needed?
I have a question about how best to check if a service is still running.
First a bit of clarification. The service I have is a C# application which can either be run from the command line or can be run as a Windows Service. The function of the service is to check for changes to a remote 3rd party data source and process those changes before adding them to our own local data store.
I want to be able to identify when the service has stopped functioning for whatever reason, and notify somebody when this happens as automatically as possible. This needs to happen regardless of whether the service is being run as a Windows Service or from the command line.
I have already considered monitoring the local data store for changes and notifying when changes haven't happened for a set amount of time, however this has proven to be a little too inconsistent, because the frequency of changes to the 3rd party data source is variable, which means that a prolonged lack of changes doesn't necessarily indicate that the service has stopped working, it could just be that there are no changes!
Are there any suggestions about how I might go about monitoring this? Anyone got any experience working with something similar?
Thanks, M
Edit 1
Just to give a rough idea of how the service works: The 3rd party service raises events when new/updated data is available so my service sits and waits for these events to be raised and processes the data returned in the raised event. Therefore this is why it's tricky to identify when there's "no changes" rather than "service crashed".
Edit 2
I think I need to be a little clearer: The main reason for this monitoring is to notify a user about a potential issue either with the service or with the connection to the 3rd party service. The service itself is single threaded and has proper exception handling and logging. Chances are this service is going to be run on a server somewhere so if there are any problems with the service and it stops updating our local data store for whatever reason the service needs to notify someone.
you might want to consider something like a 'heartbeat':
Heartbeat activity for Windows Service
But your main consideration should be working out why your service should be able to stop/hang? All exceptions need to be caught, and at the very worst case, reset your service to its start state after a short wait to prevent CPU maxing.
Windows itself has a variety of methods to help also:
Start > Run > Services.msc > Right Click Service > Properties > Recovery Options
If you design your application to properly use exceptions and handle them appropriately, you shouldn't ever have a problem with your service 'hanging for some reason'.
Additional:
Is there no way for you do determine the difference between "no work required" and a hang?
you can use ServiceController class in .net to monitor services.
I faced the same problem in one of my projects.
I used the below approach to monitor the my service.
First thing, i logged all the informations,errors from my service to event viewer in a standard format like this
custom-eventid|datetime|message
Then i created one more notification service which will listen to the
event viewer for the particular events,reads the message from the
event entry
if the event entry falls in the event viewer it will send mail
notification through smtp
if you are not provided with the smpt then go for windows application
which listen to the events and shows message using baloon or message
box
The solution that worked for this project was to use a heartbeat like implementation to allow the service to notify me of it's availability.
Because our application uses WebAPI I was able to set up an endpoint which the service "pings" every [x] seconds.
A separate process has been added which checks the date and time of the last notification from the service and if that doesn't fall within a set threshold I notify the user that the service is unavailable.
I looked at using the ServiceController but that was not going to be an ideal solution because of the possibility that the functionality added to the service could be run as a Windows console application instead of a Windows Service.
I am developing a C# a stand alone single user desktop application that requires the user to login to the application. I want to ensure that when there is no activity for 5 minutes or so the application will prompt the user to login again. I have several solution in mind to do this but there do not seem efficient. Previously while doing web programming i was able to do this kind of feature using session variable are there are similiar kind of features in C# that can be used for desktop application.
One way to do this is to set a 5-minute timer that is always running, and logs the user out when it ticks. Then you can have any activity restart the timer from the beginning.
If this is a WinForms app, you can have your top-level forms implement IMessageFilter. In your PreFilterMessage function you would restart the timer and return false for messages that indicate activity (WM_KEYDOWN, WM_MOUSEMOVE, etc.) to let everything get processed normally.
You can always add a trigger to auto-logout within a Windows Forms Application. Here is a link with examples with an accepted answer
How can I trigger an auto-logout within a Windows Forms Application?
To monitor user activity, you could create a custom Form-based class
from which your application forms will inherit. There you can
subscribe to the MouseMove and KeyDown events (setting the KeyPreview
property to true), either of which will be raised whenever the user is
active. You can then create a System.Threading.Timer, with the due
time set to 30 minutes, and postpone it using the Change() method
whenever user activity is detected.
No, but session state is just a list of variables to help overcome the stateless nature of web applications. Since desktop applications are not stateless, there's no need. I'd just use a simple timer or something similar and log the user out after 5 minutes of inactivity.