Android app design: The right separation between actions, services and threads?

Question

I'm currently trying to finish developing a larger application that is used to remotely control wireless devices through a proprietary wireless bridge, a USB device using CDC.

But right now I'm stuck on how to properly split between Activity, Services / IntentServices and workflows .....

The application will be made from these basics: - Various GUI screens that will eventually work. I intend to have some threads for receiving several messages and, accordingly, updating the GUI through the handlers for these message receptions. Any comments on this approach?

• A module that processes the entire low-level USB / CDC connection, message serialization / deserialization, and message transfer to the application via queues. This requires a separate thread. I don’t want this thread to be destroyed just because the activity that spawned it leaves - what does IntentService call in my book - right?

• Some players are sequences that will control wireless devices on time. They will be launched from one of my activities and MUST be launched to the end, not stopping due to pressing buttons on the house, launching other actions, etc. - Again, this requires an IntentService ..... right?

• A status module that updates some “global” data structures (possibly a database) when receiving messages from a low-level module. Here I am puzzled ... coulmd, is it just a working thread in my main activity - or am I looking at a third IntentService?

Would it be better to include everything in one service and then just add threads where necessary?

Sorry for my mobility - Android is difficult for C ++ programmers who have been programming backgroud tasks for GUIs of the last century.

Thanks in advance!

Answer 1

For bullet one and two, you are right that service is the best approach. In particular, IntentService is good for handling jobs one after another that were sent from another location.

If your service should only support a live thread, which itself processes the message / queue processing (as I understand it, a bullet), a regular service may suffice.

For bullet three, it depends on whether these updates should be performed until your application is noticeably active for the user. If so, use the service as well.

By the way: a thread is not tied to a specific activity or service, but to a process. If this process contains a running service, then all threads in it are also supported (except for the process, which must be killed due to special circumstances).