[FR] Provide an API to transfer large amount of data on Wifi between phone and watch when possible.

[Tolriq]

Following a discussion on Slack. It would be nice to have an high level API that allows watch to get large data from the phone but using Wifi when both the watch and the phone can be connected to the same network.

Typical use case would be to download music from the phone to the watch to play without the phone available. There's still people storing their music on sdcards or on servers that can't transcode to smaller file and need to sync via the phone.

A first step would be to have an API allowing to check that both devices are connected to the same wifi network and can communicate.

Then if possible build a transfer solution on top of that.

My naive way if I was to do it, would be the watch ask the phone to open a socket on a port (returns error if phone not on wifi or actual error or return the wifi ip and port). The watch check if it can connect to wifi, connect then try to connect to that socket with a well known message.

[yschimke]

cc @garanj I wonder if it's useful for other apps.

[Tolriq]

@yschimke the 100 000$ question is about the battery usage of BT vs wifi, in the doc you suggest no BT for more that 1 Mb. But is there any data to help justifying that the gain is so huge it can be beneficial for maybe a little lower sizes too. (For the cases that do not care about speed of course).

[yschimke]

These are just guides. They are written to be fairly black and white, to ensure that most apps just do the safe/optimal thing. But if you have a specific case, such as needing particular network access, then you can make an educated call and check it isn't draining the battery super fast.

[Tolriq]

Well in my case the need is to transfert large amount of data from the phone to the watch in the most efficient way possible battery wise. Speed would be nice but probably secondary. So I don't have a particular network need, if BT is battery efficient to transfert 500Mb+ of data then it's ok for me. The docs seems to imply wifi would be best for battery hence this request.

[yschimke]

There are two issues with BT for this

1. It's going to be slower, you'll keep the app awake longer running the copy, than if you got it straight via Wifi.
2. BT is a shared resource, you'll saturate the connection, and other things between the watch and notification could be delayed.

But they are very different APIs also.

I don't know to treat the BT connection as a socket to the mobile. So it's Data Layer APIs unless you have more information.

[Tolriq]

From the doc I would have do the ChannelClient way as it seemed to be the solution to that and tried to build some kind of channel that would go through Wifi. This part of wear is new to me and there's little doc about it. And horologist all nice stuff is about downloading from internet.

On another Wear app without such constraints I use DataClient but this does not fit this need at all.

Edit: But in all cases thanks for the confirmation that I should not try to achieve that via BT :)

[capntrips]

I'm trying to do something similar and came across this. After reworking the DataLayer sample to use ChannelClient, it unfortunately continues to use Bluetooth, so I tried using raw sockets in Ktor. A 500mb file, which was on target to take just under an hour to transfer over Bluetooth via ChannelClient, took just under two minutes to transfer over Wifi via Ktor. Rather than completely redoing everything, I imagine I'll just end running Ktor as an HTTP server and dynamically generating the JSON files.