The Dangers of SharedPreferences: An API Allegory

SharedPreferences has been in the framework and recommended since day 1. However, it has some hidden nuances and pitfalls that can lead to flakiness in production.

Learn when you should use it and how to write robust APIs with it.

Transcript

1. The Dangers of SharedPreferences (An API allegory) Kurt Nelson Uber Mobile Platform @kurtisnelson
3. Let’s talk designing an OS API.
4. Let’s talk designing an OS API immutable API that lasts decades.
5. Designing OS APIs Writing a good API for a library isn’t easy. RxJava is an example of a largish rewrite. But apps pick what version they want to use and bundle.
6. Designing OS APIs Once an OS API has shipped, we’re stuck dealing with it. Flash still isn’t dead 20 years later. Has anyone ever tried to modify a Unix system call?
7. Designing Android Framework APIs The Android Framework is slow moving. Unlike an old Linux kernel running the same software on an unchanging metal machine somewhere, new devices are being shipped running old Android. Google Glass EE still runs KitKat. Even if you are aggressive, you probably still have a minSDK of 21/Lollipop.
8. Designing Android Framework APIs What we write today will not be widely available for a year or two. Hardware is hard and inflexible once shipped, you are building software that is sold on a shelf in a store.
9. Designing Android Framework APIs What we write today will not be widely available for a year or two. Hardware is hard and inflexible once shipped, you are building software that is sold on a shelf in a store. Your job is to calculate all the possible tradeoffs to solving a problem, and then make a decision on behalf of all of your users forever.
10. Designing Android Framework APIs Hide as much implementation complexity from the user while being versatile enough for many use cases. Silently handle as many failure modes as you can while informing your consumer when things do go wrong. Be at least as performant but hopefully better than a naive hand-rolled solution. Operate safely in a shared environment. Make hard engineering decisions on behalf of your user.
11. As they say: Measure twice, cut once.
12. Design for failure, review widely, measure twice, cut once.
14. So you want to persist data on device...
15. syscalls Java File API SQLite Room Square OkIO SharedPreferences Square Tape
16. Brief SQLite Aside
17. SQLite • Fast • Fully async • Configurable ◦ Write-ahead logging • Manually written queries • Migrations • Overhead to open • Plumbing to Rx • Bad for storing byte[]
18. SQLite • Fast • Fully async • Configurable ◦ Write-ahead logging • Manually written queries • Migrations • Overhead to open • Plumbing to Rx • Bad for storing byte[] Room Helps
19. Not good for small values in critical path.
20. syscalls Java File API SQLite Room Square OkIO SharedPreferences Square Tape
21. Most apps use SharedPreferences (and that’s OK)
23. Let’s talk though the problem space of key-value storage.
24. A storage API seems simple.
25. void write(String key, Object stuff); Object read(String key);
26. void write(String key, byte[] stuff); byte[] read(String key);
27. write(String key, byte[] stuff) throws Exception; byte[] read(String key) throws Exception;
28. boolean write(String key, byte[] stuff); byte[] read(String key);
29. initializeAndReadAll(); writeAsync(String key, byte[] stuff); byte[] read(String key);
30. initializeAndReadAll(); writeAsync(String key, byte[] stuff); // Flash is full. byte[] read(String key);
31. initializeAndReadAll(); writeAsync(String key, byte[] stuff); // Cheap flash fails. byte[] read(String key);
32. initializeAndReadAll(); writeAsync(String key, byte[] stuff); // Cheap flash fails // In memory cache masks the failure. byte[] read(key);
33. initializeAndReadAll(); writeAsync(String key, byte[] stuff); // Cheap flash fails. writeAsync(otherKey, otherStuff); // In-memory cache saves the day and both write. byte[] read(String key);
34. initializeAndReadAll(); writeAsync(String key, byte[] stuff); // Cheap flash fails // In memory cache masks the failure. byte[] read(key); // The OS kills your process ???
35. Writes to mobile flash will fail.
36. Writes to mobile flash will fail. (and most of the time no one notices)
37. Why does no one notice?
38. Why does no one notice? The device you are developing on probably has better than average flash. The store is serialized and written as a whole. Any single successful write will persist any pending changes. SharedPreferences (especially in Pie) tries to do the right thing and tell you when things fail.
39. Given entropy and enough users, it will eventually fail.
40. Back to SharedPreferences...
41. apply() has no callback whatsoever. They do ensure changes were committed to memory on return of apply(). Changes may or may not make it to disk.
42. SharedPreferencesImpl Pie
43. SharedPreferencesImpl Pie
44. SharedPreferencesImpl (lollipop-mr1) If using apply, your application will never hear about these types of failure. When using commit, you’ll just get “false” (newer versions are very similar, they have more code tracking timestamps)
45. If you use commit, check the return value.
47. SharedPreferences Initialization (for our curiosity)
48. Let’s use androidxrefs.
50. SharedPreference’s API contract has limitations around failure.
51. I’m sad now.
52. I’m sad now. But this stuff still works for caches right?
53. Kind of. You can’t tell it to stick itself in your app’s cache directory so it’ll count as real data.
54. I’m sad now You can use SharedPreferences for storing non-critical pieces of data...such as preferences.
55. I’m sad now Use Room! Square’s Tape is good for offline storage of transaction data. Just use java.io.File for authentication tokens and such. Okio is nice for bigger files, streaming and/or partial reads. The major image libraries all have great caching layers. If you like being sad, take a look at the source code for AtomicFile!
56. An API allegory (If this tale is the type that keeps you up at night, my team is hiring) The Dangers of SharedPreferences Kurt Nelson Uber Mobile Platform @kurtisnelson kurtn@uber.com