Mobile Device APIs Use Cases

From MemberWiki

Jump to: navigation, search

This wiki page is one of several wiki pages for the Mobile TF work on Mobile Device APIs. Here are the pages:


Contents

Introduction

The potential applications of Device APIs are wide-ranging. This document aims to identify some motivating examples, but also to capture the multiple possible aspects of device API use by presenting and classifying use cases.

Scope

The scope of this discussion is characterised by:

  • the range of environments in which device APIs might be used: we are including any runtime or execution environment that uses the web formats that are considered to be within the scope of the OpenAjax Alliance - these are the W3C-standardised markup languages ([X]HTML, SVG, SMIL, CSS) and any of the scripting languages that are usable in conjunction with them (ie predominantly Javascript but also possibly VBScript and others).
  • the features that are considered to be "device features" accessible by a "device API": we are considering any local function or service on a device (such as a mobile phone) that is not formalised within the document or window DOMs.

The environments within scope include:

  • conventional browsers (ie applications that provide access to remotely or locally hosted pages, and provide the user the explicit means to navigate to them by bookmark and/or URL entry);
  • "web runtimes" (ie execution environments that run "applications" or "phone-top widgets" that are authored using web formats but whose invocation and lifecycle model is presented to the user in a manner more similar to other conventionally installed applications);
  • any hybrid of these approaches, eg where remotely hosted pages run full-screen, or packaged widgets that are presented as interactive fragments within a larger web application, etc.

Custom DOM environments (eg Yahoo! widgets) are not explicitly considered, but many of the use cases (and associated specification and implementation issues) are equally applicable in these cases.

The device features within scope include:

  • any local service that is available on the device (and typically accessed using local "conventional" applications), such as phone services (calls, messaging, SIM), PIM (contacts, calendar, todo etc), local connectivity (Bluetooth, etc), location, etc;
  • any services that relocate services that would normally be remote to the local device, such as data persistence (eg per-domain database), content persistence (eg programmable local http store);
  • any services, made available via APIs, that allow the content to adapt better to the form factor or UI constraints of the target device, that are not available via the existing document or window DOM (such as soft-key support, input method support, etc).

Web APIs are not considered to be within scope and we are not attempting to deal with them (although, again, some of the same security considerations may apply).

Categories of use cases

There are many possible scenarios in which device API access might be used, and the manner of their use differs by multiple criteria. In order to try to characterise this multi-dimensioned space, we consider different categories of use case. These are explained below.

Application deployment model

Ajax provides a visualization framework, programming toolkit, and network protocol for applications. Applications can selectively use these Ajax techniques to create brand new applications as well as replacements for existing non-Ajax applications. The motivation for creating such applications could be one or more of the objectives identified in Mobile Device APIs Objectives. An application is a means for the end user to interact with a piece of software. There are two ways to dice Ajax applications. Our primary way to look at applications is in terms of the level of isolation among them. The second way is to view the coarseness of user interfaces - from general purpose ones to very targeted ones. This section categorizes the range of application use cases that may involve the use of Ajax techniques.

Using these two dimensions - isolation level and full-ness of the interface - the four deployment models under consideration are:

  • A single process shared by multiple applications
    • Full-frame applications - e.g., conventional Web-sites used from Web browsers
    • Mini applications - e.g., widgets deployed in a Web runtime
  • Separate processes for each application
    • Embedded Ajax application - e.g., Web controls embedded inside native non-Ajax applications
    • Native Ajax application - e.g., Site-specific browser applications such as standalone GMail

