The quick & dirty and wrong approach Activity Adapter Thread - worker Rest Method Processor Memory
Android Laws Foreground Apps. must have the resources they need Visible activity or running service. Should keep running. As long as it does not break #1 Background Apps kept in memory to reduce start up and latency time. As long as it does not break #1 or #2.
Implications: Android may (and will) shut down your process. Background apps should be ready to die Handle onPause() and onStop(). Background apps should be “thin”. Being good android citizen increases your chances to live longer.
The quick & dirty and wrong approach Killed during transaction Request may or may not executed on server side. No persistence data High latency. Waste of bandwidth. Waste of battery
Service Activity Data Processor Storage Rest Method Service
Data Processor Holds a “mirror” of the data in the server. Runs before and after each transaction. Before Post / Put: Prepare transaction data Create DB row with status “updating” After Post / Put: Clear the “updating” status.
Data Processor Before Delete; Set status to “DELETING” After Delete: Delete DB row. Before GET After GET Update DB
Service Activity Wrapper Data Processor Storage Rest Method Service
Service Wrapper Singletone. Exposes simple async API to be used by UI. Upon service request: Check if method is already pending. Create intent. Generate req id. Hold binder. Return Req id. Handle callback from the service.
Handling service callback - Activity Activity has its own lifecycle. Activity is still active when the response arrives. Activity is paused, resumed and then the response arrives. Activity is paused with the response arrives, and than resumed. Adapter.notifyDataSetChanged() when needed.
Summary Dont implement REST method in Activity / UI layer. Long running ops should run inside a service And dont forget worker thread. Persist early, persist often Dont download what you already know. Dont make me go crazy. Sync adapter for non critical BG operations.