how to find a common ground for a few phone manufactures

[TacB0sS]

hey, I was wondering, I never really had to deal with specific manufacture API, but I'm sure each has its own way to deal with specific things, like the accelerometer for example, I would like to implement one object that would check for the device manufacture and derive from that what to do, which code to use or anything else, is this even possible or I must decide on one and design my code for it?

how do I even import a package that I'm not even sure that is there??
I could use the fully qualified name with many if's if that would do...

please share your thoughts...

[grahamhughes]

Using an API that might not be there is the same process whether the API is manufacturer specific, or simply "optional" (like the location API, for example). Writing code to handle optional APIs relies on knowing how classes are loaded and linked at run-time in the Java virtual machine. If you get it wrong, you'll get Errors. Worse, you can also end up with code that works on some phones, but not on others, because of differences in the way loading and linking is handled between implementations.

I suggest reading How to use an optional API in Java ME from the wiki.

The alternative is simply to produce separate builds of the application for different devices.

Graham.

[TacB0sS]

Thank you again Graham...

[TacB0sS]

I have another question regarding this subject,
I think I look at this the wrong way, I read the link you gave me and I was wondering,

the package is there, its just not implemented with all the devices that's why I need this over headache?

I don't think I understand why this problem is caused... could you enlighten me? (ref)

[grahamhughes]

the package is there, its just not implemented with all the devices that's why I need this over headache?

Can you explain what you mean by this?

[Tiger79]

well, hte problem lies at the manufacturers... Even thought the API's exist that doesn't mean every manufacturer wants to supply evenry API with every device... I guess thats cutting costs on their side...
You might compare it to the car industry, even though ESP has been around for years and it's a very handy and safe technology it doesn't mean every car is equipped with it... Some do and some don't, mostly depending on price range...
The expensive and sports cars have it..
It's the same with many mobile deives... Like the N-series who most of the time are the devices with the most API's...

[TacB0sS]

Can you explain what you mean by this?

Thanks Tiger,

OK, so when I use the code that Graham posted, I actually check if the manufacturer Implemented/Used/Have the Hardware/API/Package/Class on a specific device? can I count on the java to give me the same data on different devices or should I check/calculate a factor to normalize the output. (This entire thread, I think about the Accelerometer as an example).

I lake the terminology thats why I have few words in bold.

I hope its clearer...

[grahamhughes]

OK.

If you look at your J2SE installation on your desktop, you'll find a lib/ folder, and in that you'll find "rt.jar". This is the runtime library, and contains the API classes (and supporting classes). This is where the J2SE VM finds standard classes when your app needs them.

Strictly speaking, CLDC does not necessarily work in the same way. But conceptually, it does, in that there is some kind of file that contains the runtime library classes (for whatever combination of APIs exist on that device).

I'm avoiding using terms like "API" and "implemented" as much as possible, because they're complicated. For example, all MIDP-2 devices have the interface SocketConnection, but not all MIDP-2 devices have a class that implements this interface (because not all devices support sockets). So you can have a bizarre situation where the AI exists, but isn't implemented.

This is getting into the field of "advanced Java", since you start having to understand particular nuances of how the VM works. It might take a little time to get your head around it. I'll try as best I can to explain it more, but this would be easier in a classroom with a whiteboard!

The code in the wiki article use Class.forName() to detect whether a specific class actually exists. That is, whether or not the appropriate .class file is in the runtime JAR. (Which is a more straightforward concept.) A key aspect to using this technique is identifying a class that has to be there if you're to do what you want.

The other key part of the technique is to make sure that no class gets loaded (by the class loader) that might make any reference to a class that might not exist. "ClassA" references "ClassB" if it subclasses it, or if it tries to create an instance of it, or if it accesses any static methods or fields of ClassB. Referencing ClassB will cause ClassB to be loaded, and if ClassB can't be found, the class loader will throw an error.

