CODEWITHSUNDEEP
c#windowsservicebackgrounduwp
Bixit
Bixit

Reputation: 41

Windows 10 uwp sticky background service?

I'm trying to convert an Android app to Windows 10 UWP. On android its easy: when boot completed, app service is started. It connects to controller over internet, fetches system state and all data (temp sensors, pumps, valves, etc) and keeps everything in memory. Foreground app can get data as soon as service gets them and display values, charts realtime. After closing foreground app, service keeps working, I still have all system state and I can play alarm sound if needed.

Is it possible to do [almost] same functionality on Windows 10 uwp?

I cannot find a way to start service with windows. Service started with foreground app is stopped when foreground app is closed. SocketBackgroundTask keeps connection perfect, but system state is lost with service.

Should I save system state to file and analyze all data after each renew? Data flow varies from once in 10 minutes to ~10 per second.

Or should I forget Windows 10 as limited platform?

Upvotes: 4

Views: 2634

Answers (1)

Vladimir Akopyan
Vladimir Akopyan

Reputation: 654

I am designing a similar piece of sensor control software, and I have found UWP/Win10 to be limiting. We ultimately resorted to using Assigned Access to keep the app permanently in the foreground.

Assigned Access Assigned access assigns an app to an account. So when Mr. Bob logs in, the app starts full-screen, and it cannot be closed, and if it crashes, it is restarted.

Note that the only way to access other parts of the system is to hit ALT-CTRL-DEL and log in as a different user. That might be bad for some, but if you have critical process monitoring going on, then it's probably a good thing that the user can't mess about with the system or quit the app.

It's also quite simple to implement, you only need to add a declaration to the app manifest, and you need Win10 Pro or Higher.

Windows IoT You could also look at Windows 10 IoT, when you deploy an app to it, it does pretty much the same thing. However the range of hardware is quite limited, and many of them aren't fully functional yet - RPi suffers from SDcards being inherently unreliable, and lack of graphics acceleration. Dragonboard lacks driver support for resolutions other than 720p, etc. https://developer.qualcomm.com/forum/qdn-forums/hardware/iot-development-platform/29652

Extended Execution In addition we have experimented with using extended execution, which lets the app run in minimised state, potentially indefinitely. I have mixed feelings about it. Although the app will keep running most of the time, but if the OS is struggling for resources, the app will get suspended and won't be restarted until the user switches back to it.

Upvotes: 1

Related Questions