buffer

Buffer Android client. Download v0.1 here.

Why spend time on this:

• I want to try a new app architecture which is described here.
• Try Buffer API.
• And maybe get a job at Buffer :)

Libraries:

• Scribe for OAuth.
• Dagger for dependency injection.
• android-priority-jobqueue for background job management.
• Otto for event bus.
• Retrofit for REST client.
• Picasso for image download and caching.

Feature proposal (aka: things I wish I have time to do and will do if I have time):

• Offline editing for updates, including create new ones, reorder, edit, share, delete, etc…
• Edit and create new updates.
• Cache and prefetch updates.
• Shuffle updates.
• Drag and drop updates to reorder.
• Swipe list view:
  • It may be easier for user to figure out than floating context menu.
  • I implemented this feature but it doesn’t work well with ViewPager, since ViewPager also depends on swipe gestures.
• Polish UI.

Things I learned:

• Buffer API.
• New architecture.
• android-priority-jobqueue. It’s would be great if the library could:
  • Cancel scheduled jobs.
  • Collapse scheduled jobs into 1, using either group id or another id.
• Retrofit.
• Drop-down navigation with custom views.
• Swipe list view.

Job priorities:

SYNC is the lowest one, then PREFETCH and UI. UI is the highest priority since most of the time, user is actively waiting for the data.

Cache policies:

• AccessTokenController: data is cached in memory and persistent store. No other fancy things since we can’t get access token automatically.
• ConfigurationController: data is cached in memory and persistent store.
  • In constructor:
    • Load data from persistent store and save to memory.
  • When data is requested:
    • If it is in memory, it will be returned immediately.
    • If it is not in memory, it will be loaded from network by an UI job and saved. Subscribers will be notified again.
  • Reason for this policy:
    • Configuration is not frequently changed so only make network call if the data is unavailable.
• ProfilesController: data is cached in memory and persistent store, but is always synced with server:
  • In constructor:
    • Load data from persistent store and save to memory.
  • When data is requested:
    • If it is in memory, it will be returned immediately. Then it is loaded from network by a SYNC job and saved. Subscribers will be notified again.
    • If it is not in memory, it will be loaded from network by an UI job and saved. Subscribers will be notified.
  • Reason for this policy:
    • Profiles may be changed from the web interface, but not so frequently.
• UpdatesController: data is cached in memory.
  • When data is requested:
    • If it is in memory, it will be returned immediately.
    • If it is being loaded, an appropriate event will be posted.
    • If it is not in memory and not being loaded, it will be loaded from network by an UI job and saved. Subscribers will be notified.
  • Reason:
    • Updates are changed very frequently, from the app and from web interface. So it’s hard to invalidate cache in persistent store without support from server (or user).

Known bugs:

• JobManager is not meant to be used in context based objects. It should be stored in application object. Jobs then have to subscribe to lifecycle events of their activity and update their internal flag. onRun(), jobs will decide whether they should continue or not, based on the flag.
• To manually show context menu for an list view item, we must call ListView.showContextMenuForChild(childView) instead of Activity.openContextMenu(listView).