Depending on device (and how it's class loader works), loading ClassA might cause ClassB to be loaded immediately, simply because ClassA contains a reference to it. It might not wait until ClassA's code is executed.

(Note that having a class's name in a String, as an argument to Class.forName(), does not count as "having a reference to that class". The class's name has to be in code, not in quoted text.)

Therefore, to prevent errors, we must make sure that ClassA is not loaded, unless we know that ClassB exists. That means we have to load ClassA using Class.forName(), so that we don't have a reference to it in the code we're running. Then we need to use Class.newInstance() (on the Class object returned from forName()) to create an object.

This leaves the problem of how to use that object. newInstance returns a reference to an Object, so we can only invoke methods defined by Object. We need to cast the Object reference to something more useful.

Unfortunately, we can't cast it to a reference of ClassA - since that would count has "having a reference to ClassA". To make this work, all the useful methods in ClassA need to be defined in a superclass of ClassA, or an interface that ClassA implements. We can safely reference the superclass or interface, since that won't contain a reference to ClassB.

Next... can you reliably use the API in the same way on all devices.

If you're using the same API on two devices, the rules are no different whether you dynamically located the API, or coded it "normally". The best you can hope for, is that the API implementation on the two devices will behave according to the specification.

More tricky is trying to use two different APIs for the same job. The most common situation for using manufacturer APIs is for sound - either on MIDP-1 devices (that frequently lack MMAPI), or because MMAPI on a MIDP-2 device doesn't work properly, and you find the manufacturer API more stable. Then you have problems that the APIs are just fundamentally different. For example, do they all allow you to create a Player/Sound/AudioClip/whatever object from a byte[] or InputStream, or must you provide the file name? Do they all support looping? Do they all support pause/resume? Do they all have some equivalent to PlayerListener? You need to identify a common subset of functionality, and create your own API for that. Then you can create different versions of a class implementing that API, each wrapping access to a different underlying device API. Again, this is the same technique whether you're going to have separate JARs (each with a different version of this class), or a single JAR (containing all the versions of the class, and selecting one at runtime).

Does that help any?

Graham.

[TacB0sS]

WOW, how long did it take you to type all this??

Thank you, although I was not a stranger to classes loading process, I think your post filled my gaps regarding external API's, and your detailed explanation would serve others well, as it served me well.

As you probably expect, after understanding, questions pops up, so...

then each manufacturer would implement in its own way interfaces or abstract classes that are in the API that do whatever it is that API does? (am I on the right track here)

The most common situation for using manufacturer APIs is for sound - either on MIDP-1 devices (that frequently lack MMAPI), or because MMAPI on a MIDP-2 device doesn't work properly, and you find the manufacturer API more stable

so you are actually saying that using the Player and the PlayerManager is not the best way to implement sound?? is there another way??

and if I would like to implement (again) accelerometer (which I plan on doing soon) I would require to have an abstract class to derive the type of manufacturer and then to use something like the code in the link you posted, and to create an instance of an inheriting class of the abstract one that fit the manufacturer implementation for example different values for up, down, left, right?

actually just like key codes... differ from one manufacturer to another, from one phone to another, and needed of external database to map all the keys and such?

did I get it?

[grahamhughes]

WOW, how long did it take you to type all this??

Oh, I'm a fast typer!

then each manufacturer would implement in its own way interfaces or abstract classes that are in the API that do whatever it is that API does? (am I on the right track here)

Exactly. Some parts of the APIs are only interfaces or abstract classes, as you say. So often, the actual object you're dealing with are of some manufacturer specific class. For example, getResourceAsStream() returns an InputStream - but it doesn't, InputStream is abstract, so there is some class not specified in the API.

so you are actually saying that using the Player and the PlayerManager is not the best way to implement sound?? is there another way??

No. It is the best way. And on many devices, it's the only way. But really old devices (MIDP-1 Series 40s, for example) don't have MMAPI, and some devices (some Samsungs, for example) that just behave a little bit more reliably if you use the manufacturer API.

and if I would like to implement (again) accelerometer (which I plan on doing soon) I would require to have an abstract class to derive the type of manufacturer and then to use something like the code in the link you posted, and to create an instance of an inheriting class of the abstract one that fit the manufacturer implementation for example different values for up, down, left, right?

At this point, I can't tell you much, as I've never used the Sensor API, so I don't know how (or if) it varies between devices. Your main problem is likely to be handling the fact of it existing or not.

Graham.

[TacB0sS]

Oh, I'm a fast typer!

yes well you need to think while your at it no?

Exactly. Some parts of the APIs are only interfaces or abstract classes, as you say. So often, the actual object you're dealing with are of some manufacturer specific class. For example, getResourceAsStream() returns an InputStream - but it doesn't, InputStream is abstract, so there is some class not specified in the API.

this process is called low capsuling... or something, that is the only way to assure the end user (developer) would be able to call specific known methods, I use this all the time... makes sense it would be done this way.

Thank you so much Graham,
you just made it easier for me to develop.

[TacB0sS]

Hey Graham, one more thing, I was wondering, you said once that every device has a different class loading mechanizem so, in the example you gave me if the location API does not exist, but the line

import javax.microedition.location.*; 

exists.

Could it be that devices load classes based on the import list?
And wont it be wiser to use the fully qualified name within the try catch block?

is there any difference?

this is what I found on the sun site:

Referring to a Package Member by Its Qualified Name

So far, most of the examples in this tutorial have referred to types by their simple names, such as Rectangle and StackOfInts. You can use a package member's simple name if the code you are writing is in the same package as that member or if that member has been imported.
However, if you are trying to use a member from a different package and that package has not been imported, you must use the member's fully qualified name, which includes the package name. Here is the fully qualified name for the Rectangle class declared in the graphics package in the previous example.

graphics.Rectangle
You could use this qualified name to create an instance of graphics.Rectangle:
graphics.Rectangle myRect = new graphics.Rectangle();
Qualified names are all right for infrequent use. When a name is used repetitively, however, typing the name repeatedly becomes tedious and the code becomes difficult to read. As an alternative, you can import the member or its package and then use its simple name.

not really an answer... is it.

do you have any idea?

[grahamhughes]

In the .class files, all class names are fully qualified. "import" statements don't generate any code, they're just used by the compiler to create a kind of "search path" for identifying unqualified class names.

However, you are essentially correct. The .class file contains a list of class name that its code references, they all exist in the class's constant pool. When a class is loaded, the JVM might well read this list and attempt to load all the classes needed. This is why the class that references the location API (in the example) must not be loaded unless the location API is present. That's why the LocationImplementation class can only be referenced in a call to Class.forName(), and not directly. (Otherwise it would get loaded, and the JVM would look for the location API, not find it, and throw an Error.)

Graham.

[TacB0sS]

Oh I see it now the LocationImplementation hold the import and since there is no "physical" reference to it every thing is fine... WOW great, I love this snikky back doors its brilliant... truly brilliant.

Thanks Graham.

[TacB0sS]

Wait just a second, what about Obfuscating and this implementation... shouldn't this be a problem since there is no reference to the class???