Across use cases, the Ajax APIs, programming language syntax, and interaction protocols remain the same. A system vendor may, however, constrain the device services made available to specific applications through, say, security policies. Suitable installation and maintenance mechanisms are needed by each of the four different deployment models.

  1. Full-frame Web sites
    • (Need to review this language) Full-frame applications are deployed only the server and the Ajax toolkit (which includes a Web browser) fetches all the necessary resources to render a complete application on the client. If these resources change on the server, they are automatically fetched by the client. All that is required to launch the application is the URL of the application.
  2. Web runtime-based widgets
    • (Need to review this language) Mini applications are deployed on the client using resources from a server. A system may disallow certain mini applications or require user confirmation for installation and granting certain permissions. This practice is similar to other application models requiring interactive confirmation of installation, such as Java (MIDP).
  3. Embedded Web controls inside native applications
    • (Need to review this language) An embedded Ajax application requires a host native application to be installed. This implies general native application installation requirements apply.
  4. Site specific browser applications (SSBA)
    • (Need to review this language) A native Ajax application can be installed by simply configuring a URL for the application. Native shortcuts may be used to enable quick launch for previously installed applications. Besides these, the same mechanisms available to non-Ajax native applications should apply here. For example, security may not be any stricter for native Ajax application than it is for non-Ajax native applications.

Applications have the ability to introspect the Ajax toolkit to find out what APIs (and their versions) are supported as well as whether they have access to invoke those APIs. Ajax toolkits also may inspect the applications to determine the suitability of granting permissions to them based on user configuration. For example, if an application can be ascertained to be authored by a trusted party, greater permissions may be granted to them, even without additional user confirmation.

Application construction model

These are use cases that differ according to how the application is constructed, including:

  • single-origin applications, in which all of the markup and code is served from the same location (eg from the same domain, or from within a single locally installed package);*
  • multiple-origin applications, in which the application makes use of libraries (or interactive fragments) served from elsewhere. For example, and application might use a third-party Javascript library which itself uses device APIs.

These two approaches might also have different implications for how device APIs are made available, and how selective access to those APIs is enforced. For single-origin applications, all code can be assumed to have originated from the same site as any markup. Security frameworks designed only to deal with this case, and possibly also their user interaction, might be simpler than those that deal with the multiple-origin case.

Depending on the implementation language and the architecture of the application, it might be valid to determine permissions on the basis of either the origin of the particular code calling a device API, or the origin of the containing page, or some combination of factors, in the muliple-origin case. This relates to the wider issues of secure creation of cross-domain mashups in general.

Authority

In general we are assuming that an execution environment (ie browser or web runtime) operates under some security framework that selectively grants permission to perform a security-relevant operation based on (some combination of):

  • site origin (possibly modified by some perception of the reliability of the indicated origin);
  • the operation being attempted (possibly also including some parameters relating to the actual attempt, such as the destination domain for a network connection attempt);
  • (interactively granted) user permission;
  • current context (eg the type of connection, whether roaming, etc);

based on some defined security policy.

Here we consider use cases that differ according to:

  • who defines that security policy: for example, whether by the service provider (eg network operator), the user, application provider, or some combination;
  • how, when and where that policy is configured: for example, whether the configuration is locally stored on the device itself, or queried online, etc.

It is possible that different parts of the policy can validly be owned by different authorities and maintained using different mechanisms.

Usage scenarios

As mentioned above, there is often a blurred line between conventional browsing and installable applications (widgets or device-resident applications). It is important to keep this blurring in mind in reviewing the following sections, which attempts to break down usage scenarios based on whether the application runs in the Web browser or is installed on the device.

Browser-based applications

So far, only one category within the "browser-based applications" bucket.

Normal web page that is made more useful due to integration with mobile device APIs

Examples

