I am working on my first Java GUI and I think I've decided on a MVP architecture (thanks in part to this great article).
However, a key component of this architecture appears to be that the model notifies the presenter when a change to the model occurs. I'm working with a database API for the model that I don't control. Therefore I have no way of forcing the model to implement any sort of event notification.
In this situation, how is this generally handled? Do I make wrapper classes around the API that implement event notifications? This seems costly and doesn't handle the case when the model is modified outside of the GUI.
Update: I think I've found the answer to my own question. What I'm going to be dealing with is a passive model that doesn't participate with the view or presenter at all. I found my answer here.
Related
In a MVC-project, I want the view to listen to the model. So when ever something is changed in the model I want to notify the view, triggering it to update itself accordingly. Previously I've used observer/observable for this type of situation but since they are deprecated I'd like to learn how to use listeners for this. What would be the equivalent to having an object in the model implement Observable and a view object be an observer of that? I've used java's EventListeners for listening to GUI components but are there any listeners specifically intended to listen to the model? Are there any good articles with information on how to choose listener?
Thank you!!
Java Event's library is made so it can be used for any purpose. They are widely used in Swing to handle GUI events, however, they can be used in any other context.
To be honest, if you really need a specific solution you could always implement your own listener, it is not that hard.
If your model follows the JavaBeans standard, I will suggest using a PropertyChangeListener. That way you can track any change made to it.
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.
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
Please excuse the verbosity of this question, as in writing it I am attempting to think through my design problem!
I have inherited a Swing application which requires re-architecting into an RMI application. The customer requires the Swing GUI to run locally and communicate via RMI to a remote Server process, which encompasses a Controller class which directs calls to sections of business logic and back end database persistence when stimulated by EventListeners, which bridge the gap between the Swing Client and the Controller.
I am to implement an MVC design to allow for new Views to be developed for use with the server.
Currently, the Swing Client GUI contains a JTree which is populated using a DefaultTreeModel. This Model is constructed using DefaultMutableTreeNode objects which are populated with Business Object state via a BusinessObject mapper that sits between these objects and my Data Source.
I have no problem understanding how the Client and the TreeModel are linked: I have established a TreeModelListener to look out for changes to the TreeModel. If the TreeModel object changes, I redraw the JTree by calling its treeHasChanged() method.
However, I am having a headache trying to picture what process would stimulate the TreeModel, so that its contents are repopulated with the latest data in the database, which would in turn invoke my TreeModelListener to update my GUI's Jtree. Who should "own" the TreeModel? Should it be a Class in the model which makes up a piece of the Controller's state? Should the Actions in the Controller by the GUI's EventListeners make a hard call to run a routine to refresh the TreeModel?
Or alternatively is the TreeModel an extension of the GUI Widget, in which case it is a View component? If so, what would be the proper manner in which to invoke a refresh of the state of this object?
I should probably note that I have been thinking in terms of Observers and Listeners in recent days, so I am probably guilty of trying to invoke behaviour to occur off the back of an observer firing.
Yours, very confused!
I'm not sure if you decribed about AbstractTreeModel or DefaultTreeModel, I think that this article Understanding the TreeModel is still best around, and link to the JTree tutorial
for reall help you have to edit your question and post image of your headache in the SSCCE form, here are tons of good bases for creating SSCCE
In addition to #mKorbel's informative links and #Shakedown's comment, consider using SwingWorker to periodically rendevous with your middle tier and update your TreeModel, perhaps in response to a Timer. There's a related example here; note that the GUI remains responsive as the query runs. Of course, it's up to your application how often the update needs to run and how frequently you update the GUI.
I got my head around the problem.
I have decided it is a bad idea for Swing API to be present in the Model of my application, since my application is one which can take many different types of UI's (Headless, Swing, Web).
Thus I have decided that the correct approach is for the TreeModel object to live in the View, and be populated by a View Helper which provides access to a generic presentation of the Model tier to any interested UI.
Hey all, I'm currently working on a Java Swing application and I was looking for some guidence. The application is fairly small, but I'm noticing that as the code base is growing larger, that I have an awful lot of coupling in my object graph. I'm relatively new to Swing, but I've been programming long enough to know where this is headed.
The biggest problem I'm having is setting up my event handling. How should my child windows and objects be communicating events to my higher level objects without having references to them? I've done a fair amount of MVC web coding. Does this pattern lend itself well to Swing? Should I be building my own controller? I guess I'm just fishing for patterns that people have found useful working with Swing.
Thanks in advance for your help.
The best way to reduce coupling in a GUI, I think, is to use an Event Bus.
There are several existing implementations out there, including some supporting Swing specifically.
Just google for swing event bus and you'll find.
If you use Guice in your GUI, you may also want to take a look at guts-events.
Yes. MVC is what you have to use. Here is a very good article about MVC and Swing:
http://java.sun.com/products/jfc/tsc/articles/architecture/
Another Pattern that might be interesting for you is the MVP (Model View Presenter)-Pattern. This is great for coupling views more loosely to the model. A good explanation by Todd Snyder can be found here.
As you already said your intent to use MVC , or you may be already using. Once you have seperated out data (I call it as data model layer). Now you need to apply OBSERVER pattern on these data model classes. All the views (your ui components) using this data model are observing this model objects for any change (Via observer pattern).
I hope this is what you are looking for.
MVC !!! Then you can use also a variant of Observer called Publish/Subscribe in order to implement the event flow inside your app.
I don't agree with the people who suggest to use Event bus, because
because of code like EventBus.subscribe(SymbolListChangeEvent.class, this); your whole code will depend on a single event bus instance which makes it very hard to test,
it is hard to find out where a specific event is used.
Instead I suggest to use interfaces to encapsulate external dependencies of a module. If you like, you can use them with the listener pattern, but generally are free to refactor everything if you like.
If you want to communicate with other GUI components in the hierarchy then you should consider something like singleton that mediates calls between branches. See :
http://blue-walrus.com/2013/06/mediator-pattern-in-swing/