2

I have a specific situation, that is application specific that needs to be handled. My app is an ionic video surveillance app, that uses cordova for various plugins. It displays streaming JPEG images as one part of its function.

The scenarios I need to handle:

  1. If the app goes into background, it needs to clear up video resources, that results in stopping of video streams
  2. If the app is running in multi-window mode (Android 7.0+), it needs to run side by side another app in split window mode, even if the user is interacting with the other app.
  3. If the app is running in multi-window mode and the user actually switches it out of the view, it needs to clear up video resources

That being said, here are the following predicaments:

  1. Today, browser apps don't get onStop() as a callback. We only get onPause(). This causes a problem when running in multi-window, because the moment the user taps on the other app, my app gets an onPause() and thinks its going into the background and clears up video resources. Obviously, this is undesirable and the viewer wants the video playback to continue (not streaming video but streaming images, so we don't really have a PIP video player situation here)

  2. There is no way, in JS land, to detect multi-window mode

According to the multi-window docs, it is now necessary to differentiate between stop() and pause() (and as a corollary, resume() and start()) for user experiences like playing of videos.

Given my specific requirements sighted above, I have arrived at the following solution:

  1. I've developed a plugin that lets me trap onStop() and onStart() and multi-window state (as a result of another related question I asked on SO a few days ago)

  2. My approach therefore, is if I am running on Android, I will not trap the browser pause and resume events and only rely on onStop() and onStart() (simplifies the process of not having two callbacks for one event, both pause and stop/ resume and start)

  3. I've been testing situations on my android app on when onPause() is called and when onStop() is called. It seems to me they are always called together. I've read this may not be true in the case of an ActivityDialog. Based on the description there, that situation seems fine for my app as I don't need to clean up video resources.

Does anyone see a problem with this approach -- that is, don't trap onPause() browser event if running on android, use cordova onStop() instead? While I've tested, I might be missing something obvious that others might like to advise me on.

It is critical that my app is able to free video resources when the app actually moves to the background and its UI is not displayed (because due to some browser issues, it results in big leaks, otherwise) and hence it is important I don't miss an event. Therefore I'd like to make sure that ditching onPause() for onStop() doesn't result in a missed situation. I also need to support users running Android 4.2 & 4.4 for which I use the now defunct crosswalk library, so I really need to make sure by adopting this approach, I'm not going for a solution that will only work on modern systems.

user1361529
  • 2,667
  • 29
  • 61
  • How did you handle the limited amount of time you are given to perform tasks when the app goes into the background? I'm up against a similar issue in that I have to release some resources when the app goes into the background, but the Android is not giving my app enough time to complete the process. Did you have that problem? – d512 Sep 06 '22 at 18:02

1 Answers1

0

Answering my own question: I've been testing this approach for a while now and I don't see any evident issues - both legacy and new versions of Android seem to behave well.

user1361529
  • 2,667
  • 29
  • 61