You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This problem actually was noted by another reviewer in ticket #646, but I suspect they stopped seeing it because only certain situations seem to trigger it. Specifically, it appears that rotation and pause / resume can cause the PythonActivity to be destroyed and re-created, even if the app is still running in the background. The behavior is documented in the Android docs here:
To avoid having a complete app restart, it appears that Android caches the app state using the Bundle instance and tries to restore the app state automatically on resume. This is why onCreate gets a Bundle object that sometimes is empty (new start), and sometimes is not (rotation change or resume).
Unfortunately, it appears the state saving behavior is "under the hood" and it would take a deep look into Android's code to know what state it saves and when. It does seem to differ from app to app, which is why the problem is not persistent and easily reproduced.
When it does happen, you get the crash noted in #646, and tracking that down, you find that the problem is that when onCreate is called with a non-empty Bundle, it causes mLayout and mImageView to be restored from cache, so the attempt in showLoadingScreen to add mImageView to mLayout gives a 'duplicate view' error.
I'm going to submit a pull request with a fix for this. I didn't discover a way to check if a view exists, and I wasn't sure if doing a try block with removeView would have any side-effects, so I went with the solution of only setting mImageView to mLayout if we don't have an existing mImageView. The potential side-effect is that resume may not show the splash screen, but resume startup won't have the potential unzip slowdown, and the Bundle resuming should reduce the loading time on resume at least somewhat.
Anyway, I'm open to a different or better approach if anyone knows of one. :)
Also, I think #730 and #732 are affected by recreating the PythonActivity based on their problem descriptions, but I do not know this for certain.
The text was updated successfully, but these errors were encountered:
kollivier
added a commit
to kollivier/python-for-android
that referenced
this issue
Jun 20, 2016
… cached in the Bundle instance, so it's possible for showLoadingScreen to be called when mLayout is already created and has the mImageView attached. Only attempt to assign to mLayout if there isn't already an mImageView. This fixeskivy#797.
This problem actually was noted by another reviewer in ticket #646, but I suspect they stopped seeing it because only certain situations seem to trigger it. Specifically, it appears that rotation and pause / resume can cause the PythonActivity to be destroyed and re-created, even if the app is still running in the background. The behavior is documented in the Android docs here:
https://developer.android.com/training/basics/activity-lifecycle/recreating.html
To avoid having a complete app restart, it appears that Android caches the app state using the Bundle instance and tries to restore the app state automatically on resume. This is why onCreate gets a Bundle object that sometimes is empty (new start), and sometimes is not (rotation change or resume).
Unfortunately, it appears the state saving behavior is "under the hood" and it would take a deep look into Android's code to know what state it saves and when. It does seem to differ from app to app, which is why the problem is not persistent and easily reproduced.
When it does happen, you get the crash noted in #646, and tracking that down, you find that the problem is that when onCreate is called with a non-empty Bundle, it causes mLayout and mImageView to be restored from cache, so the attempt in showLoadingScreen to add mImageView to mLayout gives a 'duplicate view' error.
I'm going to submit a pull request with a fix for this. I didn't discover a way to check if a view exists, and I wasn't sure if doing a try block with removeView would have any side-effects, so I went with the solution of only setting mImageView to mLayout if we don't have an existing mImageView. The potential side-effect is that resume may not show the splash screen, but resume startup won't have the potential unzip slowdown, and the Bundle resuming should reduce the loading time on resume at least somewhat.
Anyway, I'm open to a different or better approach if anyone knows of one. :)
Also, I think #730 and #732 are affected by recreating the PythonActivity based on their problem descriptions, but I do not know this for certain.
The text was updated successfully, but these errors were encountered: