Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
behrk2
Posts: 367
Registered: ‎11-25-2009
My Device: Not Specified
Accepted Solution

Question about net.rim.device.api.ui.Screen object

Hi everyone,

 

I have a class that accepts in its constructor an object of type 'Screen' (net.rim.device.api.ui.Screen). When I instantiate this class, I include a class that extends MainScreen as the parameter. For example:

 

 

public ClassA extends MainScreen {
     public void tester(){
          ClassB classB = new ClassB(this);
     }
     
public void sampleMethod(){
...
}
} public ClassB { Screen screen; public ClassB(Screen screen) { this.screen = screen; }
public doStuff(){
screen.sampleMethod();
}
}

 

 

My problem is that ClassB calls methods which are in ClassA, however unless I change type "Screen" to "Class A", I will receive the error: "the method sampleMethod() is undefined for the type Screen".

 

How can I get ClassB to accept different classes that extend MainScreen?

 

Thanks!

Please use plain text.
Developer
ydaraishy
Posts: 562
Registered: ‎09-30-2009
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

If the subclass defines a method X that that the superclass does not, how is a reference to the superclass supposed to resolve the method X? Java (sadly) is not Objective-C.

 

You need to cast down to access methods in the subclass.

Please use plain text.
Developer
peter_strange
Posts: 19,601
Registered: ‎07-14-2008
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

I might be wrong, but I think ydaraishy has answered a slightly different question to the one that the poster has asked. 

 

In ClassB, you have told the compile that the object screen, is a Screen Object.  So the compiler will check to make sure that all references to screen match those that are possible to an object of type Screen. 

 

Now at runtime, when you construct your classB, you can pass in a MainScreen, or even your class that extends MainScreen, because these classes all extend Screen.  However at compile time, the compiler did know know that was what your were going to do.

 

If you are always going to supply a ClassA object to the constructor of ClassB, then change screen to a ClassA object, rather than the more restricted Screen.

 

Alternatively you can do something like the following in ClassB

 

if ( screen instanceof ClassA) {

ClassA classAScreen = (ClassA) screen;

classAScreen.sampleMethod();

}

 

Does this make sense and does it answer the question, or have I in fact misunderstood....

Please use plain text.
Developer
behrk2
Posts: 367
Registered: ‎11-25-2009
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

The problem lies in the fact that I will not always be supplying a ClassA object to the ClassB constructor. I am going to have several different classes, all extending MainScreen, each of which I want to be able to use ClassB.

 

Right now, for every class extending MainScreen, I have to make an additional "ClassB" to go with each individual class...

Please use plain text.
Developer
peter_strange
Posts: 19,601
Registered: ‎07-14-2008
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

Rather than discussing hypothetically, can you give us an example of how different these will be?

 

There is an argument that says that if you are having to create a class that is specific to another class, then aren't they in fact, different parts of the same class?

Please use plain text.
Developer
behrk2
Posts: 367
Registered: ‎11-25-2009
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

I am developing a Netflix application for BlackBerry mobile devices. So, I am going to have different types of UI Screens:

 

- the authentication screen

- the "search movie library" screen

- the "view/update queue" screen

- etc.

 

While each screen implements an interface of SampleMethod(), the screens will each perform different functionality within that SampleMethod(), which is called by ClassB. Screens are also differening in the UI elements, as well...

Please use plain text.
Developer
peter_strange
Posts: 19,601
Registered: ‎07-14-2008
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

"each screen implements an interface of SampleMethod(),"

 

Then could ClassB look like this?

 

public ClassB {

     SampleMethodInterface screen;

     public ClassB(SampleMethodInterface screen) {
          this.screen = screen;
     }

     public doStuff(){
          screen.sampleMethod();
     }
}

Please use plain text.
Developer
behrk2
Posts: 367
Registered: ‎11-25-2009
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

[ Edited ]

That is what I had originally thought to do, but if I supply ClassB with the interface, then when SampleMethod() is called, how does screen.sampleMethod() know which screen (lets say, ClassA) to go back to? Does that make sense?

 

I am unsure how passing the interace (which is implemented by ClassA) into the constructor of ClassB will eventually "link" back to ClassA...

 

Thanks for your ongoing help with this.

Please use plain text.
Developer
peter_strange
Posts: 19,601
Registered: ‎07-14-2008
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

You are not passing an Interface to ClassB, you are supplying an Object - the Object has to implement the interface in order to be accepted. You retain a reference to that Object in ClassB, and it is the SampleMethod() of that Object that is invoked.  It should all work fine.

Please use plain text.
Developer
behrk2
Posts: 367
Registered: ‎11-25-2009
My Device: Not Specified

Re: Question about net.rim.device.api.ui.Screen object

That did the trick, I cannot thank you enough. You have been a big help to me.

 

I understand what you mean now about how the object is being passed, not the interface. It was all very simple - it's amazing how you can be so set in one way of thinking.

 

A good lesson learned, thanks.

Please use plain text.