It's not horrible, it's different. It's not more difficult or easier
than MessageBox.Show, it's just different.
> I need to not go forward with some code until the users has made its
> decision. To have to do these very messy workarounds is just too sad =
These are not workarounds, they're the wa
swapnil:
I dont understand the code that Romain posted. Would you like to help
me out, sending some code if you have a "modal dialag" as you were
looking for? I'd appreciate it =)
Regards,
Ted
On 4 Jan, 11:51, swapnil kamble wrote:
> Thanks Dianne for your nice explanation. I have used synchro
Interesting thread.
I actually want the exact same thing as swapnil kamble, coming
from .NET it is very nice to deal with MessageBox.Show. The Android
way is actually horrible from where Im standing (even though I really
like Android and the framework in general).
I need to not go forward with so
Thanks Dianne for your nice explanation. I have used synchronization point
between two threads with a timeout value. Its smoothly working for me.
Thanks Romain for pointing me to CounterDownLatch.
On Sat, Jan 2, 2010 at 2:14 AM, Dianne Hackborn wrote:
> On Thu, Dec 31, 2009 at 2:39 AM, swapnil
On Thu, Dec 31, 2009 at 2:39 AM, swapnil kamble wrote:
> Have you used MessageBox.show() API in Windows ? If yes then you can
> understand it easily what I am saying.
>
This is API is not really blocking the thread -- it is running a nested
event loop, until the user responds to the dialog. This
@Swapnil, when you say that you cant call Alert Dialog from non ui thread ,
you can do that using a Handler as i said.Did u try that out ? It works in
my case where i do an an AsyncTask (seperate thread)in which i communicate
with the server and based on response i decide which screen to show. For
Sorry, just re-read your original text, it seems that message passing
between threads is the way to go.
Just use two way message passing.
On Thu, Dec 31, 2009 at 12:09 AM, Miguel Morales
wrote:
> Why not use Thread.wait() and Thread.notify() to communicate with the
> working thread.
> Or perhaps
Why not use Thread.wait() and Thread.notify() to communicate with the
working thread.
Or perhaps message passing to tell the worker thread to wait until
further notice.
here's how I would do it, though I'm not sure about wait() and
notify() since I never use them myself. But I *think* it would go
If you want to block a worker thread and wait on something that's done
on the UI thread, you just need a synchronization point. The
java.util.concurrent package offers many tools to do that kind of
stuff. Here's an example using a CountDownLatch:
829 final CountDownLatch latch = new Count
swapnil kamble wrote:
> I have handshake process, where I have to provide an option to user
> whether to accept/reject and based on that user response I want to
> return a boolean value.
That sounds like one AsyncTask, triggering a dialog in onPostExecute(),
which then fires off a second AsyncTask
Hi TreKing,
Now there are two option to start this handshake process, one either from UI
>> thread i.e. starting from some onclick event listener. But I can't use this
>> way, because I want to block thread until response is not provided(modal
>> dialog).
>
>
> I still don't understand why do you
>
> Now there are two option to start this handshake process, one either from
> UI thread i.e. starting from some onclick event listener. But I can't use
> this way, because I want to block thread until response is not
> provided(modal dialog).
I still don't understand why do you feel it necessar
Let me reframe my question. My intention is not to block UI thread but to
block a thread when AlertDialog is shown till the user provides confirmation
response.
I have handshake process, where I have to provide an option to user whether
to accept/reject and based on that user response I want to re
If you block the UI thread, the dialog won't work. The user won't be
able to click it, and it might not even draw at all. So a very bad
idea :)
On Tue, Dec 29, 2009 at 10:33 PM, Frank Weiss wrote:
> Just like Treking, I'm puzzled by Swapnil's desire to block the UI thread.
> Perhaps if he explain
Just like Treking, I'm puzzled by Swapnil's desire to block the UI thread.
Perhaps if he explained what he does not want the UI thread doing while the
dialog is displayed, would shed light on the issue for all.
On Dec 29, 2009 9:59 PM, "TreKing" wrote:
> I can put my code in listeners but still
>
> I can put my code in listeners but still I dont want that thread to
> continue its execution
Which thread? The UI thread? I'm pretty sure you DO want the UI thread to
continue it's execution. Why would you NOT?
What are you trying to accomplish? I can't think of why you would want this
behav
I dont know whether this will work or not but did you try the handler of
Android ?
public Handler ScreenHandler = new Handler() {
public void handleMessage(Message msg) {
// Handle on click.
}
}
The above handler can be put in the UI thread.
And in your onClick
ScreenHandler.sendEmptyM
Thanks for your replies. I can put my code in listeners but still I dont
want that thread to continue its execution, unless response is not given,
just like what windows MessageBox.show() does.
I have got a workaround for it, but its not at all a standard way. I will
not use it too.
Anyway from th
On Dec 29, 1:22 pm, TreKing wrote:
> Um ... why don't you just put the code you want to execute in the onClick
> handlers for the Yes and No options, respectively?
> That's pretty much the point of having them ...
>
+1 for the win.
I agree, just take what ever action is necessary and put it in
19 matches
Mail list logo
