General Application Design - Events + Async - modeling

I have an issue with designing my application.
On my login form, I fire off an event in my ViewModel that's handled in the View (it displays a progress bar).
Then I query the database
Based on the query result I fire off an event from my ViewModel whose handler displays a message based on the result
The problem is when the query executes so fast that the (async) event handler doesn't even get to initialize the progress bar before the second event gets fired. The second event handler registers that there are no progress dialogues open so it doesn't try to close the open one before displaying the message. And when the user acknowledges the message, he is left with a indeterminate progress dialog which blocks the rest of the UI.
What design pattern should I utilize to avoid this race condition?

Related

Intercept (and perhaps cancel) page's mouse/keyboard event handlers

I'm trying to create a Chrome Extension that deals with selected text. Some website pages' otherwise selectable text content has click/mouse-up/down event handlers that navigate to a new page.
Is there a way from the background or content script to temporarily disable (and restore) the page's arbitrary event handlers without interfering with the native text selection?
Worst case I'm thinking of is to detach, clone the body html, allow the selection, and then restore the bound original. Seems like trouble.
Thanks!
Most HTML DOM events follow the capture-target-bubble event model. This means, for example, that if you click on a button, that the "click" event is first dispatched at the root, all the way down to the button, then back up. Event propagation can be stopped, which prevents the event listener at the next level from being notified of the event.
The earliest possibility of receiving the event is at the root, often window at the capture phase. To bind an event listener to the capture phase, use addEventListener with the third parameter set to true:
// in a content script, at run_at:document_start
window.addEventListener('click', function(event) {
event.stopImmediatePropagation();
}, true);
Many web pages use jQuery to manage DOM events, which binds the event listeners at the bubbling phase, so the previous method will work on most sites. If the page does not use jQuery, then you have to bind your event listener at document_start to make sure that your event listener is triggered before every other event listener.

Cocoa: Delaying one method call until a subsequent call is processed

I've found myself in the following situation: I've got an NSTableView subclass with an active cell. when I click elsewhere on the user interface, the delegate method (i) is fired, this in turn fires (ii) (my own method) cocoa then proceeds to process the click, resulting in the final two calls. I was surprised and disappointed by this sequence, since I had assumed the mouse click would be the first rather than the last event processed. It also causes me a problem because the ideal implementation of manageState is dependent on some of the processing I do in mouseDown:, but of course when manageState is called mouseDown: has not yet been executed.
Is their a way to delay the execution of manageState until mouseDown has returned? For example, in manageState I'd say something like Stop! a mouse down event might be in the events queue. Wait until it's finished, then resume. As the previous sentence implies, it's also possible that this method could be triggered by something other than a mouse down. In this situation, there's no need to look out for a mouse down event and processing can continue as normal.
MOUSE CLICK on NSTextView while NSTableView cell has focus...
+-------------------------+--------------------------------------------------------+
|Event |Triggered because |
+=========================+========================================================+
|controlTextDidEndEditing:|The mouse click ends the editing session |
| |of the active cell in my table view |
+-------------------------+--------------------------------------------------------+
|manageState |This method is a selector that belongs to a notification|
| |that is fired from within controlTextDidEndEditing: |
+-------------------------+--------------------------------------------------------+
|becomeFirstResponder |I clicked on the NSTextView instance |
+-------------------------+--------------------------------------------------------+
|mouseDown: |Finally, the click that started it all is processed |
+-------------------------+--------------------------------------------------------+
I figured this one out for myself. I feared I'd have to cobble together a threads-based solution, but a bit more docs-scouring turned up the NSEvent class method addLocalMonitorForEventsMatchingMask:handler.
When my app starts I call this method, define the associated block, and 'tell' the method what events I want to look out for. Then, whenever one of these events is detected, the block runs. Crucially ,this happens before any of the processing precipitated by the event is set in motion. In the block you have the opportunity to stop the event in its tracks, or let processing continue, you also have access to the event itself . Going back to my question, this means I am effectively inserting an additional row at the top of the table. This was perfect since it allows me to act on the event before any of the subsequent event executes.
[NSEvent addLocalMonitorForEventsMatchingMask:NSLeftMouseDownMask
handler:^NSEvent *(NSEvent *event) {
// whenever an event of type NSLeftMouseDownMask is detected, this code
// will run before any other event processing
// do some processing, then...
return event; // or nil, if you want to block the event
}];

