These need reshaping by what kind of Androidy component they are, and how they group together.
For now it is just a list of things that may want to get done:
- compile list of files and metadata
- declare on the local subnet that we're running mmm (using zeroconf, ideally)
- listen for others' declarations & keep a list of local devices
- set user preferences for media to gather
- add new 'friend' (and store credentials somewhere, preferably the address book)
- using bluetooth, negotiate setting up an ad-hoc wireless network
- send query representing user 'desires' to device X
- respond to a query with a list of paths (and any other metadata we know)
- show current progress/activity
- show historic or summary of past activity
- request a particular path from a device (likely HTTP)
- serve a particular path to a device (likely HTTP)
- manage free space (inc. delete speculative downloads)
- Set keep/delete on downloads (possibly part of the general UI, not necc our bit)
- Throttle bandwidth
The next immediate task is to rough out the components we're planning to have sorted before the component weekend, and make very basic versions (which might lie) for them.
Enumeration of Android components
(If you're not already familiar with the different classes of Android components and existing APIs, start by watching this introductory overview.)
One breakdown of the above into Android components would look as follows:
Services
Services are long-lived processes that run continuously in the background on an Android device.
- Service Discovery and Advertising Service
- The purpose of this service is to discover other network services that exist on the local network segment(s) – presumably, over a WiFi connection. Ideally this would use ZeroConf, but unless: 1. Android already provides automatic link-local address configuration, and 2. we can find an existing Java implementation, this will be too much work for the time available. For speed, we could possibly take advantage of the XMPP interface provided by Android to discover the state of peers on a user's roster.
- Content-provider service
- Not to be confused with the Content Provider interface that Android provides for accessing and storing media and other data, the purpose of this service is to offer files to other clients on the local network segment(s). This should, for simplicity, probably just use basic HTTP (Possibly with some useful extra headers, like Content-MD5.) Later, we could also explore supporting other protocols, such as DAAP, or BitTorrent.
- Background-download service
- The purpose of this service is to download a given set of URLs in the background. (We should check to see if the WebKit-based browser already provides this functionality.)
Views
Views are short-lived programs designed to provide an interface to some Android Service or data-structure. Note that these Views may be automatically checkpointed and suspended when not being directly used in order to free memory for other processes.
- Background Downloader configuration View
- Allows for URLs to be added or removed from the list of URLs to retrieve in the background, and allow for global retrieval settings – such as bandwidth throttling – to be adjusted.
[… to be continued / edited … ]
