i have this situation where i stream a video through a webview (no vitamio in this particular instance.)
i've tried several ways to stop the video, from a dedicated movie.stop() button to removing the webview
from the activity. the stream - at least the audio portion - continues unabated, even if i back out of the app. the only way to stop it is to back out of the app entirely and then go back in, presumably forcing a resume.
android documentation regarding webviews tries to portray them as simple objects of limited use. i find the opposite to be the case. in any case, i'm looking for any tools to help me deal with the situation i'm in.
what i see is that there appears to be no way to close the connection that a webview opens - or requests to be opened - via loadurl() or loadhtml(). removing the view doesn't help. nor does loading a dummy webpage (eg, "about:blank") appear to close any existing connections. nor can i call "activity.resume" from b4a in an attempt to force the same behavior that the naturally occurring
activity resume seems to cause. (i could probably just change the device's orientation, but that's a funny way to solve the problem.)
i realize this may be more an android issue than b4a, but i'm wondering how b4a sees the matter. does the webview open its own connections? if so, does it have the ability to close them? can i access that ability (eg, through the relector)? i didn't see any methods in the android documentation relating to this.
can i force a resume? would that be bad? better yet, what is it that the os does to the runaway stream when resume occurs naturally? perhaps i could do the same thing (eg, via the reflector)?
if, in fact, only the audio channel is still active through some quirk, is there a way to toggle - disable/re-enable - the device's audio? (assuming that would actually make a difference.)
for the curious: i would use vitamio if it were just a matter of pointing it to the stream. but the url to the cdn requires an embedded sessionid which i have been unsuccessful so far in exposing (except in a stream sniffer, so i know it does exist.)
thanks for any help.
i've tried several ways to stop the video, from a dedicated movie.stop() button to removing the webview
from the activity. the stream - at least the audio portion - continues unabated, even if i back out of the app. the only way to stop it is to back out of the app entirely and then go back in, presumably forcing a resume.
android documentation regarding webviews tries to portray them as simple objects of limited use. i find the opposite to be the case. in any case, i'm looking for any tools to help me deal with the situation i'm in.
what i see is that there appears to be no way to close the connection that a webview opens - or requests to be opened - via loadurl() or loadhtml(). removing the view doesn't help. nor does loading a dummy webpage (eg, "about:blank") appear to close any existing connections. nor can i call "activity.resume" from b4a in an attempt to force the same behavior that the naturally occurring
activity resume seems to cause. (i could probably just change the device's orientation, but that's a funny way to solve the problem.)
i realize this may be more an android issue than b4a, but i'm wondering how b4a sees the matter. does the webview open its own connections? if so, does it have the ability to close them? can i access that ability (eg, through the relector)? i didn't see any methods in the android documentation relating to this.
can i force a resume? would that be bad? better yet, what is it that the os does to the runaway stream when resume occurs naturally? perhaps i could do the same thing (eg, via the reflector)?
if, in fact, only the audio channel is still active through some quirk, is there a way to toggle - disable/re-enable - the device's audio? (assuming that would actually make a difference.)
for the curious: i would use vitamio if it were just a matter of pointing it to the stream. but the url to the cdn requires an embedded sessionid which i have been unsuccessful so far in exposing (except in a stream sniffer, so i know it does exist.)
thanks for any help.