How to handle LWUIT dialogs shown on background threads

I have written an application in LWUIT targeted for a J2ME phone (Sprint DuraXT). The application is for pickup and delivery van drivers. It receives dispatches from a back-end dispatching system that describe pickups and delivers the driver must make. As the drivers, execute the pickups and deliveries, the driver enters status information that is sent back to the dispatching system.
Now, during the processing of a pickup or delivery, the driver may be presented with error dialogs (incorrect field entry), yes/no confirmation dialogs (confirming some action) and information dialogs (indicating some status the driver should be aware of).
In addition, there is a background thread listening for dispatches coming from the back-end server. In the current implementation, this background thread can also create yes/no confirmation dialogs and information dialogs. These dialogs are more like an alert as they have an associated sound, but they are simply dialogs.
As long as these two dialogs do not occur “simultaneously” every thing works as expected. You can dismiss the dialogs and the app proceeds as expected.
However, when you are on a screen and there is a dialog already showing and a second one from the background thread occurs, you sometime wind up with the wrong screen showing and it is “frozen”. E.g. the soft keys have no effect.
My hypothesis is that there is a race condition between the threads that are dismissing the dialogs. It goes like this. The EDT is blocked showing the dialog that arises as part of the form’s logic. The background thread is also blocked showing a dialog. Now when the dialog showing on the EDT is dismissed, the form is restored, but the EDT may go off and display another form (via show()). When the dialog displayed by the background thread is dismissed, the form which was showing when the dialog was initially displayed is sometimes restored. Now, the display shows a different form than the one the EDT might have shown.
It is pretty clear that this problem is caused by the dialogs resulting from the activities of the background thread. So the basic question is: “How to handle the dialogs arising from the background thread?” I have some thoughts but none yield a particularly clean implementation. I am hoping somebody has had to deal with this same problem and has a suggestion.
I have tried synchronizing the dialog construction and display so that only one dialog can get displayed at a time. This certainly improves the UI, but does not fully resolve the problem. The race begins when the first dialog is dismissed. Here are some other ideas,
If a dialog is shown by a thread other than the EDT, call show on the form at the top of the display stack when the dialog is dismissed. This is a bit of a hack, but may be a workaround.
Run dialogs to be shown by the background thread on the EDT. There are several ways to do this, but the question is will it resolve the problem? Will using an EventDispatcher help? I have experimented using an EventDispatcher to fire an ActionEvent containing a subclass of a Dialog as a source. The subclass contains a show() method which invokes the correct form of the Dialog show method. The class holding the EventDispatcher (global to the application) listens for these events. When the event arrives, the show method is invoked. For information dialogs that simply continue execution from wherever they are dismissed, this should work. For yes/no dialogs, you may have to create something like yes/no callbacks to handle the bifurcation in the logic. And what is not obvious is if this will actually serialize the processing of the dialogs on the EDT thread. This seems complicated.
Any ideas?
I actually hit upon the solution after a bit of experimentation. Because the Dialogs are part of a more compilcated action involving yes/no Dialogs and database queries, I found I had to wrap the whole action in a class which implements the Runnable interface. Then I run the action via Display.getInstance().callSeriallyAndWait(runnable).
So others may benefit from this discussion, here is a example of one of these classes with the action embedded in the run method.
private class CancelOrder implements Runnable {
private KWMap order;
public CancelOrder(KWMap order) {
this.order = order;
}
public void run() {
String orderNum = getString(order, OrderTable.ORDER_NUM);
if (legStatusTable.isOrderStarted(orderNum)
&& !orderTable.isOrderComplete(order)) {
String msg = "You received a cancellation message for Order "
+ orderNum
+ " which has been started but is not finished."
+ "\nDo you want to keep it?";
if (app.yesNoDialog(msg, "Yes", "no")) {
sendCancelResponse(order, "Yes", "");
} else {
deleteOrder(orderNum);
sendCancelResponse(order, "No", "");
}
} else {
// order has neither been started nor completed.
deleteOrder(orderNum);
sendCancelResponse(order, "Yes", "");
app.alertDialog("Dispatcher cancelled Order " + orderNum);
}
}
}
The key thing here is that the action contains logic depending on how a user responds to a yes/no Dialog and there are operations on an underlying database and messaging subsystem as well. Except for the Dialogs, nothing in this action blocks the EDT for more than a few 100s of milliseconds, so the application runs very smoothly. The app coorectly handles dislogs stacking on top of each other which was a problem with the simple apporach of letting these actions run on the background (non EDT) thread.

