Is this a "reflection" when I use getClass.getMethod (...)?

Question

I have written several bluetooth applications now, but until recently, I never saw this particular approach . In the example, they use device.getClass().getMethod("createRfcommSocket", new Class[] { int.class }); which seems long to me just by saying BluetoothSocket bs = createRfcommSocket(...

What is the difference between their approach

 Method m = device.getClass().getMethod("createRfcommSocket", new Class[] { int.class }); sock = (BluetoothSocket) m.invoke(device, Integer.valueOf(1)); 

and mine

 sock = createRfcommSocket(..... 

Is there any reason to use this or that?

thanks

Answer 1

Yes, using getClass etc. is a reflection.

The difference is that you get help from the IDE and the compiler in case you mistakenly use the method name or make a similar error, while the authors of this code by themselves.

Perhaps they are in a situation where the method to call is simply not available at compile time, which may occur in the context of software that allows new plugins to be loaded at run time. But in this case, you did not expect to see the method name and other details hardcoded in the code.

The literal text of your example just looks like bad programming to me.

Answer 2

Without knowing the exact details, I can offer one of the reasons that their approach has a kind of duck print. Regardless of the compilation time class of an object, if it has a method with the correct signature, it can be called.

Now, in general, I think that duck typing is not a big idiom in Java for this. However, there may be other justifications for this approach. In particular, this means that this code will not depend on compilation time in the device class. This can be, for example, one of the paths from circular dependencies, and an additional one makes the compilation step weaker.

In a broader sense, although if your approach works, I see nothing wrong with that. Using reflection is usually a workaround essentially for something that you cannot do in a more idiomatic way.

Answer 3

Beware that reflection makes it extremely easy to use platform implementation details that are not part of the SDK, as it bypasses compile-time checking. There should never be a reason to use this reflection to access the platform’s API, except in the case of backward compatibility, where you want your application to run on older versions of the platform that did not have this API. And at any time when you do this, you must be very careful to ensure that what you are referring to is actually part of the SDK.

Answer 4

The answers here are correct, but the specific reason for using reflection was as a workaround for the problems surrounding createRfcommSocketToServiceRecord .

My reasons for this were with other people saying that they fix their connection problems.

See here and here for more details. I think this error is fixed because createRfcommSocketToServiceRecord (without any workarounds) works fine on my Android 2.2 Nexus One OS.

Answer 5

if you check if this method exists in this object at runtime - without any exceptions (say, the parent runtime class is differently based on these variables - for example, external drivers), then you should add a few more lines .. Direct access to such methods or obtaining by name leads to the fact that exceptions are excluded in the absence.

IF NOT - then

You should not write like that. If you already have access to the object, then the ... period method is called.

@mxrider, glad you did it right. This is perhaps a good example of the misuse of the reflection API. But you might be wondering if the original authors wanted a script that I tried to explain above.

Answer 6

Does the reflection method only work when I use the multipoint Bluetooth connection for me? People who have difficulty making multi-drop connections should try the reflection method.