Wikimedia Apps/Wikipedia/App rearch notes

Some quickie notes on arch plans:

Testing

We want to be much more aggressive about automated unit testing, especially for low-level non-GUI components.

• Android: Yuvi's started some tests in the apps/android/java-mwapi stub repository; add some notes on this
• iOS: look into this more
  • things like code style linting should be runnable on Linux, in theory
  • Actual unit tests (using XCTest framework) need to run on device or in iOS simulator, so needs a Mac
    • [There's some sort of automation you can rig up with OS X Server app installed; I'm fiddling with it on a spare Mac. --brion]
    • In the meantime, at least the tests are real easy to run inside Xcode (hit cmd+U)

Event bus

In working on the Commons uploader native apps we've found that directly linking pieces of the UI together can make future refactoring difficult; a central event bus that lets us broadcast and listen to notification messages would greatly simplify many code interactions.

• Android: looking at otto (based on Guava's EventBus)
• iOS: stock NSNotificationCenter

Networking

The apps will of course make a lot of HTTP(S) requests -- small API hits for configuration and login, large ones for reading articles, and hits to upload and possibly bits for images and scripts/styles within content pages. At least for API fetches and offline precaching, this'll be done from the native side rather than within the web view.

On mobile networks, using SPDY or upcoming HTTP 2.0 modes would be helpful for optimizing small interleaved web requests.

SPDY may not be available yet so actually using it is not a high priority, but using a library that's prepared for it may have advantages.

• Android: looking at okhttp which includes SPDY support.
• iOS: stock NSURLRequest and such don't support SPDY. Investigate support of pipelining, or SPDY alternatives, or a wrapper helper class that we can use to transition easily.

Accounts

While the first generation of the app might skip login to get a minimum viable product out the door, we want to be prepared for it.

We should also plan explicitly to support multiple accounts; it's not that hard, but the data structures should be prepared for it from the beginning or it'll be hard to retrofit. This may seem like a power user feature, but power users are one of our targets for apps.

For credential storage:

• iOS: system Keychain can store arbitrary data by arbitary key; it should not be hard to devise a naming scheme for listing multiple accounts.
• Android: the Android accounts system explicitly allows creating multiple accounts of a given type

Classes and data structures that may have to deal with authentication or per-account data need to accept their user info via some sort of dependency injection; try to avoid relying on global state!

Look into OAuth as a possible replacement for storing passwords on the device, but remember that OAuth isn't always a good fit for apps (keeping an app secret is not possible as it's distributed with the binary).

Telemetry

We had no event logging or data collection on the old app -- this meant the only information we had about its usage was pulling hits from web proxy log streams. Yuck!

We expect to use Wikimedia's EventLogging infrastructure, as we did in the Commons app.

Question: how to pick a good UI for opt-in / opt-out?

Things to measure in addition to clicky-clicky page view counts:

• OS version
• device category?
• screen size (in dp or points)
• screen density
• on android, presence or absence of menu button