Archived:Infrequent paint() call when Bluetooth is used in S60 devices (Known Issue)

Comments

(no comments yet)

Log in or Join to leave comments.

Archived: This article is archived because it is not considered relevant for third-party developers creating commercial solutions today. If you think this article is still relevant, let us know by adding the template {{ReviewForRemovalFromArchive|user=~~~~|write your reason here}}.

The article is believed to be still valid for the original topic scope.

Article Metadata

---

Compatibility

Platform(s): S60 3rd Edition

---

Article

Created: User:Technical writer 1 (30 Nov 2006)

Last edited: hamishwillee (28 Jun 2012)

Overview

The Java Bluetooth API behaves differently in S60 and Series 40.

I have a Java ME application that paints an animation while another thread reads from a Bluetooth connection (about 30 bytes every 20 ms). This application works perfectly on Series 40 phones. On S60 phones, however, the animation becomes nearly frozen while the connection is being read. It appears that Java threads are running frequently enough (reading Bluetooth / calling repaint) but that the system (GUI Event thread) is infrequently calling paint().

Description

In S60 Java is not calling paint while Bluetooth data is received whereas in Series 40 Java is calling paint while Bluetooth data is received.

However, the Nokia N93 is the first S60 device where the MIDlet behaves correctly, that is, simultaneous painting is being done when Bluetooth data is received.

How to reproduce

If you have a client-server application, you can test whether the MIDlet behaves correctly.

• Install the application on two Nokia S60 devices
• Make sure Bluetooth is turned on.
• Start the application on server.
• Start the application on client.
• During the initialization of the Bluetooth connection, the application/screen freezes. When the connection has been established, the paint() method is called but not frequently enough.

Solution

No solution exists.