Office Hours — Today, January 23

← Tuesday, January 21

Jan 23
8:25 AM
Mark M.
has entered the room
Mark M.
turned on guest access
9:00 AM
Tad F.
has entered the room
Tad F.
Hi Mark!
Mark M.
hello, Tad!
how can I help you today?
Tad F.
I have been trying to properly implement an UncaughtExceptionHandler in my app, that will essentially properly close resources down, then restart the app.
I read through your blurb in one of your books on this.
Currently, I'm using Jake Wharton's ProcessPhoenix like this:
View paste (12 more lines) 
        defaultUEH = new Thread.UncaughtExceptionHandler() {
            @Override
            public void uncaughtException(Thread t, Throwable e) {
                StringBuilder sb = new StringBuilder();
                for ( StackTraceElement ste : e.getStackTrace()) {
                    sb.append("    at: ");
                    sb.append(ste.getClassName());
                    sb.append(" (");
                    sb.append(ste.getFileName());
                    sb.append(": ");
                    sb.append(ste.getLineNumber());
                    sb.append(")");
                    sb.append(System.getProperty("line.separator"));

                }
...
but based on what I read in your text, you don't subscribe to the getRuntime.exit() approach which he (ultimately) uses in this library, is that correct?
Currently, my flow looks like:
Application class starts, initializes long running resources, THEN my launch activity (Splash Screen) starts, and passes control to MainActivity.
Mark M.
quoting Jake's documentation: "This should only be used for things like fundamental state changes in your debug builds (e.g., changing from staging to production)."
so, I don't think Jake is expecting you to use this in production
sorry, in release builds
Tad F.
Right. I saw that. So I was a little unclear about how to implement what you suggested.
9:05 AM
Mark M.
OK... um, what did I suggest? :-)
I don't think that I have ever done some sort of auto-restart of an app
Tad F.
And in my case, I need to move all initialization into the launching activity so when it re-starts all the static stuff gets set up properly, etc.?
Let me find it and I'll post it here, hang on a sec...
Mark M.
I would be comfortable with ACRA-style solutions that fork a dedicated process to display a crash-related UI to collect notes from the user
Tad F.
Here's what you said: Set relevant static data members to null, then start up your launcher activity, using FLAG_ACTIVITY_SINGLE_TOP and FLAG_ACTIVITY_CLEAR_TOP to wipe out all other activities in your task. This should reset you to your original state, as if the user had launched the app.
From here: https://wares.commonsware.com/app/internal/book...
Mark M.
OK
Tad F.
Right now I'm doing initialization/cleanup in my application class.
Mark M.
I'm not sure how you do cleanup in an Application subclass specifically, as onTerminate() does not get called
Tad F.
There are static methods in there for initializing/releasing resources.
Mark M.
ah, OK
Tad F.
I do the cleanup by calling that static method from MainActivity on a backpress
Mark M.
then in principle you should be able to call those static methods from your uncaught exception handler
9:10 AM
Tad F.
Right - and I am doing that.
But the issue is the restart
Because initialization gets called from the app class right now.
On restart, does that class get recreated?
Mark M.
if by "restart" you are referring to passage of mine that you quoted, then no
you would need to identify what logic of your Application onCreate() you need to re-apply, then isolate that into a static method that your uncaught exception handler would call
Tad F.
I think what I mean by "restart" is a) cleanup, b) re-launch the app (which would cause a re-initialization of resources)
OK - so application won't get created again itself, correct?
Mark M.
correct
Tad F.
And how can I be assured that the back stack is completely cleared out, what do I need to do?
right now the app class doesn't launch anything of course - Android is doing that for me based on manifest settings.
Mark M.
I think the flags that I mentioned will cover that
Tad F.
And then do I manually do a startActivity at my SplashActivity entry point (the launching activity)?
Mark M.
whether you start a splash activity or your real "main" activity is up to you
if the splash screen is purely for branding purposes, I doubt that you really want to re-emphasize your brand immediately after a crash
if real work is going on there, though, then you probably have no choice
9:15 AM
Tad F.
OK - the SplashActivity is doing some checks that are important to get done prior to MainActivity being launched (which is one reason I made it the launcher), so I will do that. Maybe hide the branding or something the second...N time through.
Mark M.
BTW, with respect to the flags, I keep referring back to https://stackoverflow.com/questions/29321261/wh...
so, I'd double-check what I discussed in that question and answers to confirm what flags are the right combo for your scenario
(this stuff makes my head hurt)
Tad F.
OK I will look at that. Btw some other SO posts talk about using a "pendingIntent", but I don't need to do that right? Just a "regular" startActivity with an intent using the flags in your post?
Mark M.
what you are probably seeing are people who try using stuff like AlarmManager to allow the process to terminate, then automatically fire up the activity again at a later point
that technique was never reliable and will fail outright on Android 10, as you cannot start an activity from the background
and whether that Android 10 limitation will cause a problem for you here, I can't say
but yes, a regular startActivity() should be all that you need
9:20 AM
Tad F.
OK one other related item that I've never been able to figure out. Even though at one point or another instead of that ProcessPhoenix approach I've had a System.exit(), or Runtime.getRuntime.exit() or Runtime.getRuntime.halt(). But none of those three ever seemed to actually stop the process - I'd see my uncaughtException output in the logs, but the app would "appear" to restart (i.e. my MainActivity class would appear), but it was clear that in fact it had not properly initialized.
Does Android have some rule about attempting to re-create the last activity before the crash or something?
some behavior I should say
Mark M.
frankly, I have never quite figured out Android's rule set here
Tad F.
"appear to restart" is a misnomer. I would see my MainActivity pop up.
Mark M.
and I haven't spent much time with System.exit(), particularly in recent years
and this is an area where I would not be surprised if device manufacturers tinker around with stock Android
so, YMMV, and I don't really know what to tell you
Tad F.
OK. Gut feel just tells me that doing all the shutdown/re-initialization from within that exceptionhandler is the way to go.
Mark M.
somehow restarting the entire process would be cleaner and, in theory, safer -- it's just not really supported
Tad F.
Another topic - I am in the need of incorporating a simple palette of drawing widgets into my app. Basically I want to incorporate a simplified version of what you can do in PowerPoint to add text boxes, shapes, free-form drawing onto a canvas, then animate those objects in various ways (entry/exit animations, motion path animations, etc.).
Are you familiar with a good library that supports this kind of thing?
Mark M.
no, but I haven't ever looked for one
to be honest, I'll be a bit surprised if there is such a library, at least as open source
9:25 AM
Tad F.
It can be low-level - I've built these kinds of graphics processing modules in my past life, but they are a ton of work and I was hoping for a solid bootstrap library.
ok
Mark M.
the "ton of work" part is why I will be a bit surprised if there is such a library, at least as open source :-)
Tad F.
Right.
Never hurts to ask :)
Mark M.
there are plenty of libraries that involve a ton of work, but that tends to be for stuff that gets widely used
your use case, while reasonable, is fairly specialized
Tad F.
Btw, I am nearing a milestone to decide on a go/no-go decision for commercialization (i.e. launch a business) that incorporates this app I've been working with. I want to have a lot of this reviewed (architecture review, implementation hot spot review, etc.), and see what needs to be re-done, thrown out, tweaked, etc. for 'real live production'.
Is that something you consult on?
Mark M.
yes
Tad F.
OK - how can I email you to set up a time to discuss
?
or contact you, or whatever.
Mark M.
all roads lead to Rome -- all @commonsware.com addresses lead to me
Tad F.
ok great.
Mark M.
so, while officially I'm mmurphy@commonsware.com, feel free to make up an address :-)
Tad F.
Won't be in the near term, but decision will be before June 1 of this year - I'm doing a bunch of market research now.
Thanks, as always, for your input!
Mark M.
you're welcome, and I wish you luck on the project and in the market research work!
9:30 AM
Tad F.
has left the room
Mark M.
turned off guest access

← Tuesday, January 21

 

Office Hours

People in this transcript

  • Mark Murphy
  • Tad Frysinger