hello, Jeff!

how can I help you today?

Hi Mark.

Due to the vagaries of the Android camera, I decided to added one time camera check/setup screens to my app for the camera preview and photo storage. It's a simple preview screen with a rotation button and a Next button. When the user hits Next button, I display a Progress Dialog explaining that the app is saving the picture. Once the Save is done, I present the stored image rotation check/setup. All this works fine except for KitKat.

In KitKat, the ProgressDialog displays but the onPictureTaken() callback, which is executed after the ProgressDialog, is not executed. So is there a best practice for presenting the progressdialog that might avoid the problem?

OK, I'm lost already

if it is executed, how can it not be executed?

OK. let me try again

I have a button listener. OnClick() has the following steps:

A. present ProgressDialog

B. Create a class that implements PictureCallBack

C. call the camera.takePicture

Pre-KitKat, this all works fine

In KitKat, step C is executed. BUT the onPictureTaken() callback is not executed (based on logs and phone display)

does that clear up the sequence at least?

yes

what evidence do you have that this has anything to do with the ProgressDialog?

have you removed the ProgressDialog, left everything else intact, and it works reliably?

when I comment out the ProgressDialog, onPictureTaken() is called and the app works as desired

yes to your question

that's certainly strange

In the logs, I see that the preview's surfaceChanged() method is called in KitKat

but not in other versions

is the app totally frozen in KitKat? IOW, is the main application thread being blocked?

the ProgressDialog wheel is spinning

hmmmm

I have tried AsyncTask and Runnable to solve the problem but neither worked

how are you showing the ProgressDialog? via a DialogFragment?

I think that will have problems in general

for example, that won't survive a configuration change

what do you suggest?

well, I avoid ProgressDialog like the plague

I'd use some other progress indicator

such as?

ProgressBar, AnimationDrawable on your button, etc.

if you really want a ProgressDialog, try showing it with a DialogFragment and see if that helps

that'll at least improve your support for configuration changes

and it's possible that it will clear up this particular problem

I have not run into a scenario where takePicture() fails with nothing mentioned in logs

I can swap to ProgressBar

I'm now just intellectually curious. why is progressDialog to be avoided?

general philosophy in mobile UX design to avoid blocking dialogs in general, wherever possible

Thanks - I'll try ProgressBar

That raises another question. Is there anything like StackOverflow but for design? For example, post a question like "Should I use blocking dialogs?" One designer gave me some tips and I realized how poor my design esthetic is.

with regards to modal dialogs (though not strictly for mobile): http://ux.stackexchange.com/questions/12637/wha...

Thanks - and thanks for the help. Have a great day.

you too!

btw, I enjoyed your talk at StackExchange

ah! glad you liked it!

I just skimmed the modal dialog post - WOW

and, if you want a more Android-y perspective on the matter, here's Reto Meier's rant on the topic: http://blog.radioactiveyak.com/2010/08/what-you...

it's a bit old (2010 -- where have the years gone?)

hello, Ron!

how can I help you today?

Hi Mark, hope I'm not too late.

~12 minutes left

what's on your mind?

no, because one button cannot serve two roles

either it adds a line feed, or it is "done"

you'd need two action buttons

and that's not guaranteed to be supported, and probably usually isn't

exception would be in landscape mode, where "done" or "next" would appear to the right of the text entry area, above the keyboard

OK, I guess I'll look into wrapping into the 2nd line, right now the "Done" version has the user edittext just going off the screen.

that's a question of constraining your EditText width

combination of layout rules and android:maxWidth

The width is constrained, I meant to say extra text disappears rather than seeing it on the next line. Thanks, I know what I need to focus on now.

that's a wrap for today's chat

the transcript will be archived at http://commonsware.com/office-hours/ shortly

the next chat is next Monday at 4pm US Eastern Daylight Time

have a pleasant day!