Yes, I am working on a unified solution, which is to include a
pre-deviceready event which contains launch context data. This would/could
include being launched from an intent, or a url:protocol that you have
registered, a local notification, a push notification, launch from a
secondary tile, ....
Typically an app that needs to maintain state should do it whenever state
changes. pause/resume events can be used as well, but there is no specific
event for going from paused->destroyed other than possibly being able to
use window.onunload | addEventListener('unload'..
@purplecabbage
risingj.com
On Thu, Jun 4, 2015 at 1:04 PM, Dan Polivy <d...@cellartracker.com> wrote:
> Is there any notification to the app via JS that the activity is being
> destroyed, e.g. to allow the app to save state?
>
> FWIW, I think any plugin that invokes another intent that returns data is
> potentially vulnerable to this issue -- e.g. barcode scanner being another
> one (I have a few real world crashes on this, too -- but not as many as for
> Camera). So a more general purpose solution might be appropriate if
> possible.
>
> Dan
>
> -----Original Message-----
> From: Serge Huijben [mailto:s.huij...@gmail.com]
> Sent: Wednesday, June 03, 2015 11:39 PM
> To: dev@cordova.apache.org
> Subject: Re: Android plugin crash on resume when activity destroyed
>
> Joe, it failing on Travis was not caused by the code in the pullrequest.
> I just changed one word in the readme.md and committed that to have Travis
> build it again and now it's all good.
>
> - Serge
>
> Op do 4 jun. 2015 om 07:54 schreef Serge Huijben <s.huij...@gmail.com>:
>
> > I must say that restoring state in the webview has not been a problem for
> > me. admittedly our app is only for Android 4.1 (sdk 16) and higher.
> > In our app we save state all the time using localstorage, and I do know
> > exaxtly where the user was at --> he was taking a picture or selecting
> one
> > from the gallery
> > that leaves me with only one possible view to deliver to the user.
> > I just call checkForSavedResult on the camera plugin in onDeviceReady
> > using a promise and if it returns a value I take the user to that view.
> > localstorage is still intact so the user is non the wiser, maybe only a
> bit
> > confused as to why he just saw the splashscreen. if the returnvalue is an
> > empty string I take the user to the "welcome" view
> >
> > This method could be generalised but as Joe pointed out, there's little
> > chance of this occurring in plugins other than the camera plugin.
> >
> > - Serge
> >
> >
> > Op wo 3 jun. 2015 om 23:31 schreef Dan Polivy <d...@cellartracker.com>:
> >
> >> Interesting, thanks for the history, Joe and Serge.
> >>
> >> I do probably agree with you, Joe, that this won't work well as it'll be
> >> hard to restore the DOM to the correct state. I can say that for my app,
> >> it's pretty unlikely to get exactly back to where you started. In prior
> >> versions of Cordova (pre-4.0), I think that instead of a crash, the user
> >> experience was the app just appeared to restart itself.
> >>
> >> At the very least, is there any possibility of better handling this
> >> scenario at a general level so it doesn't lead to a crash? I guess a
> >> targeted fix for the Camera plugin, to perhaps detect this and throw an
> >> error dialog, might be a start. I've also seen this with the barcode
> >> scanner plugin (which uses the camera). I don't know the policy on
> >> introducing localized strings in the core platform components, but if
> >> there's a way to handle that, it seems like showing the user a (native)
> >> notification that it failed would be appropriate.
> >>
> >> It may also be prudent to update the plugin development guide to discuss
> >> this issue and how to prevent crashes from referencing uninitialized
> >> instance variables in the intent callback.
> >>
> >> I may also play with Serge's solution and see if it is viable, and will
> >> report back what I find.
> >>
> >> Dan
> >>
> >> -----Original Message-----
> >> From: Joe Bowser [mailto:bows...@gmail.com]
> >> Sent: Wednesday, June 03, 2015 11:44 AM
> >> To: dev@cordova.apache.org
> >> Subject: Re: Android plugin crash on resume when activity destroyed
> >>
> >> This has been a problem since we started, and there's no solution to it
> >> because there's no reliable way to restore state on a WebView. We have
> >> tried in the past, and failed miserably. I'm extremely skeptical that
> >> this
> >> would even work, since this apparently failed Travis. That said, if it
> >> does, every intent would have to manage their own state, and even when
> the
> >> plugin is loaded, we still don't know where in the app the user would be
> >> at, so returning a photo to a part of the DOM that doesn't even exist
> >> would
> >> have JS errors.
> >>
> >> Of course, this only happens when you're using a LOT of memory, like
> what
> >> Cameras tend to do, and other Intents, like for example, requesting
> >> permission to use a Tango Service on a Project Tango plugin, (
> >> https://github.com/infil00p/PhoneGapTango) or other third party plugins
> >> wouldn't run into the same problems.
> >>
> >> This is a problem with the Android architecture, and many native apps
> have
> >> run into similar problems. I don't think there's a solution for this in
> >> Cordova, and we have definitely tried.
> >>
> >> On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <ommen...@microsoft.com>
> wrote:
> >>
> >> > Interesting fix, Serge. A question comes to mind:
> >> > - Since it seems like this issue affects all android plugins that call
> >> > other intents, won't we have to do this for all of them? Is there a
> way
> >> we
> >> > can leverage your PR and maybe come up with a general solution ? Maybe
> >> fit
> >> > the boilerplate code (state saving/restoring) somewhere all android
> >> plugins
> >> > can inherit ?
> >> >
> >> > On Jun 3, 2015 3:54 AM, Serge Huijben <s.huij...@gmail.com> wrote:
> >> > what I did to solve this is add a check for callbackcontext, If that
> is
> >> > null save the incoming parameters.
> >> > if (this.callbackContext == null) {
> >> > this.savedRequestCode = requestCode;
> >> > this.savedResultCode = resultCode;
> >> > this.savedIntent = intent;
> >> > } else {
> >> > // procede as planned
> >> >
> >> > This is what happens after the activity has been killed by the system
> >> while
> >> > you are in the camera Intent.
> >> > Once you take or select your picture the mainactivity is restarted and
> >> with
> >> > it all the plugins, after which onActivityResult is fired.
> >> >
> >> > the code above saves the incoming parameters so they can be used
> later.
> >> > To do this I also added a new method, checkForSavedResults, specially
> >> for
> >> > Android, you call this method in your onDeviceReady javascript method
> >> that
> >> > will fire once the activity is restarted, and this will give you the
> >> > previously taken or selected picture.
> >> >
> >> > I put this in a pullrequest
> >> > https://github.com/apache/cordova-plugin-camera/pull/97
> >> > It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
> >> >
> >> > hope this helps,
> >> >
> >> > Serge
> >> >
> >> >
> >> > Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <d...@cellartracker.com
> >:
> >> >
> >> > > On Android, when using plugins that launch other intents, e.g. the
> >> Camera
> >> > > plugin, I'm now seeing reliable crashes when the cordova activity is
> >> > > resumed - if it was "destroyed" when the intent launched. The
> reliable
> >> > way
> >> > > to reproduce this is to enable the "Don't keep activities" setting
> in
> >> > > Android's Developer options. Based on the Google Play crash reports,
> >> this
> >> > > just started when we updated our app to use the new
> >> cordova-android@4.0.0
> >> > > <mailto:cordova-android@4.0.0> runtime.
> >> > >
> >> > > In the Camera plugin, the issue is that the
> >> > > CameraLauncher.processResultFromCamera method uses an instance
> >> variable,
> >> > > imageUri, which is set prior to launching the intent, but null when
> >> the
> >> > > activity is resumed. Presumably, this is because the plugin isn't
> >> aware
> >> > > that it needs to save state? Here's the full stack trace:
> >> > >
> >> > > java.lang.RuntimeException: Unable to resume activity {<app>}:
> >> > > java.lang.RuntimeException: Failure delivering result
> >> > ResultInfo{who=null,
> >> > > request=34, result=-1, data=null} to activity {<app>}:
> >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> >> reference
> >> > > at
> >> > >
> >> >
> >>
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> >> > > at
> >> > >
> >>
> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> >> > > at
> >> > >
> >>
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> >> > > at android.app.ActivityThread.access$900(ActivityThread.java:172)
> >> > > at
> >> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> >> > > at android.os.Handler.dispatchMessage(Handler.java:102)
> >> > > at android.os.Looper.loop(Looper.java:145)
> >> > > at android.app.ActivityThread.main(ActivityThread.java:5835)
> >> > > at java.lang.reflect.Method.invoke(Native Method)
> >> > > at java.lang.reflect.Method.invoke(Method.java:372)
> >> > > at
> >> > >
> >> >
> >>
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> >> > > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> >> > > Caused by: java.lang.RuntimeException: Failure delivering result
> >> > > ResultInfo{who=null, request=34, result=-1, data=null} to activity
> >> > {<app>}:
> >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> >> reference
> >> > > at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> >> > > at
> >> > >
> >> >
> >>
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> >> > > ... 11 more
> >> > > Caused by: java.lang.NullPointerException: Attempt to invoke virtual
> >> > > method 'java.lang.String android.net.Uri.toString()' on a null
> object
> >> > > reference
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> >> > > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> >> > > at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> >> > > ... 12 more
> >> > >
> >> > > I've been looking at this for a bit, and am wondering whether this
> can
> >> > > even be supported with the current plugin architecture. I see that
> >> > onStart
> >> > > and onStop are now part of the plugin interface, but not
> >> > > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly
> >> common
> >> > > pattern for plugins to save the CallbackContext, so this will impact
> >> more
> >> > > than just the Camera plugin.
> >> > >
> >> > > Has any thought gone into supporting this scenario? Is it possible
> to
> >> do
> >> > > with the current plugin interface, or would it need to be extended
> to
> >> add
> >> > > the instance state handlers to allow plugins to preserve necessary
> >> state?
> >> > > I'm happy to take a stab at addressing this, but would appreciate
> >> insight
> >> > > from the android native devs on the right way to approach this
> issue.
> >> (I
> >> > > haven't yet filed a JIRA issue on this, but will shortly.)
> >> > >
> >> > > Thanks,
> >> > > Dan
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >
>
