6 ms·

Another huge pain point of UWP: the whole suspend/resume concept. UWP apps can't be closed by the user. The system manages the lifecycle and there's no way for

by ricg 9y ago

Another huge pain point of UWP: the whole suspend/resume concept. UWP apps can't be closed by the user. The system manages the lifecycle and there's no way for a developer to know when the app will be terminated and when to save data. To save your app's data you have to: - Register for a suspend event - Ask for an extended execution so that your app is not terminated within a few seconds - Save your data and cross your fingers that the system does not terminate your app anyway and your data is lost I recently ported a document-based macOS app to UWP and this was the BIGGEST pain point (aside from the fact that there's no easy way for an app to have more than one window, ouch).

rymate1234 9y ago
It's worse when your app requires to maintain a constant connection to a server in order to function - when the app suspends good luck knowing when that connection will be closed, even with an extended execution!
- pjmlp 9y ago
  Well, that can be sorted out with a background task.
  - ricg 9y ago
    Even with a background task your app can be terminated by the system without further notice after the suspend event (e.g. when the user powers off the device). There's no orderly fashion in which an app can be terminated and save its data.
    - pjmlp 9y ago
      The suspended even is the orderly fashion to save the data. An ExtendedExecutionSession with a SavingData reason, should be more than enough for any kind of data.
      - naikrovek 9y ago
        Thank you. I was wondering if someone was going to mention this.
- reacweb 9y ago
  An application can never trust that the connection is reliable. When the app suspends, it is too late to use network. You should shut down as if you were offline.
pjc50 9y ago
This does force a particular design pattern which is very nice when it works but very painful to retrofit - incremental save.
deanchalk 9y ago
You are absolutely right, and I work with users who would fire someone in the dev team if their WPF app ever went down during the week (the app is kept running for 5 days of the week). This is necessary for many trading platforms
gpderetta 9y ago
If the application loses user data when forcibly terminated, it is likely not worth using anyway.

by ricg 9y ago

rymate1234 9y ago

It's worse when your app requires to maintain a constant connection to a server in order to function - when the app suspends good luck knowing when that connection will be closed, even with an extended execution!

pjmlp 9y ago
Well, that can be sorted out with a background task.
- ricg 9y ago
  Even with a background task your app can be terminated by the system without further notice after the suspend event (e.g. when the user powers off the device). There's no orderly fashion in which an app can be terminated and save its data.
  - pjmlp 9y ago
    The suspended even is the orderly fashion to save the data. An ExtendedExecutionSession with a SavingData reason, should be more than enough for any kind of data.
    - naikrovek 9y ago
      Thank you. I was wondering if someone was going to mention this.
reacweb 9y ago
An application can never trust that the connection is reliable. When the app suspends, it is too late to use network. You should shut down as if you were offline.

pjc50 9y ago

This does force a particular design pattern which is very nice when it works but very painful to retrofit - incremental save.

deanchalk 9y ago

You are absolutely right, and I work with users who would fire someone in the dev team if their WPF app ever went down during the week (the app is kept running for 5 days of the week). This is necessary for many trading platforms

gpderetta 9y ago

If the application loses user data when forcibly terminated, it is likely not worth using anyway.