GXT custom event handler code executes multiple times

I have implemented MVP pattern in my GXT project. The system registers customers as part of it function. Also the system user can search for the registered user providing the id.
i have added an OnClick event to the "search customer" button.
/* On click search button */
view.getBtnSearch().addListener(Events.OnClick, new Listener<BaseEvent>() {
#Override
public void handleEvent(BaseEvent be) {
eventBus.fireEvent(new CustomerRegistrationTabSelectionEvent(0, false));
eventBus.fireEvent(new CustomerFetchEvent(view.getValueCustSearchParameter(), view.getValueCustSearchValue(), true));
}
});
The CustomerRegistrationTabSelectionEvent does select the relevant tab and enables other tabs. Thats all it does.
Here is the handler for the custom event CustomerFetchEvent.
eventBus.addHandler(CustomerFetchEvent.TYPE, new CustomerFetchEventHandler() {
#Override
public void fetchCustomer(CustomerFetchEvent event) {
searchCustomer(event.getParameter(), event.getParameterValue(), event.isOpenFirstTab());
}
});
The issue is the search customer method is executed multiple times and if there is a invalid search the error message dialog shows multiple popups. Within the searchCustomer method i call for service which fetch me the customer data or show the popup error message if the search is invalid.
im using GXT 2.2.5 and JRE 1.6.
Could anyone help me in finding out why the code is executed multiple times?
Added Later:
When i run the application first time the code is only executed only once, therefore only 1 popup. Then i logout of the system and log in again (navigating to the same page where the "search customer" button exists.) and the code is executed twice. Likewise equal to the number of times i create/navigate to the particular page, the code executes. Is it actually adding the event handler code without removing the last one every time i recreate the page?
Yes, it seems that 'addHandler' adds handler multiple times, but stores previous context. Your code should add handlers only once, on initialization phase. You can check the number of handlers with 'getHandlerCount' method.
Ya. I fixed it!Here is the solution Unbinding presenters necessary in GWT
U can read more here. http://draconianoverlord.com/2010/11/23/gwt-handlers.html
what happened actually was, the presenter objects where i have registered with HandlerManager to receive events were not garbage collected. Because though i remove the reference to the presenters still the HandlerManager holds a reference to those objects. So every time i kept on creating new presenters on top of the old presenters of the same class. so a event is listened by multiple objects of the same class. so u need to ensure that the unused presenters are garbage collected by removing the registered handlers
in HandlerManager.

Saving the states of JavaFX controls on exit

I have a bunch of control objects (TextBoxes, to be precise) that get injected into my code using the #FXML annotation during the FXML load.
I would like to save the states of these controls, specifically the text values, when the user closes the Scene by clicking the close box on the title bar.
However, when I trap the CloseRequest event in an OnCloseRequest handler I find that the values of the control variables are null (the original injection works, so this is something that happens in between the loading of the FXML and the calling of OnCloseRequest).
Can anyone explain this behavior and/or suggest how I can get the functionality that I want?
TIA
onCloseRequest is
Called when there is an external request to close this Window. ...
(from Javadoc). One of the meanings of "external request" is when you close the window through OS native window close button. The closeRequest event is not triggered through the programmatic stage.close() or stage.hide() calls. So consider to handle onHiding or onHidden events.
Otherwise post your OnCloseRequest handler code.

Resources