I'm creating a service that works independent of the app and sends notifications according to some business rules.
The problem is: if the app is open, depending on which activity is open, I can not do anything, but the default action is to open a specific activity.
I can not find any similar example or problem to study...
Any idea?
I'm sorry for the poor english.
Try to create your handlers methods as static in your "App" class and manage the behavior of your app since that point. Think about to use some events to handle specifics changes (as notify with a "new" badge on view, if you want).
I don't have a independent service, but I'm working in an app that once a user is logged in, it starts a background service to monitore battery, updates, user properties changes... and this solution works well.
Related
I'm using Unity for Dependency injection under Prism and have a situation where one of my modules is to display a screen saver of sorts when the user is running a test and no input has been received. (The region holding the view for this module displays in front of all other regions.) The idea being if the user goes to the other side of the room while the test is running, they can see a summary of relevant test information. When they interact with the application again, the screen saver will exit and return them to the main display.
Since the Shell is what captures user input, I need to alert the screen saver module to hide the view when the user interacts with the computer.
The screen saver module itself implements a shared service interface in the ViewModel that consists of an Enable() method and a Disable() method. The screen saver is only enabled when a test is running. The modules that run these tests will call Enable/Disable as needed. The ViewModel contains an internal timer that when the Screen Saver is enabled, will trigger the display of the View upon expiration. If the user interacts, the timer will reset (and the View is hidden).
I'd like to keep my application from having a large amount of PubSubEvents when its not necessary to have one. In this case, when the user interacts, I'd like to be able to add a method to the Screen Saver service that the Shell can use to signal the user interaction. However, I don't see how that is possible without a PubSubEvent, since the shell is created before the Screen Saver module, unless I want to use a ServiceLocator or by adding a reference to the Screen Saver project in my Shell, both of which I think are worse options than using the PubSubEvent. Even if I separate the services into their own separate module, and reference that from the Shell/Boostrapper (registering via ConfigureContainer()), that module will still need to somehow be able to communicate to the ViewModel to reset the timer/hide the view.
Am I just overthinking this? Is there some other way I can do this? Or is my initial idea of PubSubEvent the best way. I'm rather new to Prism, so I'm still getting a handle on best practices.
I cannot see anything wrong with using the EventAggregator, but you can, of course, use a specialized service that does basically the same thing, just only for enabling/disabling the screen saver. Just register that service as a singleton and have it injected wherever needed.
To make things a bit nicer, seperate the active (e.g. EnableScreenSaver() and DisableScreenSaver()) and passive (e.g. IsScreenSaverEnabled property and ScreenSaverStateChanged event) members into two different interfaces, implemented by the same service. This way you get a little bit of advantage over the EventAggregator - events cannot be publish-only or subscribe-only, whoever knows the event can always publish and subscribe. But you can make the active interface known only to the parts of your app that want to control the screen saver, whereas the passive interface can be only known the parts that have a screen saver that needs to be controlled...
I've found the following question asking whether it's possible to find out whether an app update is available:
Programmatically check Windows Store App update
(Not my primary question, but is there a better way?)
I know that it's possible to configure Windows 8.1 to auto-update apps, but this doesn't always happen as soon as I want.
So, now I know that an update is available, can I trigger the update from within the app?
If so, would this trigger have to take me through the Windows Store (which won't be possible in my scenario as I'm running in kiosk mode) or can it just start the auto-update?
Any thoughts/ideas on how I might be able to achieve this would be greatly appreciated.
Thanks
I've run into this problem as well.
What you can do is to check to see if there is an update available, then notify your users that they can either wait or update manually (through the Windows Store app, which you can open for them). You can also notify them of the importance level of the update (just UI fixes/additional features or is it a critical security patch?).
Lastly, you can also register the users for toast updates via an Azure Notification Hub, then send out a toast notification about it.
If it's truly critical, you can also include code in your app to do something like lock down unless it's fully updated or something similar.
In my experience, as of right now, these are our only options. Maybe one day they'll allow us to force an update via a Background Worker or something while the app isn't running. As of right now, that's not an option though.
I am designing an app which basically is going to check for new data, my initial thought for this is to use a windows service. If i get any new data i need to display a winforms app which i'll populate with this data so that the user can acknowledge it.
I know there are restrictions running UI apps from a service so i'm just wondering what others believe is the best approach for both. Also i need to run this on XP
The timer that gets the data
how to launch the WinForms App
As im writing this i've also been toying with the idea of using a console app but nothing seems to be fitting together in terms of functionality.
You can use a regular Winforms app. As soon as the application loads, hide the entry form from within the Form_Load method, this will keep the form hidden from the user. Keep a timer on the entry form that frequently checks for relevant data and pops up windows as and when required.
Background:
Started a fair amount of work before realizing that a Windows Service cannot start an app with a GUI that displays without potential problems. The proper solution of separating the GUI of the app to be started is non-trivial, so I'm trying to think of alternative solutions.
There is a GUI to manage the service that is a separate executable, but the process to be launched (actually multiple instances of it) has its own GUI that needs to be shown. It doesn't need to be made visible by the service itself, but it needs to be at least able to be made visible by another process with a visible GUI. The Windows User that is running the service and that needs to see the GUI of the launched process is the same and known at install time.
Is there some way to accomplish this or is it back to the drawing board?
Also both the service and the app to launch are both our code and modifiable.
My first thought was to suggest that you look at the WTS* functions and CreateProcessAsUser and then I followed the link you provided and saw that you have already considered this and dismissed it.
As an alternative, if I understood you correctly you have a Windows Service and GUI which is used to manage the service. So why not use the communication channel you have between the Service and the management GUI to send a message from the service to the management GUI and have the management GUI launch the other GUI apps on behalf of the service? Of course this would assume that the management GUI is always running.
You might even do this with a hidden application that is not visible and launches when the user logs-in, that way you reduce the risk of the user inadvertantly closing the application, this would be a separate app from the actual management application.
Is it true that a service written in C# is unable to give visual feedback to the desktop?
I understand that services start up before user logon and at that point ther is no desktop available. My question then, apart from logging events in the system event log which is not a very efficient way of communicating to the user, what are my alternatives for showing a message box from a service?
Only two options come to mind:
MessageBox.Show - Looking around it seems this is not going to be an option.
Show a custom form
I've not given the reasons for why this messagebox needs to be shown.
Please assume that it needs to be shown as I don't want responses on "good practice". Not at this point at least.
A windows service should not perform interactions with a user. Instead you should create a seperate control or configuration application - often put into the system tray - that communicates with the service an can present information to the user or gather inputs.
See this Knowledge Base article and this MSDN article if you really want to do this. They contain some hints how to achiev this an you will probably need to use P/Invoke from C#.
Here are some ways that you can make interactive services. But, those have gone away with Vista.
One way you can have a user get information from a service is to build a separate UI for the purpose. The service could have a WCF endpoint for example and push messages out that the GUI would show. That way, you only show a message when there is a user logged in and it's not a security risk by popping up a window from the LocalSystem account. You could easily make this GUI run from the tray and pop-up toast so it is non-intrusive and begins when the user logs in. Much much better than trying to interact directly with the desktop.
I've never used it, and I include all of the disclaimers about not doing this.
However, you may want to check out the MessageBoxOptions.ServiceNotification enum.
Here's a good blog post detailing its use.