There are several places on this forum where people have posted about their SonyEricsson not displaying the coloured text (StringColourItem) and bitmap fonts (BitmapFontCanvas). I am one of them (with a K800i).
Excuse the long post explaining what is behind this problem.
Over the last 3 days, I have spent some time looking into this problem and can now suggest a workaround, while not perfect is lots better. It is quite simple too.
So, What seems to be causing this problem?
Well.. ..With Forms (and I am not all that experienced in using them since I went the way of a custom UI on a canvas with my apps), the SE has a bit of a quirk to it. One that is not present on the Sony SDK emulators.
Normally, what you would expect when running some process is that the device would be in a state of 'lock', or completely unresponsive to user interaction, bar those that will interrupt the KVM (such as the method for forcing program closure). This is how it is with the WTK and SE emulators. The SE however is not really like this, for some strange reason they decided that the stuff that is behind their form implementation will still function. It would appear that you can still scroll the form and interact with the items on it. Items can be updated, and their new contents are shown. Items can be added and will get displayed on the form if say, you added one, then did some un-threaded processing and added another. With this last point, we are getting close to our problem.
With a 'Normal' phone, when 'go' is used, the phone is in a state of apparent 'lock' for about 30 seconds.
After this, the StringItem contains "Count: 10" and the 10 TextFields are displayed.
With the Sony, we see "Count: 1" ... "Count: 10".
We can change the check boxes.
We see The TextFields appear and can even edit them as they do!
So what has this got to do with the CustomItem problem?
Now what does the SE do?
The same thing DictionaryForMIDs does. Some items are painted, some not, several are the wrong size.
We have broken the Sony's background form processing; it would appear that when it was setting up one CustomItem on the form, another came along and it forgot about the first or something. This first item was (I presume) incompletely set-up on the form and now never gets things like its paint method called, even if you force it to request a repaint.
DictionaryForMIDs can execute the translation in the background, on a thread. Does this help? Yes. Things are fixed again for our test, but not in DictionaryForMIDs if we execute the translation in the background.
We have a lot of simulated overhead in our item appending loop, and very little overhead in our CustomItem compared to, say, BitmapFontCanvas. So its down to timing, I guess.
A Thread.sleep(long delay) will fix things in DictionaryForMIDs. I seem to be getting good success with about 300ms on my K800i and this is our simplest answer.
Excuse the long post explaining what is behind this problem.
Over the last 3 days, I have spent some time looking into this problem and can now suggest a workaround, while not perfect is lots better. It is quite simple too.
So, What seems to be causing this problem?
Well.. ..With Forms (and I am not all that experienced in using them since I went the way of a custom UI on a canvas with my apps), the SE has a bit of a quirk to it. One that is not present on the Sony SDK emulators.
Normally, what you would expect when running some process is that the device would be in a state of 'lock', or completely unresponsive to user interaction, bar those that will interrupt the KVM (such as the method for forcing program closure). This is how it is with the WTK and SE emulators. The SE however is not really like this, for some strange reason they decided that the stuff that is behind their form implementation will still function. It would appear that you can still scroll the form and interact with the items on it. Items can be updated, and their new contents are shown. Items can be added and will get displayed on the form if say, you added one, then did some un-threaded processing and added another. With this last point, we are getting close to our problem.
Here is an example description of a MIDlet to demonstrate this quirk:
It consists of a Form, StringItem and ChoiceGroup with 3 check boxes.
There are 2 commands, one to 'exit', and one to 'go'.
Initially, the StringItem contains "Ready"
When 'go' is used, we loop from 1 to 10 and for each cycle of that loop:
We set the StringItem to "Count: "+loop cycle value.
We add a TextField containing "TextField "+loop cycle value.
We wait for 3 seconds.
With a 'Normal' phone, when 'go' is used, the phone is in a state of apparent 'lock' for about 30 seconds.
After this, the StringItem contains "Count: 10" and the 10 TextFields are displayed.
With the Sony, we see "Count: 1" ... "Count: 10".
We can change the check boxes.
We see The TextFields appear and can even edit them as they do!
So what has this got to do with the CustomItem problem?
- We modify our MIDlet.
This time we append a CustomItem that displays our text instead.
Now what does the SE do?
The same thing DictionaryForMIDs does. Some items are painted, some not, several are the wrong size.
We have broken the Sony's background form processing; it would appear that when it was setting up one CustomItem on the form, another came along and it forgot about the first or something. This first item was (I presume) incompletely set-up on the form and now never gets things like its paint method called, even if you force it to request a repaint.
DictionaryForMIDs can execute the translation in the background, on a thread. Does this help? Yes. Things are fixed again for our test, but not in DictionaryForMIDs if we execute the translation in the background.
We have a lot of simulated overhead in our item appending loop, and very little overhead in our CustomItem compared to, say, BitmapFontCanvas. So its down to timing, I guess.
A Thread.sleep(long delay) will fix things in DictionaryForMIDs. I seem to be getting good success with about 300ms on my K800i and this is our simplest answer.
- is it enough for other SE phones?
- is it enough for other dictionaries? (my test one is the English-Chinese one btw)
The delay causes some other problems:
So this needs testing on other SonyEricsson phones.
Another problem also comes to light. DictionaryForMIDs needs to not call MainForm.refreshAllTranslationResults() from within MainForm.updateMainFormItemsObj() after accept is chosen on the settings form. The new delay on the inserting of items is going to cause a long delay as they are re-inserted. During that delay, the settings form can be 'toyed' with while the SE user waits
EDIT: I forgot; it appears that hiding the form is of no help.