When there is user input that needs to be relayed to the server, cache that response prior to relaying it across the network. The network communication can happen via an asynchronous mechanism (such as a network request thread pool), ideally in some batch of other accumulated responses. The main thing to avoid is having the user’s input lost because it was sent directly without being cached, resulting in the frustrating result of losing that input when there is network failure. Caching the input will make your application much more resilient as you can retry sending the user’s input data to the server whenever the network is available.
Service is how an application indicates to the operating system that it needs to perform a longer-running operation outside of the normal Activity UI flow. It may be self-running (through Context.startService()), or running on behalf of of another process (through Context.bindService()). If you do not need either of these behaviors, you should not use a Service. For example, if you have background work to do that does not need to keep itself running (such as downloading content for your UI that you could resume later when the user returns to the UI) you should use local threading primitives such as AsyncTask, Loader, HandlerThread, etc. Using a Service is much more resource-intensive (as your service needs to be tracked as part of the global system state) and opens the door to all kinds of bad bugs where your services is left running when it shouldn’t be (this is a very common problem in Android apps, and is harmful to the system). Likewise, if you want to have an association between two pieces of code but they are running in the same local process, don’t use bindService(); instead, use regular callbacks and other facilities. This will be easier to write, easier to understand, and less resource-intensive. Also, beware a common gotcha with AsyncTask: given the asynchronous nature of AsyncTask, it’s possible that an Activity may finish by the time that results come back in. Make sure that you check the status of the Activity before using those results.
Use SharedPreferences for simple keys and values. (Important things to note about SharedPreferences. First, they are cached statically after they are read for the first time. This speeds up access, but can contribute to leaks and memory issues if they are used for anything complex. Second, committing changes rewrites the entire SharedPreferences file from scratch, so small/frequent updates can cause more work than you might expect.)