identity-android no longer reports transmission progress

[spheroid]

Before #507, identity-android contained TransmissionProgressListener that would inform the client code about the transmission progress. The actual percentage value might add some value to the UI layer, but more importantly, knowing when the transmission is complete is useful information.

After identity-android was converted to Kotlin, this interface and functionality disappeared from the library.

Is there a plan to add this functionality back in? Or are you planning to convert the transmission API to use coroutines so that one could determine the task completion from the return of the suspending function?

[davidz25]

This did work somewhat for BLE GATT but for all other data transports it was pretty much a no-op. There's really no reliable way to do this, at most it just tells you when the next layer down (e.g. operating system) accepted the data w/o knowing when it would actually be sent on the wire, less even when the other side received it... similarly, knowing when the last part of the the message was sent also isn't very useful... in fact, I would argue the only useful signal is when you receive a message from the other side.

So I'm not really sure this is something we should bring back since we'd be promising apps we know this when in fact, it's not possible to know for sure... thoughts?

[spheroid]

Right, I see. I'm not really looking for a confirmation whether the data has been received by the peer but whether it actually has been fully passed over to the underlying transport or not from the context of auto closing the connection, as required by #463.

[davidz25]

OK, I think I see the problem... I was going to say that I think the transport would report an error (via the onError callback on the listener) if the message wasn't fully delivered... but if we're calling close() right after sending it we won't get this callback, right?

I think the solution is to change the semantics of DataTransport.close() so it blocks until all messages are sent... the docs already say Messages previously sent with [sendMessage] will be sent before the connection is closed, what we need to stipulate here is that it blocks until all queued up messages are delivered to the OS. As we do this, we need to go through all users of this (library and app code) and make sure they don't call close() on the UI thread...

[davidz25]

CC @dyiop