Closed johnwargo closed 4 years ago
@vargavince91 OK, using this as an example, I replaced the call to
streamSubscription.cancel();
to
Future.delayed(Duration(minutes: 1), () => sub.cancel());
And the ESPTouch config worked but the app crashes when it comes to canceling the subscription:
════════ Exception caught by services library ══════════════════════════════════════════════════════
The following PlatformException was thrown while de-activating platform stream on channel eng.smaho.com/esptouch_plugin/results:
PlatformException(error, No active stream to cancel, null)
When the exception was thrown, this was the stack:
#0 StandardMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:569:7)
#1 MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:156:18)
<asynchronous suspension>
#2 MethodChannel.invokeMethod (package:flutter/src/services/platform_channel.dart:329:12)
#3 EventChannel.receiveBroadcastStream.<anonymous closure> (package:flutter/src/services/platform_channel.dart:531:29)
...
════════════════════════════════════════════════════════════════════════════════════════════════════
Thank you @johnwargo, I'll try to reproduce, investigate, and solve your issue asap!
@vargavince91 any progress? Anything I can do to help?
@johnwargo Here is the code that prints your original exception.
It is handling a java.lang.InterruptedException
which is thrown because we interrupt (cancel) the task from the Flutter side.
It's not an uncaught exception, however, it might look like one as the entire stack trace is printed.
This part of the code is from the original Espressif Android, so I'm not really sure why they considered it a warning (Note logcat "w" level in Log.w
and I also don't understand why they print the entire stack trace https://github.com/smaho-engineering/esptouch_flutter/blob/fb00ef0b9cda8f2720b473fc2edd4324d77396b9/android/src/main/java/com/espressif/iot/esptouch/udp/UDPSocketClient.java#L118
There are a couple of instances where the log levels doesn't make sense, but I'd prefer not to go through the entire plugin's logs.
The way I see it, interrupting the task is considered totally normal and should not be logged as a warning. Practically speaking, the plugin works consistently and you should be able to set up as many devices as you want, though the logs can be annoying.
When wrapping the two original libraries (ios+android), I tried to make as little changes as possible to the original code base, while still adapting the libs to our needs (1. be able to run from Flutter 2. be able to run with custom parameters and custom durations (e.g. run it for an hour).
For now (2.3.0), I changed the way we log: we now use the d
level instead of w
and removed the exception.printStrackTrace
calls. Please let me know if you can think of a reason why that would be problematic.
@johnwargo Oh and one more thing!
// Don't forget to cancel your stream subscription:
streamSubscription.cancel();
You should cancel the description with a delay. You need to first let the task run, then in accordance with the waitUdpReceiving
and waitUdpSending
durations, cancel the stream subscription. Another reason for cancelling the stream subscription is when the user left the screen where the task runs.
@vargavince91 thanks so much for looking into this for me. Do you mind providing some more detail for "then in accordance with the waitUdpReceiving
and waitUdpSending
durations, cancel the stream subscription."? I see in the simple example, the code waits an arbitrary time then cancels the stream subscription, but that is too arbitrary, right? What are you suggesting I do with those two durations you mention? Would those just be used as timeout values? but how would I use two of them?
Oh, sorry, forgot to commit & push the example app. See commit: https://github.com/smaho-engineering/esptouch_flutter/commit/59b6addccc196000dc703556f2c0414c123df8fa
If you have questions, shoot. Also, we are open to improvements, both on the example app's part and on the plugin itself. If you find a way that makes canceling easier as part of the library without adding too much complexity, let me know!
@vargavince91 thanks, it's working.
Thanks so much for making this package. It's just what I need for my ESP32 project. I build a test app using the connectivity package to get the device's Wi-Fi details then your sample code to configure the ESP32 device. My code to configure the device is:
but when I run the app, I get the following:
Have you seen this before? Do you know how I can fix this?