Question

To begin with, this is the first Android app I’m writing, and I have very little prior Java experience. So nothing is too simple — I could easily be missing anything “obvious”.

Here’s the general design I’m dealing with:

• A long-lived bidirectional network connection.
• Requests should go out over the network when the user interacts with the UI.
• The UI should be updated when the responses to said requests come back — asynchronously.
• The app will contain multiple activities.

These activities will be focused on particular areas of functionality available, all relying upon the same underlying network connection. So I want to set up this connection no matter which activity my app starts in, and have it survive across switching to another activity in my app, but I want to shut it down when switching away from my app completely.

I think I want threads. I’ve got something basic working, but not well because I don’t think I have them organized properly. I also am, so far, unable to pass data between the UI and network thread, so I can’t get requests in nor actions for responses out. So I’d appreciate any advice.

Answer 1

I think I want threads.

You don’t have a choice on that front. You will need a thread that listens on your socket for incoming data. Android is no different than standard Java in that respect.

I also am, so far, unable to pass data between the UI and network thread, so I can’t get requests in nor actions for responses out.

Well, your thread should be managed by a Service. The network connection supports multiple activities, so no one activity should own the thread.

You will then need to decide when the network connection should exist. Since activities come and go, you will need to decide if the network connection should only exist when one of your activities is in the foreground (in which case you would likely bind to the service with bindService() from each activity), or whether there is an explicit “start” and “stop” operation that the user must do, so the connection can live after all of your activities are gone (in which case you would likely use startService() instead of bindService()).

Once you know when and how you are starting/stopping the service, you can decide how that service will communicate its results back to the various activities. There are tons of options, some better than others depending on your use case. Registered listeners, Messenger, broadcast Intents, a ContentProvider, and so on are all candidates. Any of those can be used by a background thread and can arrange to get data to the foreground activity on the main application thread. The other activities would typically refresh their data during onResume(), since there usually is no point in proactively updating them when they are not on the screen or may have even been kicked out of RAM.

IOW, “advice” is several chapters in a book or two. 🙂