canmove, Confirmed users
725
edits
WebAPI/WebMobileConnection: Difference between revisions
→Proposed API
| Line 54: | Line 54: | ||
*/ | */ | ||
readonly attribute short bars?; | readonly attribute short bars?; | ||
/** | |||
* Search for available networks. | |||
* | |||
* If successful, the request result will be an array of operator names. | |||
*/ | |||
DOMRequest listAvailableNetworks(); | |||
/** | /** | ||
| Line 73: | Line 80: | ||
*/ | */ | ||
attribute EventListener onsignalstrengthchange; | attribute EventListener onsignalstrengthchange; | ||
}; | }; | ||
= Further APIs = | |||
The following radio/mobile connection related features will be exposed as settings in [[SettingsAPI]]: | |||
* radio on/off (e.g. for aeroplane mode) | |||
* caller ID on/off/provider default (called "CLIR" in TS 27.007) | |||
* call forwarding preferences | |||
* manual override for operator selection | |||
There are also some more features of the radio that should be exposed to (privileged) content in some shape or form: | |||
* ICC-related (SIM/RUIM card) | |||
** own phone number and other ICC I/O related features | |||
** entering PIN, PIN2, PUK, PUK2 to unlock various states of the SIM card. Entering the PIN isn't *that* exotic, actually. Some carriers deliver their SIM cards with the PIN lock enabled, for instance. | |||
** changing the PIN (also serves as enabling/disabling the PIN lock.) | |||
* device-related | |||
** get IMEI, IMEISV | |||
** depersonalize (remove network lock) | |||
** baseband-related information and features | |||
The latter, device-related features seem to be more exotic than the ICC-related ones and hopefully also mostly unnecessary. The question remains where these APIs should live. | |||