Closed
Bug 816110
Opened 12 years ago
Closed 12 years ago
Make cost control app use a system message to detect when SMS has been sent
Categories
(Firefox OS Graveyard :: Gaia::Cost Control, defect, P1)
Tracking
(blocking-basecamp:+)
People
(Reporter: salva, Assigned: salva)
References
Details
(Whiteboard: [slim:10MB][target:12/21])
Attachments
(2 files)
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.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → dale
Comment 1•12 years ago
|
||
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•12 years ago
|
||
Blocking due to memory saving.
Can we also get a bug filed to stop running that Cost Control daemon?
blocking-basecamp: ? → +
Summary: System message on SMS sent → Make cost control app use a system message to detect when SMS has been sent
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.
blocking-basecamp: + → ?
Assignee | ||
Comment 4•12 years ago
|
||
(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.
Flags: needinfo?(jonas)
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.
Flags: needinfo?(jonas)
Updated•12 years ago
|
Assignee: dale → nobody
Comment 6•12 years ago
|
||
(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.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → salva
Comment 7•12 years ago
|
||
I'm marking this as a soft blocker for the memory savings alone.
blocking-basecamp: ? → -
Priority: -- → P4
Comment 8•12 years ago
|
||
Sorry for the churn but this should really be a Gaia bug. Re-nomming for Gaia triage.
blocking-basecamp: - → ?
Component: General → Gaia::Cost Control
Priority: P4 → --
QA Contact: carlos.martinez
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•12 years ago
|
||
(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).
Assignee | ||
Comment 11•12 years ago
|
||
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.
Blocks: 809272
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•12 years ago
|
||
(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.
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?
Assignee | ||
Comment 15•12 years ago
|
||
: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.
Updated•12 years ago
|
blocking-basecamp: ? → +
Priority: -- → P1
Comment 16•12 years ago
|
||
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.
Target Milestone: --- → B2G C3 (12dec-1jan)
Updated•12 years ago
|
Whiteboard: [slim:10MB] → [slim:10MB][target:12/21]
Assignee | ||
Comment 18•12 years ago
|
||
I can not progress because I'm not receiving any message for sms-sent or telephony-call-ended
Can you provide me some help?
Flags: needinfo?
Assignee | ||
Comment 19•12 years ago
|
||
Ok, problem solved. See Bug 823880.
Depends on: 823880
Flags: needinfo?
Assignee | ||
Comment 20•12 years ago
|
||
It is done but I need to land bug 816927 before.
Comment 21•12 years ago
|
||
(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
Assignee | ||
Comment 22•12 years ago
|
||
Attachment #695300 -
Flags: review?(dale)
Attachment #695300 -
Flags: review?(21)
Attachment #695300 -
Flags: review?(dale)
Attachment #695300 -
Flags: review?(21)
Attachment #695300 -
Flags: review+
Comment 23•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•