WebSMS getNumberOfMessagesForText API

[Vicamo Yang]

Hi,

Per discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=712933#c39 , an ordinary
SMS app might have some of following numbers on screen:

1) Total segments to send: as what this API originally means.
2) Chars available per segment: depending on data code scheme, this
might be 140/70. It might also vary with concatenation involved.
3) Chars already input in current segment.
4) Chars remains available in current segment.

iPhone gets "4)/2)", while Android gets "4)/1)". Both need additional
information about the length of the last segment. And, of course, if an
UCS2-encoding char is appended to an all ASCII text, Android will
updates both numbers with correct ones.

I think a SMS app will need more than current proposed API can provide
and some re-design/extension might be required to complete gaia SMS app
UI.

Vicamo

[Vicamo Yang]

UI. BTW, all of the four numbers mentioned above are already available
in current implementation.

Vicamo

[Philipp von Weitershausen]

Thanks for bringing this up, Vicamo!

On Wed, Mar 14, 2012 at 8:26 PM, Vicamo Yang <vic...@gmail.com> wrote:
> Per discussion in
> https://bugzilla.mozilla.org/show_bug.cgi?id=712933#c39 , an ordinary
> SMS app might have some of following numbers on screen:
>
> 1) Total segments to send: as what this API originally means.
> 2) Chars available per segment: depending on data code scheme, this
> might be 140/70. It might also vary with concatenation involved.
> 3) Chars already input in current segment.
> 4) Chars remains available in current segment.
>
> iPhone gets "4)/2)", while Android gets "4)/1)".

I'm curious how Android computes (4) given their API [1] only exposes
the segments. Perhaps they guess based on the current encoding choice?
In fact, that's what you would have to do anyway, because subsequent
input could always consume more data than you're anticipating right
now.

[1] http://developer.android.com/reference/android/telephony/SmsManager.html#divideMessage%28java.lang.String%29

> Both need additional
> information about the length of the last segment. And, of course, if an
> UCS2-encoding char is appended to an all ASCII text, Android will
> updates both numbers with correct ones.
>
> I think a SMS app will need more than current proposed API can provide
> and some re-design/extension might be required to complete gaia SMS app
> UI.

I agree.

> BTW, all of the four numbers mentioned above are already available
> in current implementation.

We should see if we can squeeze the same amount of information out of
the Android backend. We could declare some of those values optional. I
know Mounir doesn't want to make the Android backend a second class
citizen, but that shouldn't hold us back from being able to implement
an even better experience with the Gonk backend.

Vicamo, do you have a suggestion for modifying the navigator.mozSms
API to provide as much of (1)..(4) as possible?

[Jonas Sicking]

We could change the API to return a JSON object which contains all
this information. Something like:

x = getMessageSegmentInfo("...");
x.segments;
x.remainingLastSegment;
x.lastSegmentSize;
x.charsPerSegment;

/ Jonas

On Thu, Mar 15, 2012 at 7:15 AM, Vicamo Yang <vy...@mozilla.com> wrote:
> Hi,

>
> Per discussion in
> https://bugzilla.mozilla.org/show_bug.cgi?id=712933#c39 , an ordinary
> SMS app might have some of following numbers on screen:
>
> 1) Total segments to send: as what this API originally means.
> 2) Chars available per segment: depending on data code scheme, this
> might be 140/70. It might also vary with concatenation involved.
> 3) Chars already input in current segment.
> 4) Chars remains available in current segment.
>

> iPhone gets "4)/2)", while Android gets "4)/1)". Both need additional

> information about the length of the last segment. And, of course, if an
> UCS2-encoding char is appended to an all ASCII text, Android will
> updates both numbers with correct ones.
>
> I think a SMS app will need more than current proposed API can provide
> and some re-design/extension might be required to complete gaia SMS app
> UI.
>

> Vicamo
>
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Vicamo Yang]

On 03/16/2012 05:03 AM, Philipp von Weitershausen wrote:
> Thanks for bringing this up, Vicamo!
>
> On Wed, Mar 14, 2012 at 8:26 PM, Vicamo Yang <vic...@gmail.com> wrote:

>> Per discussion in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=712933#c39 , an ordinary
>> SMS app might have some of following numbers on screen:
>>
>> 1) Total segments to send: as what this API originally means.
>> 2) Chars available per segment: depending on data code scheme, this
>> might be 140/70. It might also vary with concatenation involved.
>> 3) Chars already input in current segment.
>> 4) Chars remains available in current segment.
>>
>> iPhone gets "4)/2)", while Android gets "4)/1)".

