 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2007Help with Extending a class
Hi, I am writing a distributed Battleship game using RMI. I need this class to extend both javax.swing.JFrame AND UnicastRemoteObject. Is there anyway around this? public class MainGUI extends javax.swing.JFrame implements BattleShipClientIntf { Thanks. > Hi, > > I am writing a distributed Battleship game using RMI. I need this > class to extend both javax.swing.JFrame AND UnicastRemoteObject. Is > there anyway around this? You might be better off having your class contain and control a JFrame rather than extending it. Also, it should likely use a UnicastRemoteObject rather than extend it. Isn't the Swing interface going to be strictly on the client side? Why would you need to pass a JFrame over the wire? See Joshua Bloch's chapter in /Effective Java/ for "Prefer Composition to Inheritance".  SignatureLew > > Hi, > [quoted text clipped - 12 lines] > -- > Lew Thanks for the advice. I separated the classes. I was making it harder than it had to be. Another question... I need to do two way communication on my implementation. I need my client to call methods at the server (works) and then I need my server to respond and call methods at the client. What I don't understand is how to do the naming lookup at the server side? Thanks very much. > Another question... I need to do two way communication on my > implementation. I need my client to call methods at the server > (works) and then I need my server to respond and call methods at the > client. What I don't understand is how to do the naming lookup at the > server side? Disclaimer: There are bound to be other folks with a different take on your question than mine, possibly better. "YMMV", etc. Whenever possible I recommend not having both sides be initiators of a call. You have to do so much dancing to handle it that it's not usually worth it. It's almost always much better to have a client be the client and a server be the server, never the roles to switch. Only the client should initiate service calls; the server should only respond. What is the client doing while waiting for the server to call back? If you want a simulation of asynchronous RMI calls, spawn a client thread to call for the result and wait for the reply. Have it asynchronously signal your primary thread when the result is ready. Why do you feel the need for server calls to the client? Perhaps by stepping to a wider outlook we can perceive a simpler solution to a desirable result based on different premises. SignatureLew > > Another question... I need to do two way communication on my > > implementation. I need my client to call methods at the server [quoted text clipped - 23 lines] > -- > Lew In the Battleship game, the client shoots then the server returns fire. I see your point. It would be a lot better if the server generated a shot and then the client got it with a remote method call. Thanks for helping me clear this up. Lew wrote: >> What is the client doing while waiting for the server to call back? >> [quoted text clipped - 5 lines] >> to a wider outlook we can perceive a simpler solution to a desirable result >> based on different premises. > In the Battleship game, the client shoots then the server returns > fire. I see your point. It would be a lot better if the server > generated a shot and then the client got it with a remote method call. > > Thanks for helping me clear this up. But back to my first question: >> What is the client doing while waiting for the server to call back? Doesn't the client have to wait for the server to fire before it can do anything? If so, just have the server's shot be part of the response from the RMI call that registers the client's shot. SignatureLew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.