Thread: Killing view of a dead model

Sounds like the title of a spy novel, doesn't it?

Actually I wrote a small MVC-type program that has icons (JLabel) on a screen (JPanel). The logic of the icons is managed by a model class. Through the Observable class a view class is registered to it which takes care of the drawing, relocating and coloring of the icons. This view class is a JLabel-derived class. The view is aware of the model, but the model only communicates to the view through the observer/observable system using the setChanged() and notifyObservers() methods. The view then accesses the model's attributes to detect what changed and redraws the icon if necessary.

Everything works well except removing the icon from the screen. When I destroy the model, how do I get the view notified that is should... get destroyed too? How do I get it to tell the JPanel that it is to be removed, and how does the JPanel know which of the icons is to be removed?

Thanks in advance.


Love,

Alice

I'm not that familiar with the classes you are using. If you can post the code, it would help me see the problem and work on it.

Sweet of the both of you to reply so fast.

Originally Posted by Norm

I'm not that familiar with the classes you are using. If you can post the code, it would help me see the problem and work on it.

It's not that easy to post my code since the program does lots of other things I'd rather not divulge. If this post doesn't help make it clearer, I'll come up with something.

Originally Posted by copeg

Use your already implemented Observer - when the model is 'destroyed', fire the listeners to notify them of the event.

I'm not sure how to do that.

You see, when I change something in the model, I add these two statements:

observable.setChanged()
observable.notifyObservers()

This triggers the update method in the Observer implemented view class. The view overrides this method and redraws the icon. The view object accesses the model object and gets information from it how this redrawing should happen. A certain status in the model object is represented by a particular color in the view object, another status corresponds to a different location of the view object on the JPanel, and so on...

But the model's object gets destroyed by losing all references to it. The Java garbage collector is taking care of the destruction. There is never time to fire the setChanged and notifyObservers methods. And even if there was (maybe in some kind of destructor method?), the view would try to access the model object that is no longer there. Wouldn't that cause a null pointer error?

Am I not seeing this right?

Originally Posted by copeg

I'm not following: if all references to the Model are gone, this would mean the view would not longer hold a reference and that reference would have to be removed (at which point you know when the model is 'destroyed'), but you say "the view would try to access the model object that is no longer there" makes me think otherwise.

You are right. I forgot to clear that reference. (I feel so silly). The icon model is referenced from two places.

As a matter of fact, now that I took care of that reference, the model object still won't get destroyed. I put a System.out.println("") debug message in the model's finalize method, but it won't run. Is it possible that being Observable makes it referenced? It would make sense.

break the problem down for us

I have a screen (JPanel) which is also an MVC view-type object. On this I have a mouseListener. To this screen view I linked a screen model, which keeps track of all the icons on the screen. The icon model objects are stored in a linked list. Each icon model is observed by its own icon view object.

When an icon is double-clicked, the JPanel mouse listener tells the screen model object to destroy the corresponding icon model object. In that icon model's finalize method (that I only just added) I call the setChanged and notifyObservers methods, which should trigger the icon view's update method. This now checks whether a model is still attached to it. If not, it should contact the screen view object to get rid of the icon view object. (I don't know how to do that yet, since I have no reference to the screen from the icon view object. But that is not the issue now).

It looks like overkill, but as far as I understood this is the MVC way. (Well kind of since I got rid of the controllers, both on the screen level and the icon level).

I am getting tired of this GUI-nonsense. All I want to do is work on the logic part, but instead I've been stuck drawing pictures for the last few months.

When I destroy the model

Somehow this seems wrong. You don't destroy the model for any of the Java classes.
You work with the view/controller.

Originally Posted by copeg

Don't rely on the finalize method, it may or may not be called.

Mkay.

Is there a way to test an object has been garbage collected? Or just a way to detect what references are linked to an object at runtime? There must be tools to check for memory leakage.

Take a step back and think about why you want 'MVC'.

That's a good idea.

You see, when I started this project, I wrote classes that contained both the logic and representation side. They became huge and unmanageable.

So I started again using MVC. But too many classes made it extremely difficult to keep an overview of what I was doing. So I started yet another version where each object has a representation class and one or several logic classes. I dropped the controllers because they did not bring anything positive to the party.

I believe it's a good idea to separate the representation from the logic. Once the representation is finished, I can concentrate on the logic side without fear of breaking anything on screen. The representation side is completely defined and not really very complicated. The logic part however will probably keep growing for a long time, adding more and more classes to the equation.

become a nightmare in changing what I like to call 'spaghetti code'

"The object-oriented version of 'Spaghetti code' is, of course, 'Lasagna code'. (Too many layers)."
-- Roberto Waltman.

It sounds like you are using very fine grained listener approach...each Icon having listeners and you may wish to start with a more global and basic approach.

Actually no, the only mouse listener (and mouse motion listener) is attached to the view of the screen (the JPanel). This view is linked to a model object, which basically only keeps track of the objects to be represented (linked list of 2nd level model objects).

The icons have their own view, which is derived from a JLabel, but the mouse clicks are managed by the view of the screen. The icon view 'translates' statusses of the icon model, which in the future will be spread over many classes.

Doesn't that make sense?

Originally Posted by Norm

Somehow this seems wrong. You don't destroy the model for any of the Java classes.
You work with the view/controller.

I don't understand. I don't know how to do that.

When I double click on an icon, it should disappear from screen and from memory. So I thought the model object of the icon should get kicked from the linked list and all references to it should be severed. And as a result, unbeknownst to the model, the icon view should detect that, and somehow inform the screen that it is no longer to be shown.

If you have a better suggestion, please let me know.