fuin.org

Optimized View and Logic (Controller) Separation with Swing

---

Part 5: Blocking of the Surface During Prolonged Tasks

The JXLayer Project has been looking into solutions for the blocking of surfaces for quite some time. Based on the former, jbusycomponent offers some useful expansions. Our in-house developed ControllerResultBusyAdapter class utilizes this component and can therefore be used in the panel rather easily:

public class AddressListPanel extends JPanel {

        // ...

        buttonDelete.addActionListener(new ActionListener() {
            public void actionPerformed(final ActionEvent e) {

                class DeleteListener extends ControllerResultBusyAdapter<AddressListPanel>
                        implements AddressController.DeleteAddressListener {

                    public DeleteListener() {
                        super(busyComponent);
                    }

                    @InvokeAndWait
                    public void addressDeleted(Address address) {
                        // TODO Remove address from UI
                    }

                }

                final Address addressToDelete = getSelectedAddress();
                addressController.deleteAddress(addressToDelete, new DeleteListener());

            }
        });

    }

    // ...

}

While this method is not yet the most beautiful approach, one must take into account that the development of the JmsMvc4Swing Framework is still in its very early stages. Maybe one of our readers will come up with an excellent idea as to how we could further improve it.
 
Having said that, what about the sub-categories of our requirements?

Allows precise configuration of what is being blocked (entire frame or panel only)

Given that the implementation is message based, it is not a problem to set up other JMS receivers. For instance, the frame could be blocked each time the controller method is requested. In this case, the panel would not implement any blockage of its own.

User can abort the process at any time / Progress bars can be displayed if required

The annotation @MethodCancelable in the interface method allows the user to define whether an Abort label is visible or not. Command @ProgressDeterminate makes it possible to activate a progress bar:

public interface AddressController extends Controller {

    // ...

    /**
     * Loads a list of addresses and notifies a listener.
     *
     * @param selectedAddress
     *            Currently selected address or null if no address is selected.
     * @param listener
     *            Gets informed about the results.
     */
    @MethodCancelable
    @ProgressDeterminate
    public void loadAddresses(Address selectedAddress, LoadAddressesListener listener);

    // ...

}

If the process is aborted via the surface, the relevant processing in the controller implementation is not actually aborted. All that happens is that the MethodResultReceiver is terminated. The controller may actually continue to send additional messages; however, the surface does not know anything about it.
 
Next Page: Pending Issues/Problems & Conclusion
 

---

 
Page: 1 / 2 / 3 / 4 / 5 / 6 / 7