834334 - Proposal for removing Cost Control's message handler

Status: RESOLVED WONTFIX

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

Description

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

Actually, the message handler (MH) is in charge of receiving several system messages, attending them and closing itself. The message handler has not interface and it is intended to be launched by the system, having a fast start-up and closing ASAP in order to free memory.

But it introduces a lot of complexity:
  1- As the window manager drops a system message if the application is in foreground, the application need to register the callbacks again when they should be attended by MH.
  2- Furthermore, as an alarm cannot be received by other URL than which one installing it, all views must have a inner iframe pointing to MH.
  3- To not register callbacks twice, this responsibility is delegated to MH via the iframe. The MH is able to distinguish when it is on standalone mode (no iframe) or application mode (inside an iframe).
  4- Until MH is not ready (have registered all the callbacks) any component including it can load so a lot of synchronization effort is here.
  5- In standalone mode, the MH tries to close itself as soon as it attend the message but closing can have unexpected results as avoiding an async storage operation to finish or avoiding sending a desktop notification.
  6- Some code that should reside in MH but remaining accessible from other points of the application should be redirected with artificial bridges in order to avoid code repetition.
  7- The ConfigManager must be a singleton but since some components include iframes the object inside the iframe should be redirected to point its parent ConfigManager. If not, "race" conditions arise.

By removing MH we reduce the complexity but the application won't close itself automatically. Instead, it will remain in background in the same way the current SMS application remains in background after receiving a SMS.

It is important to note the CC application, if closed, will be launched with almost every activity on the device (sending a SMS, finishing a call, receiving a SMS...) so the CC application will remain active the major part of the time but if the device runs out of memory, nothing prevents Gecko to dispose the CC application.

I think the trade off memory / complexity does not worth it. Furthermore, this level of complexity puts in risk code maintainability.

Comment 1

[Dietrich Ayala (:dietrich)]

tracking-. if there's a concrete user impact and agreed-on approach, re-nominate.

Comment 2

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

(In reply to Dietrich Ayala (:dietrich) from comment #1)
> tracking-. if there's a concrete user impact and agreed-on approach,
> re-nominate.

Now we have an impact in the user experience as the message_handler separation is revealing a leo+ bug based on a race condition impossible to avoid. See bug 882084 for further details. Renominating.

Comment 3

[Dietrich Ayala (:dietrich)]

Noemi will talk to Salva to see if option #1 in bug 882084 is possibly smaller and less risky for 1.1, given that we are trying to minimize any code changes at all.

Comment 4

[Noemí Freire (:noemi)]

de-nominating this issue since it won't be necessary to cover it once the issue reported in Bug 888926 is solved

Comment 5

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

I hope this won't be necessary for the new Smart Data application I will push for avoiding it as much as possible but for Cost Control, I fear it's too late.