There is my WifiConnection class that encapsulates the process of connecting and receiving data via Wi-Fi Direct (peer-to-peer). It can contain thread {} or a CoroutineScope(Dispatchers.IO) for socket processing. The connection needs to be alive as long as the application is alive. Users can open other applications (phone calls, messengers, etc.), but the connection must continue to be active.
What is the difference between:
Service and creating an instance of WifiConnectionWifiConnection as a singleton provided by HiltAs I understand it, both cases will be WifiConnection survives during the activity/fragment lifecycles changing when the user interacts with my app. However, what happens when the user switches to other apps or turns the screen off for a long time? I can call the startForeground() method and send an ongoing notification for the Service. However, if the singleton is the same outcome, therefore, the Service and the notification are overhead.
It seems what you're really needing here is an explanation of how injection works and Android lifecycles.
Injection is basically a singleton. Some component (generally the application) will hold a Dagger (Hilt is built on top of Dagger) graph with a bunch of saved instances, and when you inject a class it will apply those saved instances. It's more complicated than that, but that's a broad overview.
That means the instances will last as long as the Application object itself does. The Application object lasts as long as the program is in memory. If the OS kills the process, the Application object is destroyed. Restarting the app gets a new Application and new instance of everything in the Dagger graph.
In Android, when an app is in the background (no Activity is on top of the stack), the OS will eventually kill it to claim resources. The amount of time that takes can vary depending on power save modes, OS version, phone utilization, etc. But when it does, all those values in the Application are deleted because the process no longer exists.
What a foreground service does is it tells the OS that this piece of code is going to be running in the background. It makes it a higher priority to keep around than an app in the background with no foreground service. It still will eventually be killed for resources, but it will be given MUCH more time before that happens. Without a foreground service it can happen within minutes, maybe seconds if you start a memory hungry app. With one, it will happen only after a very long time or when the OS has no choice in order to allow other foreground apps to remain running. (Please note that a background service is not enough, it will only be allowed about 2 minutes in the background before being cleaned up for memory).
So if you need to keep an instance of something around in thebackground for a longish time, use a foreground service. Just remember that it is NOT fool proof, your foreground service will not last forever. Realistically you should be looking at any option to not need to be around in the background and instead respond to incoming events with BroadcastReceivers, although for wifi direct that may be hard to do.