We Keep Coding

Using OO Observer pattern without updating object from which change originated

I'm building an application which contains a GUI and a Model. I'm using the Observer pattern (using java's built in interfaces) to update the GUI when fields in the model are changed.
This is generally working fine, but I have a situation in which a particular String variable in the model (specifically the url of a file) can be changed by two separate JTextFields (swing) the contents of which actually reflects the value of the model variable in question.
The issue I am having comes from the fact that an change in one of these JTextFields needs to cause an update to the state of the model, and the contents of the other JTextField. My Model ensures that notifications are sent to observers only in the case that the state of the model has changed. However, the process by which JTextFields are modified involves blanking it's text content then reseting it.
Without going into too much detail, the upshot of this is that the update / notification process gets stuck in an infinte loop. I have temporarily hacked around this by setting aside the observer pattern for this particular problem, but I was wondering if anyone could suggest a neat way of ensuring that a particular component is not "updated" by a change which originated from the same component.
Any help appreciated.

As discussed in Java SE Application Design With MVC, this is one of several Issues With Application Design. The suggested approach relies on a PropertyChangeListener, illustrated here. The PropertyChangeEvent includes both old & new values for reference.

This link which talks about a Bidirectional Observer may offer some help on this.
It does seem in your case that the Model and View are trying to update each other. The solution would lie in enforcing the direction of an update. For example Inner layer -> Model -> View and View -> Model -> Inner layer. So it wouldn't really be a true Observer Pattern.
The update(Observable o, Object arg) method of java.util.Observer does accept an Observable(Subject) object. This object can be used to provide a hint to the Model asking it to propagate the update inward rather than toward the View.
I gave it a quick try and found that setting up Bidirectional observer (using Java apis) is not as simple as I thought. But you could venture a try.

How to automatically update/load/refresh view in RCP application

I am developing one RCP application to capture and display http requests. The application is like a proxy tool but the functionality is very simple. Till now, I know view change could be triggered by some events: like: selection. But I don't know how to update/load/refresh the view with data changed automatically. In this case, the data should be the captured http requests.
Could you give me some insights? Thanks.
Updates
Some nice guys tell us to use observable pattern to do this. The following snippets is my code. But it does not work as expected. The ui cannot be refreshed.
IObservableList input = Properties.selfList(Sequence.class).observe(sequences); // Sequence stands for one request, sequences are a list of sequence.
tableViewer.setContentProvider(new ContentProvider());
tableViewer.setLabelProvider(new TableLabelProvider());
tableViewer.setInput(input);
Joseph

I recommend using the observer pattern. Your data becomes the subject. Every time your data is changed notify your view (observer) to refresh.
http://en.wikipedia.org/wiki/Observer_pattern

In case you parse the received data, have a look at the Eclipse Databinding framework.
The idea with this framework is that you can bind values from a model representation of the data (usually Bean or EMF) with the various SWT Controls that are used to display the data. The framework will then automatically update the content of the widgets when the model changes (and vise-versa if you let it :-)).
See this tutorial for an introduction to the framework - you can find plenty of examples and documentation on the web...
EDIT: Also see the snippets directory for various solutions to common problems...

Is there a Java utility class to do data management in a desktop UI?

Is there a Java utility class to help with data management in a desktop UI?
I am writing a UI to configure a network device that will be connected to the serial port of the computer while it is being configured. There is no web server for my application.
The UI has a large number of fields (50+) spread across 16 tabs.
I will write the UI in Java (Java FX?). It should run inside the browser when launched, and issue commands to the network device through the serial port. A UI has several input fields spread across tabs and one single Submit button. If a field is edited, and the submit button clicked, it issues a command and sends the new datum to the device, retrieves current value and any errors. so if input field has bad data, it is indicated for example, the field has a red border.
Is there a standard design pattern or Java utility class to accomplish the frequently encountered, 'generic' parts of this scenario? lazy loading, submitting only what fields changed, displaying what fields have errors etc.
(I dont want to reinvent the wheel if it is already there). Otherwise I can write such a class and share it back here if it is useful.

You need a data model : a set of classes with different kind of relationships (UML design may help).
You can learn more about MVC pattern.

Java encourages the Model Control View pattern for separating the levels of responsibility when it comes to the management of data.
Essentianlly the idea is to provide a model that a view can show to the user. The model doesn't care how its displayed nor does the view care about how the data is managed, they simply have an agree dead interface through which they can communicate

