sendMessage and receiveMessage refactoring? about react-native-wifi-p2p HOT 6 CLOSED

Hi @viniciuscb

I think it make sense to add stopReceivingMessage and stopReceivingFile 🙂 Would you mind to contribute and add these methods? 👀

Sometimes the connection is closed

Would be good to understand the reason behind it, i. e. why the connection was closed. Is it a bug in a library or it depends on external factors, such "user closed app"/"distance to receiver side became too big and because of that the signal was lost"?
Also maybe would be good to send an event "CONNECTION_CLOSED" or something like that, if we actuall can derive this event.

from react-native-wifi-p2p.

Got it @viniciuscb 👍
Then I think we'll need to have stopReceivingMessage/stopReceivingFile methods and it would be very helpful to know, when "CONNECTION_CLOSED" event occured (to actually call stopReceivingMessage/stopReceivingFile methods). Agree?

P. S. I'm going to create 3.4.0 release, but I'll be glad to release 3.5.0 with new API methods if you submit PR 😊

from react-native-wifi-p2p.

@viniciuscb I think if you rewrite and migrate away from AsynTask, then you may not worry about backward compatibility :)

In my opinion it's useful to know sender address - of course it will be breaking change, but it will be easy to migrate.

Moreover I already have some deprecated methods in API and I would like to remove them and publish new 4.0.0 version :)

from react-native-wifi-p2p.

Hi Kirill. The problem with sendMessage is happening due to external factors. For instance, when the app crashes/is closed in one device, and I didn't receive yet (in the other device) the information that the connection changed in react native level (through listeners/subscribe methods).

from react-native-wifi-p2p.

I see now that the AsyncTask class became deprecated in API 30. So the receiveMessage will need to have a refactoring anyway.

From: https://developer.android.com/reference/android/os/AsyncTask

AsyncTask was intended to enable proper and easy use of the UI thread. However, the most common use case was for integrating into UI, and that would cause Context leaks, missed callbacks, or crashes on configuration changes. It also has inconsistent behavior on different versions of the platform, swallows exceptions from doInBackground, and does not provide much utility over using Executors directly.

Besides that, @kirillzyusko and @seba9999 , maybe we can pass an optional parameter to receiveMessage to receive also the metadata (currently only the origin IP address). This way we can maintain backward compatibility.

from react-native-wifi-p2p.

I've proposed a PR ( #80 ) that does not break backward compatibility.

from react-native-wifi-p2p.