- From: Micheil Smith <micheil@brandedcode.com>
- Date: Tue, 19 Apr 2011 19:36:23 +1000
- To: public-device-apis@w3.org
Hi All,
I saw the recently changed Device Messaging API draft [1], and couldn't help but feel that it
seems extremely un-javascript-ish. I saw that the authors are looking for feedback on the
API, so I composed an alternative API to the current one.
My proposal is very similar to the previous API [2], which I felt fairly good as far as a JavaScript
API, however, it has the following changes:
(The full WebIDL proposal is at: https://gist.github.com/ebd79f6cd4f620fc4fa7 )
1) The navigator.device.messaging.* methods have been made Constructors instead, such
that the following is valid:
var message = new navigator.device.messaging.SMS({
to: "+46000000001",
body: "Welcome to Atlantis"
});
2) All Messaging Constructors inherit from the DOMEvents EventTarget interface. Example:
message.addEventListener("sent", function() {
alert("Your SMS message was sent!");
});
3) All Message Objects have a send and abort method.
4) All Message Objects have a readyState, and readyState constants defined.
5) All Message Objects have properties for various events (see onsend, onsent, onerror)
6) All arguments or properties that were an Array of Something, eg, DOMString[], are now able
to be either a DOMString (for the singular) or a DOMString[], such that the following work:
var message = new navigator.device.messaging.SMS({
to: "+46000000001",
body: "Welcome to Atlantis"
});
var message2 = new navigator.device.messaging.SMS({
to: ["+46000000001", "+46000000002", "+46000000003"],
body: "Welcome to Atlantis"
});
7) Attachments are now of type "sequence<Blob>".
The full WebIDL proposal is at: https://gist.github.com/ebd79f6cd4f620fc4fa7
I think that anything where there is the possibility of multiple callbacks should be instances of
EventTarget [3], as this is a well known and easy to use API, which allows for developers to
optionally listen for events. In the case of the Messaging API, sometimes a developer may
wish to send a "fire-and-forget" message.
On each Message Object, I have introduced a readyState property, as well as readyState
constants, the usage of this is to be able to poll for a state change, as is available in the
XMLHTTPRequest API [4].
Let me know what you think, or consider taking some of this feedback on board.
References:
[1] http://www.w3.org/TR/2011/WD-messaging-api-20110414/
[2] http://www.w3.org/TR/2011/WD-messaging-api-20110120/
[3] http://www.w3.org/TR/DOM-Level-2-Events/idl/events.idl
[4] http://www.w3.org/TR/XMLHttpRequest/
Cheers / Regards,
Micheil Smith
--
BrandedCode.com
Received on Wednesday, 20 April 2011 13:15:10 UTC