RE: Network Information Use Cases

Tobie,

One of the key use cases we are exploring is opportunistic use of existing network connections, to avoid apps from needing to create a new network connection for transfer of data that can wait until there is some connection established for other purposes (i.e. by some other app or device function). Giving developers tools and guidelines to help reduce RRC (radio resource control) layer chatter on mobile networks is one of the goals of the GSMA's Application Network Efficiency (ANEFF) project and the Network Friendly App and Webapp Community Group [1]. Currently a lot of very short connections are used by apps, asynchronously/uncoordinated. The navigator.connection interface as well as the currently existing navigator.onLine interface will hopefully be valuable in enabling developers to use network connections more opportunistically, for data transfers that can be delayed until an opportunity arises.

Related to that use case goal, as part of the wiki it would be useful to explain the relationship of the navigator.connection interface with the navigator.onLine interface, and point to experience testing with the current implementations of the interfaces. 

Below for example is some test data that I obtained by running my test of the navigator.connection interface [2], which uses addEventListener for both navigator.connection and navigator.onLine to produce a record of the changes seen. I'm just now looking into what this data tells me about the reliability of the information obtained. In this case I was in a conference, and bouncing between EDGE and 3G (deep in the ballroom of a hotel without a microcell, thus getting variable mobile network coverage) using a Galaxy Note with ICS and Firefox Beta.

[1]: http://www.w3.org/community/networkfriendly/
[2]: http://bkaj.net/test/dap/connection.html 

+++test output+++

The navigator.connection interface is defined.
navigator.onLine: true
navigator.onLine events:
1. 12:41:44 offline
2. 12:41:57 online
3. 12:42:07 offline
4. 12:43:30 online
5. 12:47:09 offline
6. 12:47:22 online
7. 12:51:12 offline
8. 12:51:19 online
9. 13:24:21 offline
10. 13:25:40 online
11. 13:26:07 offline
12. 13:26:20 online
13. 13:30:45 offline
14. 13:32:39 online
15. 13:39:28 offline
16. 13:39:52 online
17. 15:18:17 offline
18. 15:18:21 online
19. 15:19:36 offline
20. 15:19:55 online
Connection bandwidth: 20 Mb/s
Connection is metered: false
navigator.connection events:
1. 12:41:44 0 Mb/s, not metered
2. 12:41:57 20 Mb/s, not metered
3. 12:42:07 0 Mb/s, not metered
4. 12:52:26 20 Mb/s, not metered
5. 12:51:12 0 Mb/s, not metered
6. 12:51:23 0.1953125 Mb/s, not metered
7. 13:10:15 7 Mb/s, not metered
8. 13:24:21 0 Mb/s, not metered
9. 13:25:40 20 Mb/s, not metered
10. 13:26:07 0 Mb/s, not metered
11. 13:26:20 0.1953125 Mb/s, not metered
12. 13:30:45 0 Mb/s, not metered
13. 13:32:39 0.1953125 Mb/s, not metered
14. 13:39:28 0 Mb/s, not metered
15. 13:39:52 20 Mb/s, not metered
16. 15:18:17 0 Mb/s, not metered
17. 15:18:21 20 Mb/s, not metered
18. 15:18:32 20 Mb/s, not metered
19. 15:19:36 0 Mb/s, not metered
20. 15:19:55 20 Mb/s, not metered
21. 16:10:39 7 Mb/s, not metered

Thanks,
Bryan Sullivan 

> -----Original Message-----
> From: Tobie Langel [mailto:tobie@fb.com]
> Sent: Wednesday, July 18, 2012 9:49 AM
> To: Core Mobile
> Subject: Re: Network Information Use Cases
> 
> Hi,
> 
> In order to make progress on this issue, I've created a wiki page[1] where
> I referenced all use cases submitted so far and divided them in to two
> categories: those that could be met with Network info and those that
> couldn't.
> 
> I also added a section which explains what Network info provides and what
> it doesn't. Worth reading as the spec has changed recently.
> 
> I've also added a use case[2] for responsive images, as I found out there
> are JavaScript libraries[3] using Network info for this purpose.
> 
> There are three use cases that can be met with the Network Info API alone:
> 
> - Warning against or avoiding downloading of large-sized files
> - Poor man's adaptive streaming
> - Poor man's responsive img
> 
> 
> (Note the later ones are temporary solutions until better, dedicated
> technology gets specified and implemented.)
> 
> I suggest we concentrate our discussion around these three use cases only.
> And make a decision for inclusion in L1 based on the validity of these use
> cases and vendor intent to implement the spec.
> 
> Best,
> 
> --tobie
> 
> ---
> [1]:
> http://www.w3.org/community/coremob/wiki/Features/Network_Information_API
> [2]:
> http://www.w3.org/community/coremob/wiki/Features/Network_Information_API#P
> oor_man.27s_responsive_img
> [3]: https://github.com/adamdbradley/foresight.js
>

Received on Wednesday, 18 July 2012 17:21:20 UTC