The document outlines the architecture of an Android REST client, emphasizing the importance of correctly handling background apps and ensuring efficient resource management. It proposes solutions including using services and content providers for handling data transactions and maintaining responsiveness. Key recommendations include avoiding long-running operations in the UI layer and persisting data early to improve application performance.

1. Android REST Client Architecture

2. About me
Independent Android Consultant and Trainer
Co-founder of IAA
GDG & GDE
+Ran Nachmany

3. Rest Architecture
Client and server
Client send request get or change resource.
Twitter, facebook, Google, flight schedule etc.

4. The quick & dirty approach
Activity Adapter
Thread - worker
Rest Method Processor
Memory

5. The quick & dirty and wrong approach
Activity Adapter
Thread - worker
Rest Method Processor
Memory

6. 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.

7. 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.

8. 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

10. Solution #1: Service API

11. Service
Service is designed to run in the background.
Has no user interface.
Runs on main thread (i.e. UI thread)
You still need to create a worker thread.

12. Service
Activity
Data Processor Storage
Rest Method
Service

13. Activity ↔ Service interface
Starting the service:
Activity.startService(Intent I).
Initiating transactions and getting results:
Binder interface.
Intent interface.

14. Activity ↔ Service interface
Start Service

15. Binder Interface - Activity

16. Binder Interface - Activity

17. Binder Interface – Service side

18. Intent Interface – Activity side

19. Intent Interface – Service side

20. Service
Activity
Data Processor Storage
Rest Method
Service

21. 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.

22. Data Processor
Before Delete;
Set status to “DELETING”
After Delete:
Delete DB row.
Before GET
After GET
Update DB

23. Service
Activity
Wrapper
Data Processor Storage
Rest Method
Service

24. 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.

25. 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.

26. Solution #2: Content Provider

27. Content Provider
Mechanism to share /transfer data across boundries.
Usually used to share data between apps.

28. Activity & Cursor Adapter
Content Provider
Wrapper
Service
Data Processor
Rest Method

29. Activity & Cursor Adapter
1. Query (insert /
update/ delete)
Content Provider
Wrapper
Service
Data Processor
Rest Method

30. Activity & Cursor Adapter
1. Query (insert /
update/ delete)
Content Provider
2. Start (intent)
Wrapper
Service
Data Processor
Rest Method

31. Activity & Cursor Adapter
1. Query (insert /
update/ delete)
Content Provider
2. Start (intent)
Wrapper
3. Start Service
Service
Data Processor
Rest Method

32. Activity & Cursor Adapter
1. Query (insert /
update/ delete)
Content Provider
2. Start (intent)
Wrapper
3. Start Service
Service
Data Processor
4. Execute method
Rest Method

33. Activity & Cursor Adapter
1. Query (insert /
update/ delete)
Content Provider
2. Start (intent)
Wrapper
3. Start Service
Service
Data Processor
4. Execute method 5. Process respons
Rest Method

34. Activity & Cursor Adapter
1. Query (insert /
update/ delete)
Content Provider
2. Start (intent)
Wrapper
3. Start Service
6. Insert/ update/
Service delete
Data Processor
4. Execute method 5. Process respons
Rest Method

35. Activity & Cursor Adapter
1. Query (insert / 7. Notify Content
update/ delete) Observer
Content Provider
2. Start (intent)
Wrapper
3. Start Service
6. Insert/ update/
Service delete
Data Processor
4. Execute method 5. Process respons
Rest Method

36. Activity & Cursor Adapter
1. Query (insert / 7. Notify Content 8. Query
update/ delete) Observer
Content Provider
2. Start (intent)
Wrapper
3. Start Service
6. Insert/ update/
Service delete
Data Processor
4. Execute method 5. Process respons
Rest Method

37. Solution #3: Content Provider + Sync
Adapter

38. Activity & Cursor Adapter
Content Provider
Sync Adapter
Data Processor
Rest Method

39. Summary
Don't implement REST method in Activity / UI
layer.
Long running ops should run inside a service
And don't forget worker thread.
Persist early, persist often
Don't download what you already know.
Don't make me go crazy.
Sync adapter for non critical BG operations.

40. Thank You