I would like to create an UWP App (e.g. AppSwitch) in WinIot Core, which communicates with two different UWP apps.
In some situations the AppSwitch application only has to communicate with the other apps and depending on the communication, the AppSwitch has to display some Status information and needs to get the foreground app.
For that I was thinking to create a foreground app having an in-process AppService. But how is it possible to display the status information, if the apps was never Launched (OnActivated) but only started as AppService (OnBackgroundActivated). Can I get from OnBackgroundActivated to the UI if never launched?
Thanks
Schaf
Related
I am working on UWP app where in I have added Fulltrust permissions to my app in order to get access to the desktop application using APpServiceConncetion. But whenever I call FullTrustProcessLauncher it creates a new instance of my desktop application under my UWP app in task manager and it looks like it consumes CPU memory for each desktop app.
How do I close/keep only one instance of desktop app when I call it from UWP?
Also How can I kill desktop application from task manager/ background when I no more require this code using c# in UWP
You are in full control of the lifetime of your desktop application process, assuming you own the code. So your process can shut itself down whenever it is no longer needed. A common good practice is to shutdown when the appservice connection gets closed (i.e. the UWP app goes away and the ServiceClosed event fires).
There is some details on this in this post (under "Handling Process Exit Scenarios - Scenario 2"):
https://stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3/
Scenario. I want to make UWP(8.1/10) library (somekind of remote diagnostic of app) which works with my server. Is it possible to keep tcp/ip connection in background as long as possible?
I know about two things:
Run while minimized
Run background tasks indefinitely
But if I want to insert my library into some app and then upload it in Store, it won't work, am I right?
However, developers writing UWP apps for personal use (that is, side
loaded apps that won't be published in the Microsoft Store), or
developers writing Enterprise UWP apps, may want to use all resources
available on the device without any background or extended execution
throttling. Line of business and personal UWP applications can use
APIs in the Windows Creators Update (version 1703) to turn off
throttling. Be aware that you can't put an app into the Microsoft
Store if it uses these APIs.
Also I have read about ExtendedExecutionSession when app minimized from these questions:
Run Background Task Indefinitely in UWP
extendedExecutionSession : Can we run UWP like Desktop app without
Suspending?
But I'm still confused. So, can I make library for UWP(8.1/10) with long-running background tcp/ip connection and insert into app which will be uploaded in Windows Store?
I have developed an application which does periodical jobs. It runs as windows service in background and manages jobs. I want to trigger another application with GUI from service application when any error notification needs to be given to user. So after seeing err message user will give some response. So now service application (running as service) should do some work based on user response in GUI application (with interface). User response should be communicated to the service application.
So my requirement is
Application running as service should be able to trigger another application with GUI (its sufficient if triggering happens only when users are logged in)
Communication between an application running as service and application with GUI.
I saw many links about communication between service and application. Named pipes requires .net 3.5 and above, but I want my application to work in .net 2 alone. Writing to a txt file and reading it is last option for me as it is not the best method.
So how it can be done? Please give me ideas to start with.
I would like to develop a program (an agent) that will run on the user's desktop. It has to communicate with a web service periodically then if a state changes it will notify the user in a notification balloon.
Can I do a winforms or wpf project? (that will both communicate with the web service and notify the user)
Or should I do separately a windows service that will firstly communicate with the web service and then communicate with another standalone winforms app that will notify the user?
Thanks.
Periodically fetching status through service
You can implement an executable(Console) application which should have the logic to invoke the web service to fetch the status. You can use windows task scheduler to execute this exe periodically.
There are many task scheduler wrapper libraries are available, Use could use any of them based on your need.
Task Scheduler Managed Wrapper
Quartz Job Scheduler
Notifying user
If the status is changed then you can notify the user through any User interface, this can be WinForm or WPF application. When the exe which is initiated by the task scheduler finds a status change, it will execute the UI application that you have created to notify the user.
If you need only a single Form to notify the user then Windows Form should be enough unless you want to show any fancy UI using WPF.
Why Windows Service might not be a good choice
It's actually easy to use a windows service to periodically call the web service instead of using a Task scheduler, but the problem you will face with the windows service is that it can't easily communicate with user's desktop, that means it can't directly show/execute any User interface application on user desktop. You will end up writing a IPC(Inter Process Communication) mechanism to communicate with any UI application from windows service.
I'm working on a Metro style application in the new WinRT (.NET 4.5) framework for Windows 8, and I was wondering if it would be possible somehow for an application (through the registry or some other means) to register itself to start up when Windows starts as well.
I haven't been able to find anything about this anywhere else, only for Windows 7 or below, with normal-style applications.
There is no way to make a Metro style application launch at boot. The user will have to invoke the application from the start screen. Metro style applications cannot be services and so launching them at boot time doesn't seem like the right approach any more than launching Microsoft Word or Adobe Photoshop at boot time would be.
Microsoft's goal with Metro-style apps is that the user is always in control. Therefore, Metro-style apps cannot activate themselves when a machine boots up. Furthermore, traditional Win32/.NET desktop code cannot interact with Metro-style apps and so cannot start a Metro-style app behind the scenes.
That said, if your app has registered itself as the handler for the rendering of its own tile, then it gets called periodically and is asked to re-render its tile's content so it should always be able to show its latest status/news/info to the user when they view their start page.
I think you could have all your star tup stuff running as a service that exposes the appropriate WinRT level connectivity. Then the user only needs to fir up the client app.
Goo separation too.