Add start workers in LaunchActivity

[TimoPtr]

Summary

Replicate the start workers from the WebViewActivity within the LaunchActivity. It does replicate exactly the existing behavior, it is not gated behind WipFeature because it just triggers a second update of the sensor which is acceptable.

Checklist

• New or updated tests have been added to cover the changes following the testing guidelines.
• The code follows the project's code style and best_practices.
• The changes have been thoroughly tested, and edge cases have been considered.
• Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.

Any other notes

[TimoPtr]

@jpelgrom I'm struggling here to find a nice way to work with this and I need more context.

• I don't want to use any Context in the ViewModel
• ViewModel should stay unaware of the onResume/onStart IMO if possible

From my point of view it is also not the responsibility of the Screen to start the workers.

I can modify the start function to not take any Context by injecting the WorkerManager in the ViewModel, but I wonder if the logic of starting in onResume is mandatory or if it can only be made one time when the VM is created?

I'm curious about your opinion here.

[github-actions]

Test Results

  231 files    239 suites   10m 11s ⏱️
1 776 tests 1 775 ✅ 0 💤 1 ❌
1 847 runs  1 845 ✅ 0 💤 2 ❌

For more details on these failures, see this check.

Results for commit 6d9e728.

♻️ This comment has been updated with latest results.

[jpelgrom]

@jpelgrom I'm struggling here to find a nice way to work with this and I need more context.

* I don't want to use any `Context` in the ViewModel

* ViewModel should stay unaware of the onResume/onStart IMO if possible

From my point of view it is also not the responsibility of the Screen to start the workers.

I can modify the start function to not take any Context by injecting the WorkerManager in the ViewModel, but I wonder if the logic of starting in onResume is mandatory or if it can only be made one time when the VM is created?

I'm curious about your opinion here.

I think the goal the current behavior is trying to achieve is simply more updates for sensors / a way to kickstart any workers that the system may have suspended, as it is unlikely they will be delayed when the app is actively being used. That means tying it to the entrypoint for users -> WebViewActivity. (@dshokouhi might know more history here.)

Following that logic, it isn't really about the specific screen but rather the entire app being opened or hidden (lifecycle).

I kind of understand what you're trying to do with the ViewModel taking no context, but could you spell it out? There are still tons of Android-specific functions that exist and need context so I'm not sure it can be completely avoided forever, and to do everything in Compose where you have a context feels like misuse.

ViewModel doesn't need to know about onResume/onStart but we could want functions called on those lifecycle events. If multiple things need to happen on onStart I'm not opposed to simply creating a function named onStart in the ViewModel to make it easier to manage 🤷.

[dshokouhi]

Yes we do have an app importance sensor that needs to update if the app is in foreground or what not. That's why the on pause and on resume calls are there. It should be on the settings activity as well iirc

[TimoPtr]

@jpelgrom we could potentially move the logic within the ViewModel but I'm not sure if it relevant here, it would force us to pass the context or change how we start the workers.

[Copilot]

Pull request overview

This PR updates LaunchActivity (the app’s navigation entry Activity) to start the same background workers that are currently started from WebViewActivity, so sensor updates and the persistent WebSocket worker are initiated when the app resumes.

Changes:

• Start SensorWorker and schedule WebsocketManager from LaunchActivity.onResume()
• Trigger an immediate sensor refresh via SensorReceiver.updateAllSensors() from LaunchActivity.onPause()
• Expand LaunchActivity KDoc to describe these lifecycle behaviors

[Copilot]

This change claims to replicate WebViewActivity behavior, but WebViewActivity only triggers SensorReceiver.updateAllSensors() on pause when the activity is not finishing/relaunching. Here it always broadcasts on every pause (including finishing), which is a behavioral difference and can cause an extra full sensor update. Consider adding a guard (at least !isFinishing) or documenting why LaunchActivity should behave differently.

[Copilot]

The KDoc says these workers are "tied to the Activity lifecycle" and that onResume "starts" a persistent WebSocket connection, but both SensorWorker/WebsocketManager are WorkManager periodic jobs that can outlive the Activity. Please adjust the documentation to reflect that the Activity only schedules/refreshes these background workers from lifecycle callbacks.

Suggested change

	* and managing background workers tied to the Activity lifecycle.
	*
	* It also handles the splash screen display based on a condition exposed by the [LaunchViewModel].
	*
	* On resume, starts periodic sensor collection via [SensorWorker] and the persistent
	* WebSocket connection via [WebsocketManager].
	* and triggering lifecycle-based refresh of background work.
	*
	* It also handles the splash screen display based on a condition exposed by the [LaunchViewModel].
	*
	* On resume, refreshes the scheduling of periodic sensor collection via [SensorWorker]
	* and the background WebSocket work via [WebsocketManager].
	* These jobs are managed outside the Activity and may continue beyond this lifecycle.

[TimoPtr]

What I don't like with this approach is that we don't have any tests.