Background Apps

Some applications might need the ability to run in the background: ie. to run without having a window open. This is a brainstorming page to figure out to handle this.

Goals

• Allow applications to run in the background as a service, without the user having to launch them. eg. A mail app could continually check your mail without it being explicitly launched. This solves a number of UX issues:
  • It reduces the amount of work the user has to do to get the services they need up and running.
  • It prevents errors, where you think that a background service is running and it isn't - for "service" type apps, the need to keep a window open for the app to keep working is a potential source of errors.
• Do not allow background apps to leak into the foreground, distract from or interfere with foreground applications.

Non-goals

• Enable applications to hide their windows while still providing foreground functionality. eg. Music players.

Prior Art

Windows 8

Background processes/services in Windows 8

Android

Applications can be prevented from running in the background by using the disable button (found in the Apps section of Settings):

Note: on Android apps can register as services, so they can run in the background without any notice. Only the frontend of the application is then listed in the task manager, so for example killing Hangouts from there does not disconnect from chat.

iOS

Settings has a global switch to disable apps from running in the background:

"When Background App Refresh is on, apps that take advantage of this feature can refresh themselves in the background. For example, an app can check if new content is available and download the updates, or retrieve the updated content in the background when it receives a push notification, ... Apps can also schedule background refreshing based on your location. ...

iOS learns patterns based on your use of the device and tries to predict when an app should be updated in the background. It also learns when the device is typically inactive, such as during the night, to reduce update frequency when the device is not in use."

• -- iOS: Understanding multitasking

Discussion

The kind of capabilities being explored here could potentially be provided by a combination of Wayland, Flatpak and Portals. The compositor would be able to identify Flatpak apps that don't have open windows and portals could use this information to determine what the app is able to do.

Open questions:

• Should applications be required to obtain user permission before they run in the background?
  • Associated question - does there need to be a way for users to revoke the ability for an app to run in the background?
• Is it necessary to provide a more convenient way to stop background apps from running (other than killing them from system monitor)?
• Would "Quit" mean exit and not run in the background?
• Possibility: provide a mode that prevents background apps from using network, as a way of allowing users to cut down on their data usage.
• Possibility: indicate which apps are running in the background in system monitor.

Tentative Guidelines

Some basic capabilities and restrictions for background apps:

• Capabilities:
  • Run without a window.
  • Automatically launch in the background, when the user session begins. (This might not be desirable in all cases - needs further thought. If it is an optional thing, apps could maybe be restricted to autostarting in background mode.)
  • Send notifications.
• Restrictions:
  • Consume a noticeable amount of system resources, including cpu, memory and network bandwidth.
  • Draw on the screen or play audio.
  • Independently open windows.

Comments

• Should close-vs-hide window be immediately visually indicated? Currently, if a user presses "x" on their instant messenger for the first time, there's no way for them to know if the program will quit, or hide to the tray. Windows that hide could have their "x" change to ".", and it would more obvious to the user what pressing the button would do.

• Does it make sense to distinguish apps that "run in background" (music, torrents) from apps that offer/run session services in the background (e.g. gnome-software-service)? What about services that are not directly related to apps at least technically (evolution-data-server, telepathy)? What about apps that keep a inert background daemon for performance reasons (gnome-terminal-service, evince-daemon, and a number of GtkApplication apps for usually 10 seconds)? More generally, are the requirments from the pov of performance (so stuffing it in gnome-system-monitor/Usage would be appropriate) or privacy/awareness (so one should be able to turn individual background features, and we need a persistent session indicator of what's going on)?

• Probably hiding it under tray/panel is the best way to go. It'd be cool if my mail client is hidden, but at the same time I can visually check if no new mails received. Messaging Menu is more or less the extensions we can reuse, however it needs more UX love: https://extensions.gnome.org/extension/519/messaging-menu/

• One thing I've been playing around with is the idea of putting specific background apps and hidden (minimized) application windows in the Message Tray. To me background apps and minimized app windows are basically the same thing. Also viewing a background app as an icon is more immediate and less tiresome than search through a huge text list.

  • mockup - overview in browse mode

  • When the user nudges the screen they're able to check on things very quickly.
  • Background apps are on the right side and minimized windows on the left.
  • Minimized app windows are grouped by application as are background apps.
    • Right clicking on an icon reveals a status menu and some action items.
    • Background apps reveal a list of ongoing actions in their status menu.
    • If the icon is of a minimized app window it reveals a list of windows.

• (Building upon Carlos’ API idea) When an app is registered as a background app the close icon and animation could be changed to a hide icon and animation to better indicate what is going to happen and to distinguish between closing an app immediately and minimising it. —JurajFiala

• Android Oreo recently changed how it deals with background services

  • Exploring background execution limits on android oreo

  • How to handle background services in Android O

  Transient services seems related to this. It was mentioned at GUADEC 2017 that moving to systemd user session might enable similar limits on background services for GNOME. Can background services which are running all of the time today be migrated to a system where they are ran once every e.g hour instead to pull in mail, calendar, social media etc. Systemd Timers allow of this right? —JohnMcHugh