read data into a string using HttpConnection

[artemg]

I am using HttpConnection, to connect to a php script on my server and read the information (short line of text) into the TextBox in the MIDlet.

I finished up the app, tested it on default emulators supplied with WTK and with Nokia 7210 SDK. Worked really well.

The problem surfaced when I tested the application on a real phone (Nokia 7210). When I read the string - StringBuffer.toString() - the output I receive to the TextBox on the real phone is always " ¡õ¡õj ", no matter what string is provided by server, whereas all emulators display the actual string.

Can somebody explain to me what could be causing this and what are possible solutions. Thank you

[shmoove]

What encoding is the server sending the string in?
Those squares are what appears when the phone gets a character it can't decode. You have to make sure that whatever encoding you're using to send the string from the server, you use the same one to read the string on the MIDlet (and of course that the encoding is supported by the phone).
Is the emulator running on the same machine as the server? That could explain why it works on the emulators.

shmoove

[artemg]

I have been doing some experimenting with this and this is what happens.

If the URL contains a text file, it shows fine on the SDKs and on the real phone. If the link is a html, the phone will show the source code for it.

The object is such: my server script (btw. it's a 3rd party server) produces one line of text. Since the page extension is .php I guess the phone is trying to read something else. It IS nonetheless plain text.

So my question now would be How do I tell the phone to interpret the string as plain text? With HttpConnection.setRequestProperty(which one). Or should I have the server script produce a header?

Thanks again

[artemg]

Just to make things a little clearer...

I have used a tutorial on http://developers.sun.com/techtopics...icles/network/

Without any modifications, this application produces the same exact result on my phone as my app - I get the " ¡õ¡õj" displayed in the TextBox. The return is exactly the same (two unrecognized characters + "j" - no matter what the input string maybe.

I wonder if this is just a thing with Nokia pones and if so, what is the workaround for this.

[shmoove]

If the URL contains a text file, it shows fine on the SDKs and on the real phone. If the link is a html, the phone will show the source code for it.

The object is such: my server script (btw. it's a 3rd party server) produces one line of text. Since the page extension is .php I guess the phone is trying to read something else. It IS nonetheless plain text.

Your phone only knows it is receiving a stream of bytes. If you use an HttpConnection the phone will parse the headers for you, but the body as far as it's concerned is just a plain stream of bytes. It has no concept of MIME types or extensions or anything else. Anything like that you would have to implement yourself. What matters is how your code interprets those bytes.

In the example you give this is the part that reads the stream and saves it as text:

while ((ch = is.read()) != -1) {
b.append((char) ch);
System.out.println((char)ch);
}

As you can see, it is reading in a byte, converting it to a char and appending it to a StringBuffer (this will only work for standard ASCII chars). Then it uses the StringBuffer to get a String from it.
Try printing out the actual bytes instead of adding them as chars of a string. Maybe it will help you make some sense of it.
As I said before, I think your server is encoding the text in a non-ASCII manner and that's why you get garbage. Another possibility is that WAP gateway you go through is doing some nasty stuff with the response. That could also explain why it works well on the emulator (the emulator is not going through the WAP gateway). A good way to test if the WAP gateway is the culprit would be to try and use the phone's browser to access that page and see if the result is any different.
Good luck,

shmoove

[artemg]

Thank you very much for thorough answer.

I have finally resolved the issue on the server script side by adding a header and using alternative text output command. Thanks again.