Skip to main content

Suggestion: Change Device Database to Wiki

15 replies [Last post]
bardubitzki
Offline
Joined: 2003-11-02
Points: 0

This would enable the developer community to provide additional device and operator specific information.

Lets give me an example: The Motorola RAZR V3c is the CDMA version of the RAZR V3 which ships in North America. From other forums I learnt that this device doesn't support JME in the USA, but in Canada. However, it took me six weeks of intensive research, consulting and network monitoring to get confirmation that HttpConnection doesn't work, at least not on Bell Mobility here in Canada. So, you have to write your own low level implementation to talk to a HTTP server.

I believe, this kind of additional information could be very helpful for developers.

Cheers,
Stephan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bardubitzki
Offline
Joined: 2003-11-02
Points: 0

Thanks Sid.

But my original problem with the RAZR and Bell Mobility was quite different: The attempt to establish a connection by using HttpConnection was teared down immediately on 1X. (A local MVNO helped by monitoring 1X network). So, I never reach the server.

After implementing my own low-level connection based on SocketConnection I'm able to talk to the HTTP server.

It is also of interest that this implementation works only with Motorola phones like the RAZR or E815, but doesn't works with Samsung, LG and the likes.

Stephan

cesidio
Offline
Joined: 2003-07-03
Points: 0

It would help If I posted all the code.

}
catch( ConnectionNotFoundException cnfe ) {
//handle exception
}
catch( IOException ioe ) {
//handle exception
} finally {
try {
if( os != null )
os.close();
} catch( IOException ioe1 ) {
}
try {
if( in != null )
in.close();
} catch( IOException ioe2 ) {
}
try {
if( hc != null )
hc.close();
} catch( IOException ioe3 ) {
}
}

I hope this helps.
Sid.

Dhawal Ogale

It's well known (and also available on Motorola developer support) that
trying to read past end of stream when the content-length is known, causes
Motorola devices to hang. The same loop works just fine when content-length
has not been passed by the server in its HTTP headers.

I also remember that there were some issues with one of the three syntaxes
of InputStream.read() method- int read(), int read(byte[] buf), and int
read(byte[] buf, int off, int len). I bet that using read() is safe, but not
very efficient. We have used buffered reads using the other two syntaxes and
has not caused any problems on the RAZRs lately.

My 2 cents.

-----Original Message-----
From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM]
On Behalf Of meinterest@MOBILEANDEMBEDDED.ORG
Sent: Tuesday, March 13, 2007 12:24 PM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: Suggestion: Change Device Database to Wiki (+ HTTP issues)

It would help If I posted all the code.

}
catch( ConnectionNotFoundException cnfe ) {
//handle exception
}
catch( IOException ioe ) {
//handle exception
} finally {
try {
if( os != null )
os.close();
} catch( IOException ioe1 ) {
}
try {
if( in != null )
in.close();
} catch( IOException ioe2 ) {
}
try {
if( hc != null )
hc.close();
} catch( IOException ioe3 ) {
}
}

I hope this helps.
Sid.
[Message sent by forum member 'cesidio' (cesidio)]

http://forums.java.net/jive/thread.jspa?messageID=207717

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Joe Bowbeer

Adding a note to this, on some devices read loops should terminate on
<= 0 rather than -1, because -1 will never be returned. Terminating
on <= 0 seems to work everywhere, even though some implementation
could potentially read more stuff after 0 was returned (depending on
how one reads the specs).

On 3/13/07, Dhawal Ogale wrote:
> It's well known (and also available on Motorola developer support) that
> trying to read past end of stream when the content-length is known, causes
> Motorola devices to hang. The same loop works just fine when content-length
> has not been passed by the server in its HTTP headers.
>
> I also remember that there were some issues with one of the three syntaxes
> of InputStream.read() method- int read(), int read(byte[] buf), and int
> read(byte[] buf, int off, int len). I bet that using read() is safe, but not
> very efficient. We have used buffered reads using the other two syntaxes and
> has not caused any problems on the RAZRs lately.
>
> My 2 cents.
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Hartti Suomela

7610 is a CLDC 1.0 phone
http://www.forum.nokia.com/devices/7610

Have you built your app for CLDC 1.1?

Hartti

________________________________

From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of ext Mark Ripley
Sent: Tuesday, March 20, 2007 7:42 AM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Nokia 7610

Hi,

Just had a report in from a customer who can't get a game to run on this
phone, when I've heard no problems before on this phone or s60v2's in
general, apart from the ones that's got reduced heap. Is the 7610 one of
those?

