When writing Swing or AWT applications, I'm aware that GUI changes should always be done in the EDT. How does this translate to writing GWT applications?
I'm looking at a scenario when I call the following.
myRequestBuilder.sendRequest(myRequestDate, myRequestCallback)
myRequestCallback modifies the GUI. Having such a construct in Swing, I would make sure that the myRequestCallback invokes the EDT for the GUI changes. Does GWT require me to do something similar as well?
On the web (in browsers), it's dead easy: everything always executes in the event dispatch thread.
See also http://www.html5rocks.com/en/tutorials/workers/basics/
Related
I an implementing an IDE based on XCode design. It has been a lot of learning.
I need to update UI without blocking it.
I already have a pair of threads
using Grand Central Dispatch.
Basically I have an Interpreter, and an UI with an codeView (NSTextView) and an outputView (NSTextView). When I press play/run the IDE runs the code. It launches two threads, both with an while loop. One to run the program, the other to update the UI from any output or message sent from interpreter.
Something like this:
// program execution thread
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),
{
self.interpreter_s.execute()
});
// update UI while interpreter thread is running
dispatch_async(dispatch_get_main_queue(),
{
self.updateUIWhileInterpreterRunningThread()
});
}
They both communicate one with the other, so they have concurrency.
According with the research I've made, it's recommended to update the UI using the main_queue(). However, when I do this, it blocks the UI from receiving user input.
In my case, this causes the stop button to be rendered useless.
So I need an way to update the UI from the updates from interpreter thread without blocking the Views from user input.
Any thoughts?
I have huge preference from an solution already using Grand Central Dispatch. I also want to avoid dispatching UI Updates from the interpreter thread, since this could be terribly inefficient in this particular case.
Currently, I'm using the powerful SetWinEventHook() function to catch some user-interface's actions like minimizing and maximizing from other window runned by programs on the computer.
So I inspired myself by using the code provided by BrendanMcK on this post and it does work (I mean: the callback function is called when an event occurs) until the line
MessageBox.Show("Something")
is present. But I don't want to use any form or window for this program..
After some research, I figured out this kind of hook needs a message loop to allow the redirection of messages from other window handles. Apparently, calling the thread using Application.Run() should do the trick, but I would prefer something cleaner, in the C# object itself.
So my question is: is it possible to create a message loop inside an object's method?
http://bytes.com/topic/c-sharp/answers/557342-thread-message-loop-c
No, the function doesn't require a window handle so no "form" is needed. But the MSDN docs for the function is quite explicit:
The client thread that calls SetWinEventHook must have a message loop in order to receive events.
A message loop is universal in any program that want to receive notifications that are generated externally by other processes or threads. It is the common solution to the producer-consumer problem. Clearly any GUI app has a need for such a solution, Windows messages are generated by the operating system. It isn't different for SetWinEventHook(), the accessibility events originate in other programs. There is no clean mechanism to "interrupt" a thread and make it run other code, the re-entrancy problems that causes are extremely difficult to deal with. The thread has to co-operate, it must be idle and ready to receive a notification to safely process it. A message loop solves that problem.
Pumping a message loop (calling Application.Run) in a method is certainly possible. But do keep in mind that the method won't return until you explicitly stop the loop with Application.ExitThread. There is therefore usually only one good place for that call, the Main() method of your program.
Starting your project with a Winforms or WPF project template is a very good way to get this right. You have no need to actually create a window, call Application.Run() without an argument, after pinvoking SetWinEventHook.
I'm new to iOS development (and Obj-C), and I'm trying to port an existing C program to iOS.
The C program usually runs in the console, but I want to make a UI for it on the iPhone. I've already ported the C code, and when the simulator is run I can get the printf output in the console window. I want to avoid changing the original code as much as possible, so this is my plan:
The program takes some time to execute, so I think I need to run it on a seperate thread. It look likes I'll only need an NSInvocationOperation to call it's main method.
I will redirect stdout to a pipe.
On another thread, I will read from the pipe, and throw this to the UI. I'm not sure what might be the best concurrancy API to use for this.
Is this a good strategy for the iOS, or is there a better alternative for porting this? Are there any pitfalls I should look out for?
For concurrency, use the dispatch queues for quickest programming. See this guide: http://developer.apple.com/library/ios/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html
To print to the screen, you could do this in many different ways, but just use a UILabel if you just want get text up there right away. You can also format it nicely later.
Main pitfalls for multithreading are like on any OS - locking any data models that have simultaneous read/write. You can use #synchronize or make your dispatch queues thread safe by using dispatch barriers also noted in the linked guide above.
From what I understand, the entire client side of a GWT application is converted to Javascript when you build, therefore I suppose this question is related to both Javascript and the possibilities that GWT offers.
I have a couple of dozen processes that will need to be initiated in my GWT application, each process will then continuously make calls to a server. Does GWT support threading? Does the GWT client side support threading?
EDIT:
This link states:
No JavaScript knowledge required If you’re just a user of the framework,
which I am for the matter of discussion, you do not need to know JavaScript
in order to write dynamic content, be it client-side such as rolling frames,
docking panels or scheduled “multi-threading” tasks, or server-side calls
using XMLHttpRequests (aka AJAX).
or scheduled “multi-threading” tasks, what does this mean?
JavaScript doesn't support multithreading. However, GWT has a class to 'simulate' threading, which is not real multithreading, but in most cases does what you need: com.google.gwt.core.client.Scheduler.ScheduledCommand. The technique is based on the timer class, which executes a method after the given time elapses.
For example, when placing the following code in you own code, the scheduleDeferred method will return directly and your code continues after the command, while the execute() method is executed using the timer:
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
public void execute() {
.. code here is executed using the timer technique.
}
});
You can create a repeating command RepeatingCommand, which can be used to run the command more than once. Start it with Scheduler.get().scheduleIncremental() that will execute the command until the execute method returns false. You can use this to split tasks into sub tasks to get better 'threading' behavior. The Scheduler supports some additional methods to start a scheduled command differently. See the JavaDoc for more details.
Edited and updated with new GWT class instead of the deprecated DeferredCommand.
There is work on Web Workers as part of HTML5 that is implemented in a number of browsers, but not on all (most notably internet explorer). You could use these features where available, but what you should do is look at the javascript programming model.
Javascript generally works asynchronously. Requests are fired off and at some point their answers are received as an event. You can have a large number of pending requests at the same time. This will require a bit of a redesign of your system though.
New way is to use a Scheduler
JavaScript doesn't support multithreading, so whatever GWT does, multithreading has to be done solely on the server side, because GWT can only use features that are already available on the client side.
I am trying to write a test case where I have to access UI Thread.
Does Nunit provide a way to access the ui thread or is there anyway I can execute some code on UI Thread in my test case.
Thanks
Update: I'm using winform. The usual way is to have the presentation layer and write the test cases against it but in this situation I have a grid that I need to work with and to populate it, its DataSource property needs to be set on UI Thread.
That very much depends on which technology you are using for your UI. Depending on that it might be possible to setup the NUnit runner thread to act as your UI thread.
Genrally though, it is recommended to make the actual UI layer as thin as possible to reduce the amount of UI-code to test.
If you really need to have a live WinForms control on your NUnit thread, consider using Application.DoEvents() which will handle all currently pending events in the message queue. Be aware that doing so might bring you other problems though.
You could try NUnit Forms, but I'd second David's recommendation to take as much logic as possible out of the UI layer.
There is a 'RequiresSTA' attribute you can specify on the test that will run it in the same thread as the NUnit UI.
I discovered this when trying to write a test for a TIBCO Rendezvous message. The listener has to be set up in the main UI thread (blame TIBCO, not me!), otherwise the call to getAutoDispatchQueueGroup returns an error "Object cannot complete the requested operation".
I tried using WindowsFormsSynchronizationContext and BeginInvoke, and neither worked.
For NUnit 3+, I got this working by declaring on a test class with [TestFixture, Apartment(ApartmentState.STA)] or on a test method with [Test, Apartment(ApartmentState.STA)].
Also see this related question.
NUnit has no builtin support AFAIK. You can execute code in your UI thread of course, but the 'how' depends on the UI technology you use (WPF or Winforms)
Look for something like BeginInvoke() and pass an anonymous delegate to it that you can define in your unit test