pirogoeth / uniform_imperials Goto Github PK

We should probably flesh out a design doc for the notification transfer protocol -- this includes API style, data packing style, encryption, signing, etc.

Mobile app view implementations should be done mostly with Android's XML view format along with supplemental classes for adapting models into views (ie., RecyclerViewAdapter, etc).

This requires relatively close integration with the models team (#13, #8) for loading proper data from models into the adapters.

Task details:

• Assigned: @mh1723
• Assisting:
  • @gustavomm
  • @pirogoeth

As we work on the presentation and docs, should we have some sort of automated deployment for the code so we can view our work "in staging" as we go?

Use Docbase to generate/deploy docs to gh-pages so there's always a set of docs getting generated and available in an easy to read and pretty format.

Set up the scaffolding for the Reveal.js base project in /docs/presentation. Figure out where/how we're going to host this and possibly set up auto-deploy for the presentation files on a subdomain somewhere.

The server-side notification dispatcher will handle registration of devices and channels, as well as notification routing between devices via a target module (GCM, brokering, etc).

Implementation details:

• Language: Python 2/3
• ORM: Peewee
• Task broker: Huey
• Web framework: Bottle + Restify

Task details:

• Assigned: @pirogoeth
• Assisting:
  • @gustavomm
  • @jdd932

We should integrate with some sort of CI to test our code as we push to develop -- makes ensuring that a PR to master will not introduce bugs!

Options:

• Travis CI (hosted, free for open-source)
• Drone CI (self-hosted, already have a copy running)
• Appveyor, Semaphore, ...?

One of the things we really need before you can move much further with development is models. It's hard to design an interface if we don't have data that matches what we're trying to view..

Some models will be slightly different than others. Some models will load data from Android's SQLite store, some will load data purely from the REST API provided by the dispatcher. Some models will do hybrid fetching and caching to the local database. Here's a preliminary breakdown:

Local-only:

• Historical notifications (configurable limit)
• Settings
• Application white/blacklists

REST-only:

• Channel detailed information
• Outbound notification

Hybrid REST+LC:

• Active devices

Begin the structure for the dispatcher part of the project. This requires that we decide what language the thing will be coded in, first. We don't need a web front-end, just a REST-ish API. This makes things considerably easier.

One of the requirements for the project is to present an interface mockup. This is obviously something that is very useful for our end-project, but we should definitely try to sketch out something soon to get this in the works.

Split up the presentation tasks between group members. Everyone should have an equal part.

Within the presentation directory, we should have a series of Markdown documents representing our slides. I feel that this is considerably easier than trying to modify and format Markdown inside HTML.

Mobile app model implementations according to presentation and following dispatcher return spec.

Preliminary response structure for channel and device models is documented in the server-side code: /server/src/unwind/routes/{channel,device}.py.

Soon, server-side models will be complete enough to structure the mobile models as well.

Implementation details:

• Model base: Requery

Task details:

• Assigned: @gustavomm
• Assisting: @pirogoeth

Android's built-in SQLite library is old and slow, so we should use the "new" versions provided by Requery:

# in build.gradle
dependencies {
    compile 'io.requery:sqlite-android:3.12.0'
}

This makes sense considering we're also going to use Requery as our ORM in the mobile app.