Thanks =)

Mark Ripley
cheeky.gr

New improved Blobbit Push coming soon! - www.Blobbit.com
Link to Blobbit and earn 60% commission! - www.cheeky.gr/?p=84

========================================================================
=== To unsubscribe, send email to listserv@java.sun.com and include in
the body of the message "signoff KVM-INTEREST". For general help, send
email to listserv@java.sun.com and include in the body of the message
"help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Mark Ripley

Ah good point, there may be 1.1 specified in the manifest or
something....

Mark Ripley
cheeky.gr

New improved Blobbit Push coming soon! - www.Blobbit.com
Link to Blobbit and earn 60% commission! - www.cheeky.gr/?p=84

On Mar 20, 2007, at 6:52 PM, Hartti Suomela wrote:

> 7610 is a CLDC 1.0 phone
> http://www.forum.nokia.com/devices/7610
>
> Have you built your app for CLDC 1.1?
>
> Hartti
>
> From: A mailing list for KVM discussion [mailto:KVM-
> INTEREST@JAVA.SUN.COM] On Behalf Of ext Mark Ripley
> Sent: Tuesday, March 20, 2007 7:42 AM
> To: KVM-INTEREST@JAVA.SUN.COM
> Subject: Nokia 7610
>
> Hi,
>
> Just had a report in from a customer who can't get a game to run on
> this phone, when I've heard no problems before on this phone or
> s60v2's in general, apart from the ones that's got reduced heap. Is
> the 7610 one of those?
>
> Thanks =)
>
> Mark Ripley
> cheeky.gr
>
> New improved Blobbit Push coming soon! - www.Blobbit.com
> Link to Blobbit and earn 60% commission! - www.cheeky.gr/?p=84
>
> ======================================================================
> ===== To unsubscribe, send email to listserv@java.sun.com and
> include in the body of the message "signoff KVM-INTEREST". For
> general help, send email to listserv@java.sun.com and include in
> the body of the message "help".
> ======================================================================
> ===== To unsubscribe, send email to listserv@java.sun.com and
> include in the body of the message "signoff KVM-INTEREST". For
> general help, send email to listserv@java.sun.com and include in
> the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Mark Ripley

Hi,

Just had a report in from a customer who can't get a game to run on
this phone, when I've heard no problems before on this phone or
s60v2's in general, apart from the ones that's got reduced heap. Is
the 7610 one of those?

Thanks =)

Mark Ripley
cheeky.gr

New improved Blobbit Push coming soon! - www.Blobbit.com
Link to Blobbit and earn 60% commission! - www.cheeky.gr/?p=84

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

The topic of a device database is a very important one. The Sun Developer Network maintains a database of device *features* which is quite comprehensive and up-to-date. I believe it is the most complete such database at this time:

http://developers.sun.com/techtopics/mobility/device/device

Bugs, device quirks, and operator specifics are *not* part of that database. There are several community-wide efforts available here, such as the Wiki Stephan mentions:

http://www.j2meforums.com/wiki/index.php/Handset_Bugs_%26_Workarounds

