title: Android: redesigning producer consumer /approach for sensor data
body: <p>I have a single threaded Android application for reading data from beacons. I have a service that handles the beacon readings today (mainactivity just starts this service). I am noticing that my code base is becoming complex and need to be partitioned. </p>
  
  <p>I want to have a producer thread that gets the data from the callback, from BLE Scan, and put into a queue that consumer thread (= existing service??) would handle. But I am confused on how this consumer thread has to look; because consumer thread (= existing service) also gets events from 1) GUI which is mainactivity and 2)several receivers that are defined in androidmanifest.xml.</p>
  
  <p>So consumer thread cannot block on the queue and it some how has to handle events from GUI and receivers. How can I achieve this?</p>
  
  <p><strong><em>EDIT</em></strong></p>
  
  <p>It is a 24/7 app that always runs in the background and scans the beacons. Also, periodically pushes the data to AWS. Because we get callbacks at about every second, delivering them via Intent to the service is expensive (Intent = Thread creation and destruction). Because app has to process the scanned values and push data to AWS, we will be delaying/blocking callbacks from BLE scanning(from the logged timestamps, I notice I am getting callbacks at about once every 3 seconds because of the processing overhead in my code; while the same codebase without any processing is just scanning at about once every 500 ms). Hence I am thinking of multi threaded code producer and consumer model</p>