| KDE Connect |
On both devices I tested, the bluetooth InputStream did not notice end-of-stream and thus the transfer hanged.
Using this workaround, if we know the size of the payload, we notice this condition and prevent reading too much.
If this happens on all devices, we could possibly cancel the transfer immediately instead of only logging.
Transferring files or media art now works correctly.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 6416 | |
| Build 6434: arc lint + arc unit |
Actually, wait a bit before reviewing this. It turns out that not all (Android) devices support multiple Rfcomm servers (currently used for transmitting payloads), so we'll need something for that too.
I'm thinking about some kind of multiplexing thing, I'll get back about that.
Just so you know, I initially had the payload transfer going over the existing bluetooth connection (by sending the payload transfer info followed by the payload itself), but if the payload had newline characters, then the processing got messed up (because newlines got stripped off as part of regular message processing). Also, with payloads of unknown lengths, it wouldn't be easily possible to determine the end of the payload. Therefore, I split it out to a separate connection.
Makes sense. Sending it directly also causes problems for long transfers (e.g. file shares), so separating them makes sense. I'm trying to make something work in all cases.