What we here in the M&E Community have been discussing (and I'd like to get your feedback on this) is that a wiki is great but maybe a little too unstructured, resulting in duplicate or inconsistently entered information. I'm more in favor of an online database that all members of the community can update as new information becomes available.

I believe the upcoming new version of IssueTracker, called Project Tracker, would be suitable. Project Tracker is more flexible than IssueTracker because we could define our own database schema plus it has a web services interface so it can be accessed and integrated with other tools. Project Tracker will be available in about two months so we should start talking about concrete implementation steps soon.

What do you think?

-- Terrence

bardubitzki
Offline
Joined: 2003-11-02
Points: 0

Indeed, Project Tracker sounds promising and you got a point regarding wiki.

Stephan

captainfreedom
Offline
Joined: 2007-01-10
Points: 0

I entered a lot of bugs in that database. Unforunately the nature of Wiki is unrelable. People don't go to the trouble of making sure the information is 100% accuate and often omit crucial details. Having said that it's certainly better than nothing

Stefan Haustein

Hi Stephan,

there is already a J2ME-related Wiki with a device bug section available at

http://www.j2meforums.com/wiki/index.php/Handset_Bugs_%26_Workarounds

BTW: While we're at HTTP: Did you know that S40 phones run all HTTP
request through a single centralized queue?

It's not just about forcing socket reuse (keep-alive), the same happens
if you try different servers (which was my first stab at a workaround).
Of course, your workaround (write your own-low level implementation)
does not work either: A socket connection to port 80 is denied by the
JVM (for "security reasons"), and a socket connection to any other port
is denied for the default APN by one of the largest operators in Germany
(the one with the nice, non-intrusive branding habits).

Luckily, especially for S40 phones, it is quite easy to add an
additional access point with the correct APN -- once you have found the
simple (only about 20 steps) instructions in the Opera Mini forum. To
memorize the steps, I recommend to draw a UML diagram of the internal
data structures -- everything suddenly becomes quite logical (sort of).

Unfortunately, it turned out to be a bit too optimistic to assume that
the typical user holds a degree in computer science and/or is willing to
go through those simple steps just to install a MIDP application.
Moreover, phones like the LG chocolate do not even pretend to support
more than a single HTTP connection, so we finally gave up on AJAX/Comet
style HTTP connection patterns and went back to polling (in situations
where plain socket connections are not available).

Best regards,
Stefan Haustein

meinterest@mobileandembedded.org wrote:
> This would enable the developer community to provide additional device and operator specific information.
>
> Lets give me an example: The Motorola RAZR V3c is the CDMA version of the RAZR V3 which ships in North America. From other forums I learnt that this device doesn't support JME in the USA, but in Canada. However, it took me six weeks of intensive research, consulting and network monitoring to get confirmation that HttpConnection doesn't work, at least not on Bell Mobility here in Canada. So, you have to write your own low level implementation to talk to a HTTP server.
>
> I believe, this kind of additional information could be very helpful for developers.
>
> Cheers,
> Stephan
> [Message sent by forum member 'bardubitzki' (bardubitzki)]
>
> http://forums.java.net/jive/thread.jspa?messageID=202518
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

bardubitzki
Offline
Joined: 2003-11-02
Points: 0

Hi Stefan,

thanks for the link. Didn't know that.

Otherwise, I don't quite get what you are trying to tell me about S40. I can assure you that my workaround works well, not only with the RAZR V3c, but also with the Motorola A815.

Cheers,
Stephan

cesidio
Offline
Joined: 2003-07-03
Points: 0

Hello Stephan,
Just to let you know that the issue with HttpConnection, at least for me, seems to occur also on the GSM version of the RAZR in Canada.

bardubitzki
Offline
Joined: 2003-11-02
Points: 0

Hello cesidio,

thanks for that interesting feedback. Did you experienced the problem on both Rogers and Fido?

Stephan

cesidio
Offline
Joined: 2003-07-03
Points: 0

Stephan,

After some gruelling research and testing, The issues with HTTP on the RAZR as well as the other devices we have had problems with, for both GSM(Rogers/Fido) and CDMA(Bell/Telus) seem to disappear once we changed our networking code to the following:

NOTE: The code in bold is the key.

HttpConnection hc = null;
InputStream in = null;
OutputStream os = null;
StringBuffer sb = new StringBuffer( "" );
try {
hc = (HttpConnection)Connector.open( url );
hc.setRequestMethod( HttpConnection.POST );

// necessary because certain devices(RAZR) will hang since -1 will never be
// reached
// two read loops for known and unknown lengths of inputstreams
[b] int len = (int) hc.getLength();
in = hc.openInputStream();
if( len == -1 ) {
// unknown length?
// read until .read() returns -1
int ch;
while( ( ch = in.read() ) != -1 ) {
sb.append( (char) ch );
}
}
else {
// known length
for( int i = 0; i < len; i++ ) {
sb.append( (char) in.read() );
}
}[/b]
}
catch( ConnectionNotFoundException cnfe ) {
//handle exception
}
catch( IOException ioe ) {
//handle exception
} finally {
try {
if( os != null )
os.close();
} catch( IOException ioe1 ) {
}
try {
if( in != null )
in.close();
} catch( IOException ioe2 ) {
}
try {
if( hc != null )
hc.close();
} catch( IOException ioe3 ) {
}
}

I hope this helps.
Sid.

}
catch( ConnectionNotFoundException cnfe ) {
//handle exception
}
catch( IOException ioe ) {
//handle exception
} finally {
try {
if( os != null )
os.close();
} catch( IOException ioe1 ) {
}
try {
if( in != null )
in.close();
} catch( IOException ioe2 ) {
}
try {
if( hc != null )
hc.close();
} catch( IOException ioe3 ) {
}
}

I hope this helps.
Sid.

Message was edited by: cesidio