HTC Magic, is PhoneNumberUtils.PAUSE different?

by Alejandro » Mon, 27 Apr 2009 12:37:42 GMT

Sponsored Links
 I am getting reports that the in the HTC Magic the character that
represents the pause in a dial string is different than in the Google
build of cupcake. In the SDK 1.5 pre-release, the pause is given by a
','. Apparently, in the HTC magic, the pause is given by a 'p'.
Unfortunately, I don't currently have the means to test this. Does
anyone know if the PhoneNumberUtils.PAUSE member in the HTC magic
build reflects this change? Have any other functions in
PhoneNumberUtils changed in order to support this?

Thank you,


HTC Magic, is PhoneNumberUtils.PAUSE different?

by Alejandro » Thu, 25 Jun 2009 14:05:38 GMT

 The Rogers HTC Magic phone is using the 'p' as a pause, but it seems
they haven't changed the PhoneNumberUtils.PAUSE to reflect this. This
is rather unfortunate, because it makes the Rogers build non-standard
and my app breaks. I would hope in the future there are no more
deviations of the standard SDK, otherwise, developing for the Android
platform will become harder.



Sponsored Links

Other Threads

1. Strange behavior in EditText box on Samsung devices

I'm struggling with some strange bahavior in EditText fields on the
Samsung Galaxy Tab and Samsung Galaxy S. Has anyone else experienced
similar behavior to this?

I'm using an EditText as an input window for URLs. As the user enters
a character in it, I want to autocomplete it, i.e., look up the string
in a list of URLs, find the first match (if any), and change the
contents of the EditText to that URL, while keeping a selection around
the suggested part.

So, the sequence is:
1. User enters character (f.i. the 'c' in 'www.c').
2. onTextChanged is called, notifies my own thread, and returns
3. My own thread then posts a Runnable in which I do the following:
4. Using setText, I change the text to, i.e.,
5. Using setSelection, I select the suggested part (i.e., '')

Problem On Samsung Galaxy S (and possibly other Samsung devices),
using the Samsung IME:
It seems like every time a character is entered in the URL field, the
text it is set twice; once immediately, and then "magically" again a
few ms later. In the above case, the text gets reset to 'www.c'
*after* I've autocompleted it. Delaying the posting of the Runnable
which changes the text for a few (~10) ms (using postDelayed) works
around this.

Second problem, occurring so far on the Galaxy Tab and Galaxy S, and
only in landscape mode, when the IME is fullscreen, but with *any*
Even with the above workaround, the selection on the suggestion part
of the URL is cleared (while the actual text remains). This time, it
appears that the effect of the setText call in step 4 is repeated
(again, "magically") after about 100 ms. Using another call to
postDelayed, I can delay the call to setSelection a further 100 ms,
which again works around the problem.

Both workarounds are very ugly, timing-dependent solutions, and I'd
rather find a better one.

Usually, the magic text-set is accompanied by some nondescript lines
of logcat error output.

On the Galaxy Tab, using Samsung IME, I get this:
01-31 21:25:49.500: ERROR/AxT9IME(20639): WordSymbInit: 1
01-31 21:25:49.508: ERROR/KeyLedTest(20639): KeyLedTest++
01-31 21:25:49.508: ERROR/KeyBoardLed(19113): UpdateState../sys/class/
sec/keyboard/keyboard_led state false
01-31 21:25:49.512: ERROR/KeyBoardLed(19113): UpdateState../sys/class/
sec/keyboard/keyboard_led state false finished
01-31 21:25:49.512: ERROR/KeyLedTest(20639): service.UpdateState0
01-31 21:25:49.512: ERROR/InputMethodService(20639): Keyboard State :

With a different IME than Samsung's, I only get the last one of these

On Samsung Galaxy S, I only get an error when using Samsung's IME.
What I get is this:

01-31 12:22:14.622: ERROR/AxT9IME(2583): WordSymbInit: 1

Again, has anyone else experienced similar behavior to this?


2. Logging should not be Android specific?? Why not SLF4J??

I am trying to understand why the  logging API in Android was not made
independent of the platform. SLF4J has a clean separation between the
logging API, and a pluggable logging implementation. In this scheme,
the Android platform would just provide the logging implementation
specific for the platform, but all of the logging statements sprinkled
throughout the code would just be generic SLF4J and thus not platform
specific. Given that logging tends to pervade the entire codebase, it
seems this separation is critical for allowing Java libraries to
function in applets, web applications, and mobile applications.

It is unfortunate that Sun did a poor job with the official JDK
logging scheme, which lead to it not being universally adopted, but
now it seems that Android has made the Java logging nightmare that
much more unpleasant. Logging should really be part of the language
specification rather than a library addon.

There is already SLF4J for android with the logging implementation
just delegating to the android logger, and so my question is, why is
there not a best practice directive to use SLF4J logging, or better
still, official adoption?

It seems so obvious, I fear I must be ignorant of good arguments
against this...

Thanks for any insight!


3. How to profile an application for CPU time/ Network io time?

4. [Android update sdk] How to download a specifiy platform from the command line?

5. How to sort HashMap?

6. Pictures taken in my camera app not showing up in gallery

7. DroidX adding or editing contact problem