816110 - Make cost control app use a system message to detect when SMS has been sent

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Cost Control, defect, P1)

Description

[Salvador de la Puente González [:salva]]

This is motivated by the need of keeping accurate statistics about how many SMS the device sent for the telephony module of Cost Control application in order to avoid any sort of background service to preserve as much battery as possible.

So I suggest to trigger a system message every time a SMS is sent with the information about how many real messages have been sent or, if we are dispatching a system message every time a real SMS is sent, then some kind of identifier to group those part of the same "large" SMS.

Without system messages we need to keep a script listening on DOM APIs. If this daemon is in system we can not communicate with CostControl (despite some ugly hacks). If it is in Cost Control, it could be killed missing the SMS sent while not awake.

Comment 1

[Marcelino Veiga Tuimil [:sonmarce]]

With this bug together with bug #816101 it can be kept all the current functionality of Cost Control Application, but using less memory resources, as it is not necessary to have a background service running all the time.

Comment 2

[Andrew Overholt [:overholt]]

Blocking due to memory saving.

Can we also get a bug filed to stop running that Cost Control daemon?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Putting this back to nom. I'm not convinced that we'd hold shipping for getting the Cost Control app to not have to stay alive.

Comment 4

[Salvador de la Puente González [:salva]]

(In reply to Jonas Sicking (:sicking) from comment #3)
> Putting this back to nom. I'm not convinced that we'd hold shipping for
> getting the Cost Control app to not have to stay alive.

Why are you not convinced? Please, explain yourself.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Because we're very short on time before we have to ship. And saving a few MB of memory doesn't seem like something that would make us hold the release.

Comment 6

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Jonas Sicking (:sicking) from comment #5)
> Because we're very short on time before we have to ship. And saving a few MB
> of memory doesn't seem like something that would make us hold the release.

This is also the last application that use background service and the support can't be remove without this work. The changes in background service is in a good shape and the platform code too.

Also background services can be killed and there is no code to restart them on the fly, so may result into an unexpected brokenness.

CC'ing cjones, jlebar that knows more than me about memory issues.

Comment 7

[Andrew Overholt [:overholt]]

I'm marking this as a soft blocker for the memory savings alone.

Comment 8

[Andrew Overholt [:overholt]]

Sorry for the churn but this should really be a Gaia bug.  Re-nomming for Gaia triage.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This isn't "a few MB", it's 10% of available app memory.

I'm not convinced we need a system message for this use case.  What about a counter in the sms API?

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #9)
> This isn't "a few MB", it's 10% of available app memory.
> 
> I'm not convinced we need a system message for this use case.  What about a
> counter in the sms API?

Cost Control needs to save when the sms has been sent in order to draw the consumption of sms in time on a canvas. The sms counter solution would have to contains more information than just the number of sms sent (like when has been sent the sms).

Comment 11

[Salvador de la Puente González [:salva]]

I need to accurately count how many messages have been sent from a start time. If you provide me with a historical of SMS, I'm ok. I prefer the solution with system messages because is up to the applications to count in any way.

Thanks.

Comment 12

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

What are we trying to achieve here?

There's no way to provide users accurate usage numbers by only measuring on-device.  Because, obviously, I could use my SIM card in another phone.  That's why I thought we were querying the operator to get the "real" usage info.

Given that, we're at best showing users some marginally-useful historical data, and at worst we're misleading them quite a bit, by showing lower usage than their SIM card has actually charged.

Comment 13

[Marcelino Veiga Tuimil [:sonmarce]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> What are we trying to achieve here?
> 
> There's no way to provide users accurate usage numbers by only measuring
> on-device.  Because, obviously, I could use my SIM card in another phone. 
> That's why I thought we were querying the operator to get the "real" usage
> info.
> 
> Given that, we're at best showing users some marginally-useful historical
> data, and at worst we're misleading them quite a bit, by showing lower usage
> than their SIM card has actually charged.

I thinks it is too late for this kind of discussion. Cost Control functionality was defined several months ago, clearly documented in wireframes, included in product definition, and it is already implemented. The reason of this bug is that it was requested to reduce resource use of Cost Control application, not having a service continuously running and consuming memory.

Comment 14

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

If we're about to ship a feature that aims to help users control costs, but does the opposite (doesn't help and maybe hurts), then I think we should finish this discussion ;).

Do we at least have UI in place to let users know that these are estimates, not values that they can rely on?  Are we able to query important usage totals (#SMSs, data usage, talk time) from the operator and display those in a way that users can trust, with historical graphs displayed as advisory information?

Comment 15

[Salvador de la Puente González [:salva]]

:cjones, :sonmarce, you are talking about the same issue that is being discussed here in bug #809272.

:cjones you are right, it is only an estimation and we should warn about it. :sonmarce you are right as well, wireframes have been there since long time ago.

Both of you are right because this is not our problem, it is a problem with the operator and its API (which is SMS for balance and **nothing more**). That sucks but this approach is our best approach because we have no way to get more info from the operator.

Comment 16

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 18

[Salvador de la Puente González [:salva]]

Attachment: Manifest of Cost Control application

I can not progress because I'm not receiving any message for sms-sent or telephony-call-ended

Can you provide me some help?

Comment 19

[Salvador de la Puente González [:salva]]

Ok, problem solved. See Bug 823880.

Comment 20

[Salvador de la Puente González [:salva]]

It is done but I need to land bug 816927 before.

Comment 21

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Salvador de la Puente González [:salva] from comment #20)
> It is done but I need to land bug 816927 before.

I just merged it as https://github.com/mozilla-b2g/gaia/commit/6c9dc5b25e0feea0d477243d896344b6e35e5f01

Comment 22

[Salvador de la Puente González [:salva]]

Attachment: System messages management added

Comment 23

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/82a5a1084cedde7c67a8cdf16c4195dba04435e4