decorator pattern to allow different behavior of a model

I was wondering whether the use of a decorator pattern is good in case I want my model ("M part" of MVC) to raise Exceptions depending on their origin. I explain myself.
I have a class called Game which is a part of the Model. I have two Views : a GUI and a command line. I want my model to raise an Exception for command line view when the user enters a character instead of a number (for example). Of course I don't want this Exception to be handled by the model as it "belongs" to the command line and not to the Model itself.
To encapsulate those two different behaviors, I plan to decorate the Game class with two classes : CommandLineGame and GUIGame which have only one attribute : Game and handle their own kind of Exception. Is it a good idea ? Is there a better one ? The problem of such a solution is that every model class raising Exception depending on its origin has to be decorated...

What you are describing in the example is "input validation". Strictly speaking*, this belongs in the Controller ("C Part") of MVC.
The separation of concerns for MVC decomposes as follows:
View is there to 1) present a UI for the user to evaluate the state of the program (Also, what your program looks like visually) and 2) to receive the user's expression of intent (receive raw instructions on what they may want to do)
Controller is the actual interpreter of these "actions" or "intentions" from the user. It decides what it means for a user to click a particular button and what to call in your model. It decides whether a particular input actually makes sense given context from the UI (and in some case from the model).
Model should be View/Controller agnostic (Meaning the model should have no knowledge of the View/Controller). It should only be about the internal representation of what you are trying to "model". The advantage of doing it this way: you can have many different UIs, or change your existing UIs without affecting the model.
Overall, the idea is to lower coupling and increase cohesion.
I hope that makes sense =)
Depending on the language / framework, the lines between MVC components get blurred a bit. Some idioms will lump most of Controller into the View, but the encapsulation of logic should stay relatively similar.
*In practice, for defensive programming, input validation is done twice for mutual suspicion: they are broken down into client-side mediation and server-side mediation:
In this case, the Model part should handle the "server-side" mediation: it should check that the arguments passed to its functions actually make sense before proceeding.
Similarly, the Controller/View part should check the input as part of "client-side" mediation, so that it can warn the user right away, without passing it back to the model, and then eventually back to the view.

It will keep your code very clean, something i like a lot from an academic perspective.
On the other hand do you need to introduce this kind of design complexity for a simple problem like this?
So, if you need the code to be clean... GO for it.

Must every activity has own model?

I have just read the description of MVC desing pattern and I havesome questions: I am Android developer (junior), and I want to make my code more clear. So, should I use MVC for it? And must every activity has own model? Is there any good tutorial for it? Thank you.

It's already implemented. MVC pattern on Android
you need not to do anything, As Android is prebuilt MVC

MVC is kind of an idea more than a specific way of doing things (like a 1-to-1 relation between activities and models). The idea is to separate the model, view, and controller, so that stuff makes sense.
In Android, more than one activity can refer to a single model (for example, an activity with a list of houses you can search on, an "edit house" activity, and a map that shows them as points in their coordinates). So, to answer your second question: no, they don't need to have their own model.
And yes, you should use MVC, if it makes sense. Just think about your models as a separate entity from the actual application, and your activities as "users" of the models.

On Android, I've found the MVP (Model, View, Presenter) pattern to be a more direct correlation with the overall system architecture. Your activities comprise the Views, which in the MVP setup are responsible for managing their own events and controlling their own appearance. The presenter serves as a facilitator between the model and the view, providing the data when the View requests it. Depending on your needs, the presenters may or may not be a service. As for the View/Model ratio, it really depends on what you're trying to show on your screen at any one point. When android was running on phones only, it made sense to have pretty much a one to one correlation between Activities and your model. Now, the normal case is to have a one to one correlation between your model and your fragments, which your activity then marshalls about by showing the appropriate fragments.
If you want to do MVC, though, again, now that fragments are a tool in the toolbox this is much easier than it once was, especially with well developed event system (such as the one included in RoboGuice) - Think of your fragments as your Views, and your activities as controllers - Ordering your views about, providing them data from the model, and handling transitions to other controllers.
The choice of pattern depends on your needs - if one's application is to be heeavily service driven, MVP is probably a better way to go. If, however, the app is just a thin client over a database, then MVC might be easier. It's all up to you :)
'get started' resource for MVP : http://www.jamespeckham.com/blog/10-11-21/MVP_on_Android.aspx