Countless examples. Here are a few:

  • Web search page that is able to deliver location-specific search results due to integration with device APIs that provide current location in terms of latitude and longitude. For example, if you search for "expresso", the search engine might produce a list of nearby expresso bars; of when delivering Weather information to the user the forecast could be contextualised based on the user's actual location
  • Web advertisement includes a phone number. If the user clicks on the phone number, that number is dialed.
  • Browser-based chat application whose UI includes a button that takes invokes device APIs to take a picture and instantly uploads it to the chat session.
  • Browser-based email system that integrates with local mailboxes so that mail can be viewed even when the phone is disconnected from the Web (or running the locally installed mail client)
  • Web site with a large collection of user-contributed videos that allows you to SMS the URL of your favorite video to people who are listed in the contact list that is stored on your phone.
  • Web service that enables the user to select a contact from the Address Book and fetch a map for that contact's address
  • Hotel website able to add the room booking details to the user's Calendar
  • Download a song or video from a Web page to experience later (this one is also listed under widget category)
  • Make a hotel reservation and store the reservation and confirmation number locally (this was mentioned in 2008-03-06 phone call, but don't you typically get an email with this info?)

Requirements that fall out

Simplified grossly:

  1. Provide JavaScript APIs so that authorized web pages can invoke device services
  2. Provide a security management mechanism so that only web pages that are properly authorized can invoke those services

More detailed requirements:

  1. Some of the workflows require a data persistence mechanism.
  2. See below for security requirements

Security implications

Super obvious security implications

This set of scenarios has major security implications. It breaks through the browser same-domain security model where each Web page is isolated from Web pages from different domains and isolated from anything that is available on the user's machine (exception: cookies and cache, but these are sandboxed on a per-domain basis). Note: the browser treats the local machine as its own separate domain.

Quick tutorial in how desktop browsers handle similar situations

Desktop browsers already have various features that allow certain features to cross the same-domain barrier. For example, it is possible to upload an image from your local machine to a Web site or install plugins into your browser (e.g., Flash) that are (in effect) granted full access to your local system. In general, popular browsers require an explicit user opt-in before allowing these features to be used. For image uploading, the user has to actually click an "upload" button before the upload occurs. For plugins, the user typically is presented with some sort of warning dialog as part of the install process and must click OK somewhere in the process. Note that with plugins the user clicks OK once, which in effect allows the plugin to have full and perpetual system access.

The browser security model is largely based on trust between a user and a particular domain. Some desktop browsers provide UI such that the user can identify particular sites as being "trusted" (with special access rights) or in the "trusted group" of sites (where the trusted group of sites shares similar access rights).

Security requirements

From a security perspective, somehow or other the user needs to be notified, or be forced to authorize, when a Web page asks for the right to access a device API.

During the telecon of 2008-03-06, there was discussion that a good candidate for an approach to allowing web page access to device APIs would be based on the user trusting a particular domain and granting access to that domain. Following on to that discussion was the observation that perhaps the same security model applies to Web pages and mobile widgets. You trust foo.com to access device APIs whether using the Web page or the widget.

The follow-on question is granularity of such requests. Should it be that a Web page simply asks for rights to all APIs or can this be selective?

Installable applications

The following two groupings of use cases share the fact that either the device ships with a particular "application" or the user must actively choose to install a particular "application" (where a mobile widget is considered a form of "application").

Installable mobile widgets

Examples

For these following use cases, we are assuming that the installable mobile widget uses the Web Runtime engine (i.e., browser technologies such as HTML and JavaScript), communicates to a single back-end server over HTTP, and either shipped with the device and therefore was implicitly approved by the device manufacturer to have access to device APIs or was installed by the user who (explicitly or implicitly) approved access to device APIs.

Countless examples. Here are a few:

  • Weather widget, which shows the current weather and forecast for your current geographic location
  • Traffic widget. (Similar to the above, except local traffic information)
  • Social networking widget. Provides similar services as the Web version of the social networking site, but doesn't require launching the browser, and integrates with your PIM (including contact list). Allows you to instantly send SMS's or MMS's (images and videos) to your friends or start a phone call instantly in response to news from the social networking site.
  • Custom phone response widget. The widget intercepts all phone calls that are inbound to the phone and shows an alternate UI for picking up the call, such as displaying the picture of the caller and offering a custom ring tone. (Obviously, ring tone technology is available through other means, also.)
  • Download a song or video from a Web page to experience later (this one is also listed under browser category)

Requirements that fall out

(not yet written)

Security implications

One approach is that, by installing the mobile widget, the user has granted full access rights to the mobile widget to anything on the system. This is simple, but obviously extremely dangerous if the user can be tricked into installing a malicious widget.

During 2008-03-06 telecon, we talked about how perhaps the same security model applies to Web pages and mobile widgets. You trust foo.com to access device APIs whether using the Web page or the widget.

Device-resident applications

Examples

For these following use cases, we are assuming that the device-resident application uses the Web Runtime engine (i.e., browser technologies such as HTML and JavaScript), and either shipped with the device and therefore was implicitly approved by the device manufacturer to have access to device APIs or was installed by the user who (explicitly or implicitly) approved access to device APIs.

Again, there are countless examples. A key thing is that the device manufacturer is able to use the browser engine to implement any or all of the user interface that ships standards with the device. Therefore, all of the following applications could be implemented with the Web Runtime:

  • the front screen that appears after the device is turned on and becomes ready to do things
  • the contact list application
  • the mail application
  • the mapping application
  • the SMS application
  • the camera application and the photo viewing application
  • the user interface for the web browser (e.g., back, forward, goto url)

etc.

Here are a couple of VF contributed examples

Embedded web controls inside native applications
Integrating the web within native applications such as the dialer, the address book or any other third party application. An example of this would be adding a web control showing a map for each contact the user has within their address book. This way the user can browse the address book, select a contact and easily get a map showing the contact home address (which the user has stored within the device) and how to get there from their current location.
Native Ajax applications
Native mobile device applications (also known as Site Specific Browser Applications) which are tailored to web sites such as Flickr, Facebook or LinkedIn. These applications get the most of these web sites by integrating the device data and functionality with the site. An example of this sort of applications could be a "Flickr native Ajax application" this application would automatically connect to Flickr on launching, allowing the user to search Flickr data base of pictures, add comments to pictures as usual but also upload her own pictures seamlessly from her device multimedia gallery, launch the camera to upload a new picture on the move and automatically add location information as a tag.

Requirements that fall out

(not yet written)

Security implications

I am pretty sure that C++ mobile applications have full access to all device APIs. Therefore, one would think that mobile applications that are written with the "Web Runtime" (i.e., HTML+JavaScript) would be treated in the same way, which means full access to all device APIs.

Vodafone-contributed use cases

Vodafone submitted these use cases that they developed as an aid to determine which APIs (and detailed features within those APIs) have the widest applicability.

This note is a reminder that we need to study these use cases and make sure the requirements page captures all of the requirements driven by these use cases. Once the requirements have been updated, please remove this note.

Contacts

CO1 - Birthday reminder

Description

  • [X] This use case describes how a Widget can remind a user of upcoming birthdays or anniversaries and suggest a gift.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Gifts recommendation service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The widget gets launched whenever an upcoming birthday is detected.
  • [X] 2- The widget gets the contact details (sex, age, home address...) and queries the gift recommendation service to get a suggestion.
  • [X] 3- The user gets a notification an a suggestion for a gift and related information.
  • [X] 4- The user can click to browse the associated gift shop web site, send an e-mail, text or call to retrieve more information or buy it.

Interfaces involved

  • [X] Contacts
    • [X] Get contact details
    • [_] Name
    • [_] Birthday
    • [_] Sex
    • [_] Home Address
  • [X] Messaging
    • [X] Launch SMS editor
    • [X] Launch E-mail editor
    • [X] Send SMS
    • [X] Send E-mail
  • [X] Calls
    • [X] Launch dialer
  • [X] Phone System
    • [X] Vibrate
    • [X] Beep

Messaging

ME1 - Frequent Messaging List

Description

  • [X] This use case describes how a Widget can create a frequent messaging list depending on the week day, the location, the time...

Actors

  • [X] User
  • [X] Widget or Active Web Page

Pre-conditions

Post-conditions

Flow

  • [X] 1- The widget runs in the background and monitors any incoming call retrieving location...
  • [X] 2- The Widget stores these data and uses it to provide a frequent call list depending on the data.
  • [X] 3- The user can use this list to start a new call.

Interfaces involved

  • [X] Calls
    • [X] Launch dialer
    • [X] Get incoming calls list
    • [X] Get outgoing calls list
    • [X] Get incoming call details
    • [_] Source Contact
    • [_] Date
    • [_] Time
    • [X] Get outgoing call details
    • [_] Destination Contact
    • [_] Date
    • [_] Time
  • [X] Phone System
    • [X] Date
    • [X] Time
    • [X] Time Zone
  • [X] Location
    • [X] Get Current Location
  • [X] Persistent Storage
  • [X] Save Data
  • [X] Load Data

ME2 - Automatic SMS, EMail sending

Description

  • [X] This use case describes how a Widget can automatically know when the user is busy and reject any incoming call and send an apologizing message to the caller.

Actors

  • [X] User
  • [X] Widget or Active Web Page

Pre-conditions

Post-conditions

Flow

  • [X] 1- The widget runs in the background and detectd any incoming call.
  • [X] 2- If a call is detected the widget checks whether a meeting is taking place of the device is running in silent mode.
  • [X] 3- The widget rejects the call if any of the above is true. And sends an apologizing message to the caller.
  • [X] 3- The user can create a VIP list of people whose calls are never rejected.

Interfaces involved

  • [X] Calls
    • [X] Incoming Call event handler
    • [X] Get incoming call details
    • [_] Source Contact
  • [X] Messaging
    • [X] Send SMS
    • [X] Send Emal
  • [X] Agenda
    • [X] Get appointment list
    • [X] Get appointment details
    • [_] Start Date
    • [_] Start Time
    • [_] End Date
    • [_] End Time
  • [X] Persistent Storage
    • [X] Save Data
    • [X] Load Data
  • [X] Phone System
    • [X] Date
    • [X] Time
    • [X] Get Mode
    • [_] Silent
    • [_] Vibration
    • [_] Normal
    • [X] Set Mode
    • [_] Silent
    • [_] Vibration
    • [_] Normal
    • [X] Beep
    • [X] Vibrate
  • [X] Contacts
    • [X] Get contacts list
    • [X] Get contact details
    • [_] Telephone number
    • [_] Name
    • [_] Last name

ME3 - Sending Web Objects

Description

  • [X] This use case describes how a Widget or an Active Web Page can provide a user with a way to send content (images, urls, text...) to any other contact.

Actors

  • [X] User
  • [X] Widget or Active Web Page

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The user detects content and wants that she wants to share with a contact so clicks on "Share this"...
  • [X] 3- The widget sends a message containing the content selected by the user.

Interfaces involved

  • [X] Messaging
    • [X] Send SMS
    • [_] Destination
    • [_] Text
    • [X] Send MMS
    • [_] Destination
    • [_] Subject
    • [_] Text
    • [_] Attachments
    • [X] Send E-mail
    • [_] To
    • [_] From
    • [_] CC
    • [_] CCO
    • [_] Subject
    • [_] Message
    • [_] Attachments
  • [X] Contacts
  • [X] Get contacts list
  • [X] Get Contact details
  • [_] Name
  • [_] Last Name
  • [_] Telephone number
  • [_] EMail

ME4 - Autoblog

Description

  • [X] This use case describes how a Widget can be used to automatically create a blog containing all the messages and calls.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Autoblog web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget and it runs in back ground listening for incoming and outgoing messages and calls.
  • [X] 2- Whenever an incoming or outgoing message or call is detected the widget retrieves the data and sends it to the user personal blog.
  • [X] 3- The user can connect to her blog to check her communications history.

Interfaces involved

  • [X] Messaging
    • [X] Incoming SMS event handler
    • [X] Incoming MMS event handler
    • [X] Incoming E-mail event handler
    • [X] Outgoing SMS event handler
    • [X] Outgoing MMS event handler
    • [X] Outgoing E-mail event handler
    • [X] Get incoming SMS details
    • [X] Get incoming MMS details
    • [X] Get incoming E-mail details
    • [X] Get outgoing SMS details
    • [X] Get outgoing MMS details
    • [X] Get outgoing E-mail details
    • [X] Get incoming SMS list
    • [X] Get incoming MMS list
    • [X] Get incoming E-mail list
    • [X] Get outgoing SMS list
    • [X] Get outgoing MMS list
    • [X] Get outgoing E-mail list
  • [X] Calls
    • [X] Incoming call event handler
    • [X] Outgoing call event handler
    • [X] Get incoming call details
    • [X] Get outgoing call details
    • [X] Get incoming call list
    • [X] Get outgoing call list
  • [X] Contacts
    • [X] Get contacts list
    • [X] Get Contact details
    • [_] Name
    • [_] Last Name
    • [_] Telephone number
    • [_] Email

Capability Discovery

CAP1 - Capability Discovery

Description

  • [X] This use case describes how a Widget or an Active Web Application should be able to check which scriptable APIs are available in a device, to prevent malfunction.

Actors

  • [X] User
  • [X] Widget or Active Web Page

Pre-conditions

Post-conditions

Flow

  • [X] 1- Upon installation the widget or Active Web Page checks its configuration file to check which of the scriptable APIs it is going to need.
  • [X] 2- Upon installation the widget or Active Web Page checks whether the device web runtime supports the set of needed APIs. If a critical API is missing installation fails.
  • [X] 3- If there are no critical APIs missing the installation succeeds.
  • [X] 4- During run time the widget should be able to check if any optional API is present and run accordingly to that.

Interfaces involved

  • [X] Capability Discovery
    • [X] Get critical needed APIs
    • [X] Get supported APIs
    • [X] Is API supported?

Calls

CA1 - Click to call

Description

  • [X] This use case describes how a Widget or an Active Web Page can add a "click to call feature" to any advert or banner.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Banner service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The Widget shows a banner or an ad.
  • [X] 3- The user clicks on the banner because she is interested in the offer.
  • [X] 4- The Widget sets up a call.

Interfaces involved

  • [X] Calls
    • [X] Launch dialer

CA2 - Frequent Calls List

Description

  • [X] This use case describes how a Widget can create a frequent calls log depending on the week day, the location, the time...

Actors

  • [X] User
  • [X] Widget or Active Web Page

Pre-conditions

Post-conditions

Flow

  • [X] 1- The widget runs in the background and monitors any incoming call retrieving location...
  • [X] 2- The Widget stores location of each incoming and outgoing call and uses it to provide a frequent call list depending on the data.
  • [X] 3- The user can use this list to start a new call.

Interfaces involved

  • [X] Calls
    • [X] Launch dialer
    • [X] Get incoming calls list
    • [X] Get outgoing calls list
    • [X] Get incoming call details
    • [_] Source Contact
    • [_] Date
    • [_] Time
    • [X] Get outgoing call details
    • [_] Destination Contact
    • [_] Date
    • [_] Time
  • [X] Phone System
    • [X] Date
    • [X] Time
    • [X] Time Zone
  • [X] Location
    • [X] Get Current Location
  • [X] Persistent Storage
  • [X] Save Data
  • [X] Load Data

Notes (Tasks)

NO1 - Family shopping list

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a family with a common shopping list.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Family shopping list back-end service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The widget connects to a Family shopping list back-end service to update the notes in the device.
  • [X] 2- The user can use the widget to add items to a shopping list locally in her own notes that will afterwards be uploaded to the Family shopping list back-end service by the widget.

Interfaces involved

  • [X] Notes (tasks)
  • [X] Get notes-task list
  • [X] Get note-task details
  • [_] Deadline
  • [_] Responsible
  • [_] Description
  • [X] iority
  • [X] Create a note-task
  • [X] Update a note-task
  • [X] Delete a note-task

Agenda

AG1 - Appointment Weather

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a user with weather forecast information for a given appointment (location and date).

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Weather web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The Widget or Active Web Page retrieves the list of appointments along with their associated information such as location, date and time, etc and shows it.
  • [X] 3- The user selects and appointment and clicks on "Get Forecast".
  • [X] 4- The Widget sends location and date / time to the Weather web service, retrieves a forecast and shows it.

Interfaces involved

  • [X] Agenda
  • [X] Get list of appointments
  • [X] Get appointment details
  • [_] Subject
  • [_] Date and time
  • [_] Location

AG2 - Take me to the meeting

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a user with maps and information to get to an appointment location.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Map web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user browses to the Active Web Page or the Widgets automatically gets launched as a meeting approaches.
  • [X] 2- The Widget or Active Web Page retrieves the location information of the appointment and the device real location.
  • [X] 3- The Widget creates a route linking real and appointment location by means of a Mapping and Routing web service, the route gets displayed.
  • [X] 4- The route is periodically updated...
  • [X] 5- The user closes the Widget whenever she gets to the meeting location.

Interfaces involved

  • [X] Agenda
    • [X] Get list of appointments
    • [X] Get appointment details
    • [_] Subject
    • [_] Date and time
    • [_] Location
    • [X] Appointment approaching event handler
  • [X] Location
    • [X] Get current location

AG3 - Family Calendar

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a family with a common calendar merging all the family members appointments.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Family calendar back-end service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The widget merges the user local appointments with the rest of the family appointments (new appointment requests could show up here).
  • [X] 3- The user can ask the widget to store locally all or part of the rest of the family appointments
  • [X] 4- The user can view, create, edit or delete any appointment.
  • [X] 5- The widget will then create, update or delete the appointment or note both locally and in the family calendar.

Interfaces involved

  • [X] Agenda
    • [X] Get list of appointments
    • [X] Get appointment details
    • [_] Subject
    • [_] Attendees
    • [_] Date and time
    • [_] Location
    • [X] Appointment approaching event handler
    • [X] Dismiss appointment reminder
    • [X] Accept appointment reminder
    • [X] Create appointment
    • [X] Delete appointment
    • [X] Update appointment
    • [X] Dismiss appointment request
    • [X] Accept appointment request

Connectivity

CON1 - Manage connections on special situations (roaming, low battery...)

Description

  • [X] This use case describes how a Widget could monitor the system status (roaming, battery...) to manage how and if connections are allowed.

Actors

  • [X] User
  • [X] Widget or Active Web Page

Pre-conditions

Post-conditions

Flow

  • [X] 1- The widget runs on background and monitors the device status.
  • [X] 2- Each new connection is filtered depending on a user policy.

Interfaces involved

  • [X] Connectivity
    • [X] New connection event handler
    • [X] Put down connection
    • [X] Create connection
  • [X] Phone System
  • [X] Roaming event handler
  • [X] Home event handler
  • [X] Get IsRoaming
  • [X] Get IsHome
  • [X] Get Battery level
  • [X] Low battery event handler

Gallery

GA1 - Uploading files to social networks

Description

  • [X] This use case describes how a Widget or an Active Web Page could be used to upload any content to any social network.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Social Network

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The user can then select to upload a new file (i.e. a new picture for her avatar or something she wants to share).
  • [X] 3. The widget lists all the files within the Gallery or gives the user the option to take a new picture using the camera.
  • [X] 4- The user selects a file a clicks on "Upload"
  • [X] 5- The user can add metadata to the file, the widget can also include data automatically (i.e. location)
  • [X] 6- The widget sends it.

Interfaces involved

  • [X] Gallery
    • [X] List images
    • [X] Get image metadata
    • [X] Set image metadata
    • [X] Get image details
    • [X] Get image bytes
  • [X] Location
    • [X] Get Current Location
  • [X] Camera
    • [X] Launch camera application
    • [X] Take picture
    • [X] Get picture bytes

Location

LOC1 - Contact Map

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a user with maps and information on where each one of her contacts live an route information to get there.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Map web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The Widget or Active Web Page retrieves the contact list along with their home address information
  • [X] 3- The user selects a contact an clicks on "Get Map"
  • [X] 4- The Widget or Active Web Page geo-locates the contact home address and retrieves and shows a map for it using a mapping web service.
  • [X] 5- The user clicks on "Directions" to get a route linking its real location and its contact home address.
  • [X] 6- The Widget retrieves the device real location.
  • [X] 7- The Widget sends location along with the contact home address to the Routing web service to get a route and display it.

Interfaces involved

  • [X] Contacts
    • [X] Get list of contacts
    • [X] Get contact details
    • [_] Name
    • [_] Home Address
  • [X] Location
    • [X] Get current location
    • [_] Longitude
    • [_] Latitude

LOC2 - Real Weather

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a user with weather information dependant on its real location.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Weather web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The Widget or Active Web Page retrieves the current device location.
  • [X] 3- The Widget or Active Web Page queries the Weather web service using location as one of the criteria, gets the forecast and displays it.

Interfaces involved

  • [X] Location
    • [X] Get current location

LOC3 - Flickr geo tagging

Description

  • [X] This use case describes how a Widget or an Active Web Application can be used to take pictures or browse the gallery and upload content to sites like fickr automatically adding location information.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Flickr web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The Widget displays a list of pictures from the device Gallery and provides the user with the option to launch the camera and take a picture.
  • [X] 3- The user selects one of the gallery pictures or takes a new picture and clicks on "Upload to Flickr".
  • [X] 4- The Widget uploads the picture along with location information concerning where it was taken or where the device was when it was uploaded.

Interfaces involved

  • [X] Location
    • [X] Get current location
  • [X] Gallery
    • [X] List images
    • [X] Get image metadata
    • [X] Set image metadata
  • [X] Camera
    • [X] Launch camera application
    • [X] Take picture
    • [X] Get picture bytes

LOC4 - TimeZone

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a user information of the local and home time while she is on the road.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Geolocation / TimeZone web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The Widget or Active Web Page gets home date, time and time zone from the device, it also gets location information.
  • [X] 3- The Widget uses location information to work out the local time zone by means of a geo location web service.
  • [X] 4- The widget works out the time shift between local and home and periodically updates both clocks.

Interfaces involved

  • [X] Location
    • [X] Get current location
  • [X] Phone System
    • [X] Get Home Date
    • [X] Get Home Time
    • [X] Get Home Time Zone

LOC5 - Location Aware Searches

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a user with search results dependant on her real location (be them hotels, pictures, services...).

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Search web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The user enters a criteria for a query (if needed, results could be delivered without user interaction) and clicks on "Search").
  • [X] 3- The Widget adds location information to the query and provides with tailored results.

Interfaces involved

  • [X] Location
    • [X] Get current location

LOC5 - Where are my friends?

Description

  • [X] This use case describes how a Widget or an Active Web Application can provide a user with location information for a group of people.

Actors

  • [X] User
  • [X] Widget or Active Web Page
  • [X] Friends location back-end service
  • [X] Mapping web service

Pre-conditions

Post-conditions

Flow

  • [X] 1- The user clicks on the Widget or browses to the Active Web Page
  • [X] 2- The widget periodically sends the user location information to the Friends location back-end service.
  • [X] 3- The user can then get a map with its own location and their friend locations.

Interfaces involved

  • [X] Location
    • [X] Get current location

0. Summary

The following table shows an stimation of the number of times each the API is used by the use cases described above.

Messaging6
Contacts6
Calendar7
Tasks3
Pictures Gallery4
Audio Gallery2
Video Gallery4
Calls6
System16
System properties8
System actions5
System events3
Location10
Installed Applications8
File System2
International Support0
Bluetooth0
SIM0
Presence0
Capability Discovery1
Persistent Storage3
Softkeys & Menues0
Retrieved from "http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases"
Personal tools