0
votes

I'm still getting used to Jetpack Compose and I'm trying to get ahold of the phone sensors, specifically the accelerometer in this case, but it could be anything...

In a standard Activity flow, I'd get an instance of SensorManager and go from there, but given the focus on Routes that Jetpack Compose goes for, I'm at a loss as to how to perform such a task. We have one MainActivity.kt from within which the Navigation is handled.

Do I truly have to pass the SensorManager instance all the way down to my Composable? It seems excessive to simply detect a device shake... If the device shakes, perform this in the Composable...

In the bigger picture, this question also applies to anything you'd do in standard lifecycle methods I guess... In a Header(...){} component, I do not have any access to an onCreate method. Am I to understand that if composables need to depend of lifecycle, I have to bubble everything back up the tree similar to what you would do in React without Redux for instance?

The Compose docs specifically mention that state can be managed for "something like sensors", but how do your retrieve the elements you need to have access to these sensors?

I appreciate the help, as always.

1
Why is "detect a device shake" the responsibility of an activity in your app's architecture? - CommonsWare
I wouldnt say it's a responsability, but I want something to happen if the device is shaken while the app is displaying the contents of a specific Route. - aLx450
That still does not explain why the activity needs to be involved with the sensors. There are lots of things that an activity could do, such as disk I/O and network I/O. On the whole, for any sort of serious work, we have been moving those concerns out of the activity and into other objects (viewmodels, repositories, etc.). So, perhaps you should be moving your sensor work out of the activity and into other objects (e.g., a viewmodel), where those other objects expose an API (e.g., a BroadcastChannel for shake events) that your composables can consume. - CommonsWare
In a ViewModel or not, I still need to be able to instantiate a SensorManager somewhere. Given the very, very, veeeery recent venture that is Jetpack Compose and, let's face it, the limited user base around it, along with the limited proven examples out there, there is not much "serious work", as you put it, in production right now. Now, I know you wrote books on the subject, but frankly, you come across a bit pompous. I appreciate the help, I truly do. But this is new, for most people. - aLx450
Let's pretend that you were sticking with the current View system instead of using Compose UI. Having the activity detect a shake still does not make sense with current app architecture approaches, outside of trivial apps. "But this is new, for most people" -- Google's recommendations for app architecture are about four years old now, and there were plenty of other industry experts talking about the same stuff for a couple of years prior to that. Compose is new, but the concern that I raised in my initial comment is not. Compose just puts extra emphasis on architecture. - CommonsWare

1 Answers

0
votes

You can use:

@Composable
fun myComposable() {

    val sensorManager = LocalContext.current.getSystemService(SENSOR_SERVICE) as SensorManager
    //...
}