Hi, >From my understanding, SensorManager spawns a thread in its calling application to poll sensor data while the SensorService in system server controls the sensor.
I have 2 questions: 1. Why Android designs the SensorManager and SensorService in this way? Most of time in Android, XxxManager usually is an easy-to-use wrapper for a XxxService and the service interfaces with HAL. Please kindly share the thoughts behind the design. Thanks. (My wild guess is that sensor can be very demanding of CPU, if it were read from system server, it would slow down the system). 2. I would like to develop some fancy algorithm on sensor. And I would like to let a number of applications to use the outcome of my algorithm. Now I faces 2 design choices: 1) I can put the class for the algorithm in the framework, and let each application to call SensorManager to listen to the SensorEvent and pump the SensorEvent into my algorithm. When my algorithm outputs something, each application can do its specific actions upon it. Or 2) I can create an apk which contains a service and my algorithm class. The service will be started on demand and it invokes SensorManager and pumps SensorEvent into the algorithm. When the algorithm outputs something, it will broadcast an Intent and each application can receive this Intent and do its specific action. Please kindly help share your thoughts on the 2 design choices. Thank you very much. Sam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
