I am not sure what is the best way for the tasks below: threads, AsyncTasks, Loopers, services? Why? Are there other candidates?
I need threads/Tasks/Services/other for:
- Plotting data, (refreshing should be done let’s after after specific amount of data has been read)
- Generating data, (must being done during whole application runtime indefinitely)
- Reading data, (as above)
- Saving data on SD card / doing some logs
- Interacting with UX
More detailed scenario I must emulate communication between an external device and Android.
External device (I don’t have access to that device for some time – I am waiting for it to arrive, that’s why I want to emulate the communication – which is a control and measurement system board with ARM microprocessor) generates some data packed in frames in ASCII format.
Android needs to pool? (Maybe there’s a way to say: “Hey I have generated data for you. Take it!”? – If yes, could you advise me?) the external device to read data.
Let’s look at the options:
AsyncTask – Allows something to perform background work and publish results on a UI thread. Designed for you to use with something short that needs to happen in the background which once complete immediately updates the UI.
Loopers – Essentially is a construct that helps you implement queue processing on a thread. So, others can send your thread messages that are added to a queue which you then handle sequentially.
Services – Essentially an app that runs in the background and doesn’t have a user interface. Once started, can continue running.
Threads – I think you understand this. Asyc within your app. Dies with your app.
So, to answer your question, a thread will be best. An external device is running independently of your application code, but only interacts with the phone while your app is running. So, it doesn’t need to be emulated as a service (completely unnecessary) and should be not done as an AsyncTask – you’re not emulating UI interactions (I assume). A Looper may be helpful, but it depends on the specific interaction between app and device. Your description suggests you want something to independently generate the events that your application handles (with potentially bidirectional traffic between the two). Using a Looper would require that you code both your application and external device as separate threads, then use Loopers on each to manage queued communication between the two.
So, whether you use the Looper construct or not, you’d still need to emulate your external device in a thread. Furthermore, a Looper would introduce a further level of indirection and abstraction between your app and actual device. I’m sure when you get to working with the actual device, you’d like to modify your application code as little as possible. Using a Looper, you’d need to write a thread that handles communication through the Looper construct. Since the actual communication will likely already be either asynchronous or through another synchronous (threaded) library, emulating it as a thread makes it easy to use the same semantics as the final implementation (you won’t need to add on a Looper wrapper or remove the one from your app and test/debug a different interface layer).
1
This can be achieved by using interrupts[1]. Interrupts can be used with timers, digital inputs and the serial port[2]. Depending on the Arduino variant, some or all of the pins can be used for interrupts.
For regularly occuring tasks, use timer interrupts. For the serial port, use NewSoftSerial.
1. We interrupt this program to bring you a tutorial on… Arduino interrupts
2. NewSoftSerial
1