Concept Designs

Use-cases for content hand-over This page collects the use-cases for “one-shot” content handover, as currently mediated by the Didcot service. Some related use-cases which have been associated with the Didcot content-handover service during discussion of its API, but which we believe are sufficiently distinct that they should be examined separately, are collected on Content hand-over/Related. Where use-cases describe a requirement for a particular UI/UX behaviour, this is intended to be shorthand for a requirement that the platform provides enough control and enough information that the behaviour described is implementable. [Read More]

See Application Layout for more details of how store and built-in application bundles are arranged. Assumptions Store application bundles are arranged according to the Application Layout. Built-in application bundles are arranged according to the Application Layout. Platform upgrades are somewhat frequent, although not as frequent as store application bundle installation, upgrade or removal. Rollbacks are supported, but are relatively infrequent. Requirements Application bundles Suppose com.example.BuiltInApp is a built-in application bundle. A platform update from version 42 to version 43 results in BuiltInApp being updated. [Read More]

Various features on Apertis require a way to discover the applications and/or agents that implement a particular set of functionality. We refer to the “API contract” for this set of functionality as an interface. Use cases A global search user interface requires a list of services that can act as “Auxiliary Sources” (see §6.2 in the Global Search design document). For example, a Spotify client might register itself as a search provider so that searching for a term in a global search will find artists or songs matching that term. [Read More]

Use-cases General points of interest Third-party applications (the “provider”) might be aware of general “points of interest” for mapping. For example, an accommodation booking app-bundle might be aware of the locations of hotels, either from a particular chain if the app-bundle is for that chain, or for all hotels if the app-bundle is for a general service like Trip Advisor. It must be possible for a third-party app-bundle to provide these “points of interest” to a navigation app. [Read More]

Use cases App bundles’ functionality may include a feature of the form “send file to another user”. Suppose the user is viewing a file in some application, either built-in or a store application. Sharing menu The current application must be able to obtain a list of potential sharing recipients from the platform, sufficient to display a sharing menu similar to the one in Android. This list could include actions such as “send via MMS”, “attach to an email”, “send via Skype” or “share on Facebook”, each with the icon of its associated app bundle. [Read More]

The following use-cases are superficially similar to content hand-over, but have somewhat different requirements. We recommend that they are examined separately. Use-cases examined on separate pages Interface discovery Sharing Points of interest Monitoring status An application author wishes to indicate whether calling and/or SMS are currently available. () The platform must make this information available. We recommend implementing this by making it available as a C API in the platform, perhaps implemented in terms of oFono’s D-Bus API or an intermediary service such as Beckfoot. [Read More]

Design issues for content hand-over Creating new URI schemes (or not) The W3C suggests avoiding creation of new URI schemes but instead dispatching instead on the type of the representation (i.e. the content-type). Creating new content-types is substantially easier than it used to be and is compatible with sending those content-types via http or email. data:application/vnd.myapp.myobject,here-is-my-object is one way to pass small bits of content-typed data around as URIs, but we should be careful not to overuse inline data. [Read More]

This section holds concept documents which are not currently in Apertis’ roadmap but still have value as historical reference.

Contents

• Application
• Applications
• Connectivity
• Debug and logging
• Global search
• Inter-domain communication
• Points of interest
• Web portal caching
• Application and media
• Media management
• Multimedia
• On-screen keyboard
• Text To Speech
• Application customization
• Geolocation and navigation
• Internationalization
• Preferences and persistence
• Supported API
• UI customisation
• Application security
• Compositor security
• Conditional Access
• Multiuser
• Multiuser transactional switching
• Permissions
• Robustness
• Security
• Sharing

Why we need a new APT publisher Apertis relies on OBS for building and publishing binary packages. However, upstream OBS provides an APT publisher based on dpkg-scanpackages, which is not suitable for a project the scale of Apertis, where a single OBS project contains a lot of packages. Therefore, our OBS instance uses a custom publisher based on reprepro, but it is still subject to some limitations that are now more noticeable as the scale of Apertis has grown considerably: [Read More]