Developing Android Client Apps via SyncAdapter

Editor's Notes

1. Introduction. Ask about Android experience, client-server apps and sync adapter knowledge. Session goal.
2. Define session format – ask questions on current slide content. Complex & conceptual question – Q&A block.
3. Persisting in cache – Evernote example;off-line mode - no network; capability to create/delete/edit data offline and changes to be applied when back online
4. What we need to consider to achieve functionality we just mentioned…Network availability – check net before requestPending queue – gather requests if offline, avoid duplicated requests to save battery, like several refreshes, or some upload requests;
5. Rotation symbol near wifi in HTC Sense;Accounts; Configuration for Google services; Multiple accounts!
6. Basic flow suggested by the framework; All UI works only with Content Provider; Sync Adapter works with CP;
7. Let’s see the same picture, but mentioning puzzles we’ll have to implement – 3 items;
8. Network will be used in 3 places – Login activity, Authenticator – token routines, SyncAdapter network operations;You logic should allow to separate upload from download, as well as an option – to separate synced entities. For example: facebook, sync news, but not contacts at the same time;
9. How you usually store your app credentials? Prefs or DB? Prefs fine till you got multiple accounts; both pretty safe;Account can have username, password and extra data associated;
10. Only 2 classes, 1 is almost a dumbstub
11. Usually CP are avoided, I’m not sure why? ORM fashion?Cursor – allows Android to manage window + fetch exact fields and not whole entity; avoid Cursor to entity mapping when not needed;Joins can allow to do effective cross entity fetch;
12. DB versioning based on sql file names;
13. All you code is executed when network is on – but you should be aware that it can be interrupted; Use Sync status to allow repeatable requests;Schedule time intervals, not exact time; intervals may vary;
14. 2 classes, service – is almost a stub; but it is advised to make creation of syncadapter thread safeisAlwaysSyncable – important to make sure it is synced when network available;
15. notifyChange is usually used from Content Provider;
16. If you have existing app – it may be wise to drop some of components;Account and ContentProvider can be implemented as stubs; but they must be registered;
17. Simple – no need to manage threading, define IntentServices, thing of UI callbacks, etc.Framework provides - network check, queue, duplicated requests, etc;Resource – global queue, no channel starvation;Error handling, hard & soft errorsBugs – invalidate tokens; some sync flags ignored. When it works – it’s stable;
18. Any.do – switched a month ago; Evernote – in June-July.
19. Stackoverflow compensates lack of docs;