How can I create a text entry dialog in Android? Ask Question 4. What is the best way to create a modal text entry dialog for android? I want to block until the user enters the text and hits the ok button, then extract the text from the dialog, just like a modal dialog in awt. The Dialog class is the base class for implementing a dialog. Android provides several standard dialog implementation, AlertDialog, ProgressDialog, DatePickerDialog or TimePickerDialog.Your DialogFragment can implement the onCreateDialog method and return such a dialog implementation.
I would like to implement a method that displays a dialog, waits until the dialog is dismissed, and then returns a result depending on the dialog contents. Is this possible?
I am actually trying to implement an interface which has method 'public String getUserInput()', where the returned String must be retrieved via dialog. This is easily done in java, seems impossible in android?
EDIT: Posting some sample code as requested in comment
getInput()
must be called from a background thread (I call it from an AsynchTask). getInput() displays a dialog and calls wait. When the ok button is pressed on the dialog, the dialog sets the user input in a member variable and calls notify. When notify is called, getInput() continues and returns the member variable.ab11ab11
7 Answers
Is this possible?
No. There is no blocking UI model in Android. Everything is asynchronous.
UPDATE
In response to some of your comments on the question itself, you cannot display a UI from a background thread. As I wrote in this answer, there is no blocking UI model in Android. Just put your code in the button handler for your dialog that you want to have executed when the dialog is accepted, such as in this sample project.
CommonsWareCommonsWare
Thanks for all the feedback, I was able to solve this using a background thread along with a wait() and notify(). I recognize this isn't the greatest idea for the given paradigm, but it was necessary to conform to a library that I am working with.
![Box Box](/uploads/1/2/4/1/124194652/349048691.jpg)
ab11ab11
The right way to do this is an event driven program model, ie, 'don't call us, we'll call you'.
In simple console mode programming, your code tends to call blocking input functions, which don't return until you've gotten a value.
Many gui programming environments work differently - your code is not normally running, but instead it's called by the operating system / window manager when something of potential interest happens. You do something in response to this and promptly return - if you do not, you can't be notified of anything else since the OS has no way to contact you until you return. (In comparison to win32, it's as if the message loop is implemented by Android, and you only get to write the rest of the code that the message loop calls with events - if you don't return promptly, the message loop hangs)
As a result, you need to rethink your concept of program flow. Instead of writing out a to-do list as a simple series of statements, think about it as a sequence of actions which depend on each other and on input. Remember what action you are currently on in a state variable. When you get called with an event such as user input, see if that event means it's now possible to move on to the next step, and if so update your state variable before promptly returning to the OS in order to be able to receive the next event. If the event wasn't what you needed, then just return without updating your state.
![Text Text](http://simpledeveloper.com/wp-content/uploads/2014/04/how_to_create_custom_dialog.png)
If this model won't work for you, what you can do is write a background thread of program logic which runs like a console-mode application using blocking input. But your input functions will really just wait on a flag or something to be notified that input is available. Then on your UI thread where Android delivers events, you update the flag and promptly return. The background thread sees the flag has changed to indicate that data has been provided, and continues execution. (Something like an android terminal emulator takes this to an extreme, where the background component is actually another process - a console mode linux one, and it gets its input using potentially blocking I/O from pipes. The java component accepts android UI events and stuffs characters into the stdin pipe and pulls them out of the stdout pipe to display on the screen.)
Chris StrattonChris Stratton
I had a hard time understanding all the solutions offered above so far so I found my own one.
I wrap the code thats supposed to be performed after the user input is OK'ed in a runnable, like so:
Then right below that I pass the name of the runnable function to the user dialog method.
The userInput method is based on the alertDialog builder like described above. When the user input is Ok'ed it starts the intended runnable.
SkandalosSkandalos
Something like this would do
The launch is:
You get the result by using
Pentium10Pentium10
CASE: My data was ready to be processes after a preference change listener event and I needed to add a String queried from user. It doesn't appear possible to pop an alert dialog while the options menu is open...so I had to wait. I threw the half complete object into the next activity in the workflow and set its onResume() to check if its placeholder was !null in which case I popped the dialog and finished up the object *'in the button handler of the dialog'*.
Since this is my first post I can't vote for the correct answer given above but want to save anyone else running into this the time and in-elegance of less correct solutions. The dialog is the place.
user816728user816728
You can think in terms of a state machine where if you initially require first-time user input you can have a flag set to mark 'user input needed' or whatever. Then upon processing an event you check that flag and if set you fire up a dialog as the only action for the event and unset the flag. Then from the dialog event handler after handling user input you can call the code normally intended for the case when a dialog is not needed.
Gunnar Forsgren - MobimationGunnar Forsgren - Mobimation