hello, Rahul!

how can I help you today?

hello, I'm a new subscriber and new to Android world. Just wanted to check in with an office hour to see what it is like.

it is really for if you have questions to ask

the number of attendees varies, usually only a couple of people

I kinda rotate between them to handle their questions

I'm sorry, I didn't know that.

Ratul: no problem

hello, Aaron!

hello

I will come back when I have questions. Thanks!

Aaron: your turn! do you have a question?

Ratul: OK, sounds good

Yes i have a question about activity exceptions

Can i give an example?

sure

I created a demo app that i used to find out what the OS does with an activity when it crashes. https://gist.github.com/px-amaac/cbb318339ccbee...

um, OK

basically i was unaware that the OS tries to restart whatever activity is on the backstack when it crashes

My question "is there a way to prevent this?"

prevent what?

exceptions?

Basically i have an app and when it crashes it will crash multiple times

that doesn't really help me much

sorry i know the reason for the multiple crashes and i am fixing the core reason for multiple crashes but

i always thought that when the app crashed that was it

control returns to whatever preceded the activity

that could be one of your activities

or it could be something else, depending on what is on the back stack

so basically the app should resume gracefully if it crashes?

each activity rather

well, the activity will resume in lots of circumstances, such as the user pressing BACK

(from some subsequent activity)

and so it should be resuming gracefully in general

yes in my problem there is some settings that get destroyed in the crash

what are "settings" and how are they "destroyed"?

so when the activity comes back the api calls fail due to lack of these settings

and i am not sure how they are destroyed

what are "settings"?

basically i have an API class that has environment settings in it.

its a singleton i believe

then you have *much* bigger problems

ya i know

suppose we have Activity A

Activity A depends upon this singleton

yup

and Activity A does no defensive programming, lazy-initialization, or the like

(objectef: hello! I will be with you shortly!)

Aaron: but, in the normal case, when Activity A starts up, it is fine

Hello!

so Activity A is on the screen

and the user presses HOME

time passes

your process is terminated due to low memory conditions

but it hasn't been *so* long that your task has rolled off the recent-tasks list

now the user returns to your app, such as via the recent-tasks list

Android will create a new process for you

followed by a new instance of Activity A

and will put A in the foreground

and, if you are not doing anything to handle this case, A will blow up

without any of the init issues

because your singleton may not be set up

matheds running

ok and does this new process thing happen when the app crashes also?

I didn't think so, but I can't rule it out -- it's been a while since I played with this scenario

but, more importantly, even *without* the crash, you have to deal with this case

because i notice that i lose my logcat and debug stuff on crash

yes i agree

any singleton has to be a cache, and code dependent upon the singleton has to be able to survive if the cache is empty

fix that, and your problems with the activity getting control after a subsequent activity crashes should go away

let me take a question from objectref, and I will be back with you shortly

Do you mind if a stick around i have a followup question but i want objectref to get his question in.

objectref: your turn! do you have a question?

cool

objectref: your turn! do you have a question?

Hi

No, actually i got my subscription yesterdays and i started reading the book, so for the moment i do not have one. I just got in to say thanks for the nice book!

you are very welcome

if you think of a question, let me know

Aaron: back to you! do you have another question?

Ya seriously I recommended it to an android class that i TA for. They loved it.

FWIW, the book is free for qualifying college and university courses: http://commonsware.com/blog/2010/10/01/free-and...

I will let the teacher know

It has been suggested to me that i put the initialization of singletons in an extended application class to ensure that they will always be there. Any thoughts one way or another on this?

it usually doesn't solve any problems

there is little that you can do in an Application subclass that you cannot do in a regular singleton

But application is always there. So the problem of activity A starting in a new process. Would this not fix that because the new process would spawn the application class then the activity?

oh, the Application class will be spawned

so would a regular singleton, assuming that you are using some sort of static getInstance() accessor

that does lazy-initialization

Ok. that makes sense

since there is nobody else another one?

go right ahead!

In all of this i have a singleton class that handles my oauth tokens and has an async task to get tokens. In the pattern we just discussed of using a getinstance method how do i make that call with the async task and then prevent the app from continuing until it has tokens? basically it should be a synchronous call but because we want it off the UI thread we make it asynchronous.

callback?

your activity should basically have two states: ready and not-ready

if, when it is created, the desired token(s) do not exist, it goes into not-ready mode, then forks a thread/AsyncTask/whatever to do the background work

it then moves into ready mode when that work is done (onPostExecute(), event bus event received, etc.)

if, however, the desired token(s) exist already at creation time, the activity can just roll into ready mode

ok.

Thankyou very much

sure

Ill see you again some time you were a great help

happy to be useful!

Is there a way to get a transcript of this?

one will be posted to http://commonsware.com/office-hours/ shortly after the chat ends

thankyou

if anyone has any questions, go right ahead

Have a good day. Thankyou for the help.

you are very welcome