> I'm curious how Android computes (4) given their API [1] only exposes
> the segments. Perhaps they guess based on the current encoding choice?
> In fact, that's what you would have to do anyway, because subsequent
> input could always consume more data than you're anticipating right
> now.
>
> [1] http://developer.android.com/reference/android/telephony/SmsManager.html#divideMessage%28java.lang.String%29

In packages/apps/Mms/src/com/android/mms/ui/ComposeMessageActivity.java:

private void updateCounter(CharSequence text, ...) {
...
int[] params = SmsMessage.calculateLength(text, false);
/* SmsMessage.calculateLength returns an int[4] with:
* int[0] being the number of SMS's required,
* int[1] the number of code units used,
* int[2] is the number of code units remaining until the next message.
* int[3] is the encoding type that should be used for the message.
*/
...
}

The mapping of their meanings to items listed in my last post is int[0]
=> 1), int[1] => 3), int[2] => 4), int[3] => 2).
SmsManager.divideMessage() is only used at sending messages out.

>> BTW, all of the four numbers mentioned above are already available
>> in current implementation.
> We should see if we can squeeze the same amount of information out of
> the Android backend. We could declare some of those values optional. I
> know Mounir doesn't want to make the Android backend a second class
> citizen, but that shouldn't hold us back from being able to implement
> an even better experience with the Gonk backend.

Since SmsMessage.calculateLength() is public to Mms application, I think
extending this API won't raise such concern in the Android backend.

> Vicamo, do you have a suggestion for modifying the navigator.mozSms
> API to provide as much of (1)..(4) as possible?

To be compatible with Android backend, values other than the four
provided by original Android API should be avoid as possible. I don't
really know what will UI people say, but the four items cover even
iPhone sms UI design. So I think these four values will be enough for
everyone :P

Vicamo

[Vicamo Yang]

Looks good for method/attribute names, but will it cost a lot returning
an object? This API will be called every key stroke. Will returning a
numeric array as what Android did be simpler?

Vicamo

[Jonas Sicking]

On Thu, Mar 15, 2012 at 8:36 PM, Vicamo Yang <vy...@mozilla.com> wrote:
> Looks good for method/attribute names, but will it cost a lot returning
> an object? This API will be called every key stroke. Will returning a
> numeric array as what Android did be simpler?

Not really no. Especially since this won't be called in a tight loop
anywhere, but rather just once on every key stroke.

/ Jonas

[Mounir Lamouri]

On 03/15/2012 03:15 PM, Vicamo Yang wrote:
> Hi,

>
> Per discussion in
> https://bugzilla.mozilla.org/show_bug.cgi?id=712933#c39 , an ordinary
> SMS app might have some of following numbers on screen:
>
> 1) Total segments to send: as what this API originally means.
> 2) Chars available per segment: depending on data code scheme, this
> might be 140/70. It might also vary with concatenation involved.

I doubt this is useful. Even if, (3) and (4) should be enough to find it.

> 3) Chars already input in current segment.
> 4) Chars remains available in current segment.

A temporary solution for those would be to call
getNumberOfMessagesForText with shorter/longer string then do the maths.
Though, we probably need an API to make this efficient.

--
Mounir

[beatr...@gmail.com]

El viernes, 16 de marzo de 2012 15:37:29 UTC+1, Mounir Lamouri escribió:
> On 03/15/2012 03:15 PM, Vicamo Yang wrote:
>
> > Hi,
>
> >
>
> > Per discussion in
>
> > https://bugzilla.mozilla.org/show_bug.cgi?id=712933#c39 , an ordinary
>
> > SMS app might have some of following numbers on screen:
>
> >
>
> > 1) Total segments to send: as what this API originally means.
>
> > 2) Chars available per segment: depending on data code scheme, this
>
> > might be 140/70. It might also vary with concatenation involved.
>

I will add the possibility of 160 characters when using default 7bit :-)

>
> I doubt this is useful. Even if, (3) and (4) should be enough to find it.
>
>
>
> > 3) Chars already input in current segment.
>
> > 4) Chars remains available in current segment.
>

There is other bug to follow the chars counter #813689

>
> A temporary solution for those would be to call
>
> getNumberOfMessagesForText with shorter/longer string then do the maths.
>
> Though, we probably need an API to make this efficient.
>
> --
>
> Mounir

IMHO, the best option will be to offer '4/1'. We will fix both issues with it.
Beatriz.

You can also follow this discussion at: https://bugzilla.mozilla.org/show_bug.cgi?id=813682