I had written a java application which takes a input from console and extends Observable. And I had written a applet which implements Observer.
Question: can we use a Observable/Observer concept in a Application/Applet environment.
Take a look at my code for Applet and Application
Applet, which is also a wanna-be-Observer in this case, runs in the isolation hospital called Web browser or appletviewer. And your application ObservableDemo, which is a wanna-be-Observable, runs on your local machine as a stand-alone console program.
These two runs on different JVMs or different JVM instances. No communication route between them. They can't have Observer/Observable relationship, never.
This was the reply I got from one of the forums. I just wanted to confirm the answer before I meet my boss.
The way you have it coded, is, well, not the best. How would the variable ac10 in ObservableDemo ever get a value? Observer/Observable is just a pattern, so saying they can NEVER have that relationship is an exaggeration. You'd need another layer of functionality, like RMI or a custom server, to go between the JVM's. Using an applet places the code inside a secure sandbox, so you'd either have to host the RMI server on the same host as your web server or digitally sign the applet to get around the security limitations, but it can be done.
Instantiating an applet and passing that instance to the application(ObservableDemo) is not good programming I think. Since there is no instance in the addObserver() method I end up in NullPointerException. Thats where there the problem is. Please take a look at the Note part too.
The response you have posted is correct, two applications running on two different jvms cannot have an Observer/Observable relationship - they can however have a variation of the same pattern where you send a synchronous message to the other application as and when required. This could be a custom solution of your own or maybe RMI based as suggested above. But then if the recepient application is an applet, you will have to handle code signing the jar to give it elevated privileges.