Closed Bug 808919 Opened 12 years ago Closed 12 years ago

Really need to open Settings App at start up? which occupies resources for 9 seconds!

Categories

(Firefox OS Graveyard :: Gaia, defect)

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-basecamp:+)

Status:
VERIFIED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: airpingu, Assigned: frsela)

References

Details

Attachments

(2 files)

Patch which cache the data without loading all settings app and shows the correct STK menu entry correctly
361 bytes, text/html
vingtetun
: review-
Details
Patch which cache the data without loading all settings app and shows the correct STK menu entry correctly (cache in system version)
361 bytes, text/html
vingtetun
: review+
Details 
I'm wondering if we really need to open the Settings App at start up? which would occupies the resources around 9 seconds, making the start-up a bit slow to go into the stable stage. The Settings App is simply opened due to the 'icc-stkcommand' system messages. Is it possible to set the icc-stkcommand settings from the internal Gecko instead of launching the whole Settings App to handle that? It sounds a bit consuming to me.
We must not open the settings app at startup. I already commented on that in a different bug. We can handle the icc-stkcommand in the system app and stash the menu values until we need them. Or change the stk API to retrieve that data on demand when the settings app needs it. +-ing on this because this is really ridiculous.
blocking-basecamp: --- → +
Blocks: slim-fast
Completely agree.

This had been discussed some weeks ago since I asked to cache support at Gecko level since the STK commands should be responded, so for MENU LIST retrieval is not needed to fire an event to the UI and store it since it's needed.

See previous discussions:

  https://bugzilla.mozilla.org/show_bug.cgi?id=792751
  https://github.com/frsela/gaia/issues/9

Finally it has been decided to implement it at Gaia level, so it's managed on Settings App.

The collateral effect is that the settings app is opened to process the message. It's true that it can be closed as soon as the message is cached but is a dirty solution.

Another alternative is to implement it as a background service.

I opened a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=800274) to support this so I think this is a duplicate of the 800274
I guess the System app can violate the Settings API in order to cache the value. Then the Settings App can read this value when it needs it. In the longer term we need a better solution to do such things but this will work as a hack. An other solution could be for the System app to create a file in /data/local/simapps that can be retrieve by the Settings App when it needs it.
(In reply to Naoki Hirata :nhirata from comment #5)
> Is this a dup of bug 797395?

Nope. Bug 797395 is about to make it fast everytime you open it after it has been killed. This one is about not opening it in the background when the device starts.
(In reply to Vivien Nicolas (:vingtetun) from comment #4)
> I guess the System app can violate the Settings API in order to cache the
> value. Then the Settings App can read this value when it needs it. In the
> longer term we need a better solution to do such things but this will work
> as a hack. An other solution could be for the System app to create a file in
> /data/local/simapps that can be retrieve by the Settings App when it needs
> it.

I think use the filesystem to transfer data between apps is a dirty solution ... mainly for cached information ...

What's the problem to add a background.html + background_icc.js on settings app and only this background service will attend ICC commands, cache it etc...?
Even just starting background.html will require spinning up a process. Not my favorite solution. Settings is hacky but should do for v1. We can come up with something more clever later.
(In reply to Andreas Gal :gal from comment #8)
> Even just starting background.html will require spinning up a process. Not
> my favorite solution. Settings is hacky but should do for v1. We can come up
> with something more clever later.

Agree.

As I suggested some a months ago (Bug #792751) I think a clever way could be that the menu cache should be done at platform level (ie, gecko) so the navigator.mozMobileConnection.icc component should respond to all new main menu commands and store it and offer a "getMainMenu()" method to gaia to recover the cached one.

For the FRE it can also get the unsolicited apps so getUnsolicitedApp() or similar to recover the Activation one.

So we can avoid open apps with system-message for each STK command ... or only for unsolicited app like SIM Activation ...
I totally agree with Fernando. The best solution is to cache the menu at Gecko Level and expose a method to query the menu when needed. In addition, for unsolicited apps there can be a system message to be listened by the FTU app. 

Andreas do you think we can pursue this solution? Yosi, how difficult this would be to make this change?
Flags: needinfo?(allstars.chh)
I totally agree with Fernando. The best solution is to cache the menu at Gecko Level and expose a method to query the menu when needed. In addition, for unsolicited apps there can be a system message to be listened by the FTU app. 

Andreas do you think we can pursue this solution? Yosi, how difficult this would be to make this change?
Sounds good to me. Hack it up.
The question is the SIM app might want to interact with user automatically. For example, SIM activation, it will pop up to ask user to activate the SIM, even user doesn't do anything after booting up. So in the first place, gecko passed stk command to gaia to let gaia can handle this freely. Even caching this stk command in gecko, the gaia side still need to retrieve this stk command without user asks for it.

Sorry I don't know what is getUnsolicitedApp(). I cannot comment.

If you think launch settings app is too heavy, why do you put STK app in Settings?
Flags: needinfo?(allstars.chh) needinfo?(allstars.chh) → needinfo+
The question is the SIM app might want to interact with user automatically. For example, SIM activation, it will pop up to ask user to activate the SIM, even user doesn't do anything after booting up. So in the first place, gecko passed stk command to gaia to let gaia can handle this freely. Even caching this stk command in gecko, the gaia side still need to retrieve this stk command without user asks for it.

Sorry I don't know what is getUnsolicitedApp(). I cannot comment.

If you think launch settings app is too heavy, why do you put STK app in Settings?
(In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #14)
> The question is the SIM app might want to interact with user automatically.
> For example, SIM activation, it will pop up to ask user to activate the SIM,
> even user doesn't do anything after booting up. So in the first place, gecko
> passed stk command to gaia to let gaia can handle this freely. Even caching
> this stk command in gecko, the gaia side still need to retrieve this stk
> command without user asks for it.
> 

Yes, that's the idea, I'll try to explain me better:

We've 2 use cases, the menu and the "auto STK apps" (like SIM Activation)

Case 1: Main Menu. Instead send a system message which opens Settings, we suggest to store it in gecko level and respond the command at gecko level to.

The ICC API will expose a new method "navigator.mozMobileConnection.getMainMenu()" which return the Main STK menu (command 37):

{"commandNumber":1,"typeOfCommand":37,"commandQualifier":0,"rilMessageType":"stkcommand","options":{"title":"Movistar","items":[{"identifier":3,"text":"Chat movistar"},{"identifier":4,"text":"Correo movil"}],"presentationType":0}}

So we avoid to launch settings app each time the phone is restarted and we can get the STK main menu at any time since it's cached in gecko level.

Case 2: STK Apps which are automatically opened.

In this second case we need to open the settings app, so a system message is ok for me to open settings with the app.

The gecko module can send this system-message when a typeOfCommand=36 is received and no "icc.sendStkMenuSelection()" had been called before. In this case, the STK command 36 is unsolicited one (like SIM Activation) so System Message should be sent ;)


> Sorry I don't know what is getUnsolicitedApp(). I cannot comment.
> 

For the second case if no system message is sent ... but probably not needed

> If you think launch settings app is too heavy, why do you put STK app in
> Settings?

UX decision not mine ... moreover, I started the work as a separate app and I should move it to settings ...

Anyway the problem is not "settings", is open an app only to cache a menu ...

----

For resume:

1.- navigator.mozMobileConnection.icc will only send System Message "icc-stkcommand" for non solicited apps (like SIM Activation)
2.- navigator.mozMobileConnection.icc will manage internally the menu command (37) and store in RAM.
3.- navigator.mozMobileConnection.icc.getMainMenu() will return the stored main menu [2]
4.- navigator.mozMobileConnection.icc will send a normal event "stkcommand" for all the commands except 37?

WDYT?

I can drive these changes or if you prefer to drive it since is your code, I'll be happy too :)
(In reply to Fernando R. Sela [:frsela] from comment #15)
> 
> Yes, that's the idea, I'll try to explain me better:
> 
> We've 2 use cases, the menu and the "auto STK apps" (like SIM Activation)
> 
> Case 1: Main Menu. Instead send a system message which opens Settings, we
> suggest to store it in gecko level and respond the command at gecko level to.
> 
> The ICC API will expose a new method
> "navigator.mozMobileConnection.getMainMenu()" which return the Main STK menu
> (command 37):
> 
> {"commandNumber":1,"typeOfCommand":37,"commandQualifier":0,"rilMessageType":
> "stkcommand","options":{"title":"Movistar","items":[{"identifier":3,"text":
> "Chat movistar"},{"identifier":4,"text":"Correo
> movil"}],"presentationType":0}}
> 
> So we avoid to launch settings app each time the phone is restarted and we
> can get the STK main menu at any time since it's cached in gecko level.
> 
> Case 2: STK Apps which are automatically opened.
> 
> In this second case we need to open the settings app, so a system message is
> ok for me to open settings with the app.
> 
> The gecko module can send this system-message when a typeOfCommand=36 is
> received and no "icc.sendStkMenuSelection()" had been called before. In this
> case, the STK command 36 is unsolicited one (like SIM Activation) so System
> Message should be sent ;)
> 

Don't you think you're making the API harder to use?
For some type of proactive command you need to cache it, for other type you need to send it to gaia.

> 
> > Sorry I don't know what is getUnsolicitedApp(). I cannot comment.
> > 
> 
> For the second case if no system message is sent ... but probably not needed
> 
> > If you think launch settings app is too heavy, why do you put STK app in
> > Settings?
> 
> UX decision not mine ... moreover, I started the work as a separate app and
> I should move it to settings ...
> 
> Anyway the problem is not "settings", is open an app only to cache a menu ...
> 
I don't agree here, yes there should be an app to read the menu, but now it is Settings app to do this, so now gaia will bring up whole Settings app, which causes lots of memory unnecessary.

Again I disagree your idea from the view of API design.
The idea to use system-message to send icc command is to let gaia wake up the Stk gaia app only when SIM has sent a proactive command, so gaia side doesn't have to fork some portion of code to keep listening to STK command event.

Above is my idea, I don't think your suggestion is a good idea. 
But you can ask comments from others for reviewing your API proposal, for example dev-webapi.
(In reply to Fernando R. Sela [:frsela] from comment #15)
> (In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #14)
> > The question is the SIM app might want to interact with user automatically.
> > For example, SIM activation, it will pop up to ask user to activate the SIM,
> > even user doesn't do anything after booting up. So in the first place, gecko
> > passed stk command to gaia to let gaia can handle this freely. Even caching
> > this stk command in gecko, the gaia side still need to retrieve this stk
> > command without user asks for it.
> > 
> 
> Yes, that's the idea, I'll try to explain me better:
> 
> We've 2 use cases, the menu and the "auto STK apps" (like SIM Activation)
> 
> Case 1: Main Menu. Instead send a system message which opens Settings, we
> suggest to store it in gecko level and respond the command at gecko level to.
> 
> The ICC API will expose a new method
> "navigator.mozMobileConnection.getMainMenu()" which return the Main STK menu
> (command 37):
> 
> {"commandNumber":1,"typeOfCommand":37,"commandQualifier":0,"rilMessageType":
> "stkcommand","options":{"title":"Movistar","items":[{"identifier":3,"text":
> "Chat movistar"},{"identifier":4,"text":"Correo
> movil"}],"presentationType":0}}
> 
> So we avoid to launch settings app each time the phone is restarted and we
> can get the STK main menu at any time since it's cached in gecko level.
> 
> Case 2: STK Apps which are automatically opened.
> 
> In this second case we need to open the settings app, so a system message is
> ok for me to open settings with the app.

Do we have other use cases for unsolicited apps apart from the SIM activation from Vivo, because if that is the case then we should listen to those messages only on the FTU but not on the Settings app. If we start listening for those messages in the Settings app the result will be to regress to the current situation we all agree is not optimal. 


> For resume:
> 
> 1.- navigator.mozMobileConnection.icc will only send System Message
> "icc-stkcommand" for non solicited apps (like SIM Activation)
> 2.- navigator.mozMobileConnection.icc will manage internally the menu
> command (37) and store in RAM.
> 3.- navigator.mozMobileConnection.icc.getMainMenu() will return the stored
> main menu [2]
> 4.- navigator.mozMobileConnection.icc will send a normal event "stkcommand"
> for all the commands except 37?
> 
> WDYT?
> 
> I can drive these changes or if you prefer to drive it since is your code,
> I'll be happy too :)

For me is perfect Fernando de summary you provide above with the only disclaimer I have explained at the beginning. So I think we can move forward and start with the implementation
> 
> Do we have other use cases for unsolicited apps apart from the SIM
> activation from Vivo, because if that is the case then we should listen to
> those messages only on the FTU but not on the Settings app. If we start
> listening for those messages in the Settings app the result will be to
> regress to the current situation we all agree is not optimal. 
> 

The FTU cannot listen for that event because if may be already finished when the activation request is received from VIVO.
(In reply to Jose M. Cantera from comment #17)
> > 
> > Case 2: STK Apps which are automatically opened.
> > 
> > In this second case we need to open the settings app, so a system message is
> > ok for me to open settings with the app.
> 
> Do we have other use cases for unsolicited apps apart from the SIM
> activation from Vivo, because if that is the case then we should listen to
> those messages only on the FTU but not on the Settings app. If we start
> listening for those messages in the Settings app the result will be to
> regress to the current situation we all agree is not optimal. 
> 

Each operator can decide to have a similar STK app to be launched at any time :\
(In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #16)

Thank your Yoshi.

Since there are different opinions about this, I just uploaded a patch at Gaia level.

I hope this patch make happy everyone :)

1.- This patch loads the menu in a little JS which attends the System Message
2.- This patch solves the bug #810831 so I market it as a duplicate of this ;) - On settings load, I use another little JS to provision main menu name
3.- The rest of STK Commands are attended with a normal event (no system one)

Pending task: Support SIM Activation and similar apps.

My idea is to support it in the icc_cache.js and System or FRE can be also registered to the icc-stkcommand in order to open settings.

Another way is to offer an activity on settings to open ICC ...

Anyway, I think this other task should be driven on another bug. Do you agree?
(In reply to Fernando R. Sela [:frsela] from comment #22)
> (In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #16)
> 
> Thank your Yoshi.
> 
> Since there are different opinions about this, I just uploaded a patch at
> Gaia level.
> 
> I hope this patch make happy everyone :)
> 
> 1.- This patch loads the menu in a little JS which attends the System Message

+1. This solution does not imply Gecko changes and is clean

> 2.- This patch solves the bug #810831 so I market it as a duplicate of this
> ;) - On settings load, I use another little JS to provision main menu name
> 3.- The rest of STK Commands are attended with a normal event (no system one)
> 
> Pending task: Support SIM Activation and similar apps.
> 
> My idea is to support it in the icc_cache.js and System or FRE can be also
> registered to the icc-stkcommand in order to open settings.
> 
> Another way is to offer an activity on settings to open ICC ...

Other option is to open an attention screen for unsolicited apps but we would need to see the implications in the FTU. You can talk to Borj about that. 

> 
> Anyway, I think this other task should be driven on another bug. Do you
> agree?
Comment on attachment 682395 [details]
Patch which cache the data without loading all settings app and shows the correct STK menu entry correctly

As I said on Github let's send those messages to the system app in order to cache them in a setting for now.
Attachment #682395 - Flags: review?(21) → review-
I just plugged a Tuenti SIM into our phone and more STK message are sent on startup which shall be showed to the user so ... Should we attend all these messages on System or Settings?:

commandQualifier":128,"rilMessageType":"stkcommand","options":{"text":"Hay un problema con tu tarjeta SIM. Entra en www.tuenti.com para que nuestro servicio de atencion al cliente te ayude a solucionarlo.","userClear":true}}
E/GeckoConsole(  949): Content JS WARN at app://settings.gaiamobile.org/js/icc_cache.js:21 in debug: [DEBUG] STKCACHE: STK Proactive Command:{"commandNumber":1,"typeOfCommand":33,"commandQualifier":128,"rilMessageType":"stkcommand","options":{"text":"Hay un problema con tu tarjeta SIM. Entra en www.tuenti.com para que nuestro servicio de atencion al cliente te ayude a solucionarlo.","userClear":true}}
E/GeckoConsole(  949): Content JS WARN at app://settings.gaiamobile.org/js/icc_cache.js:21 in debug: [DEBUG] STKCACHE: STK Proactive Command:{"commandNumber":1,"typeOfCommand":37,"commandQualifier":0,"rilMessageType":"stkcommand","options":{"title":"SIM Tuenti","items":[{"identifier":1,"text":"Consulta saldo"},{"identifier":2,"text":"Recarga"},{"identifier":3,"text":"Bono"},{"identifier":4,"text":"Att cliente"},{"identifier":5,"text":"Tuenti Movil"},{"identifier":6,"text":"Tuenti Sitios"},{"identifier":7,"text":"Agenda Tuenti"}],"presentationType":0}}
E/GeckoConsole(  949): Content JS WARN at app://settings.gaiamobile.org/js/icc_cache.js:21 in debug: [DEBUG] STKCACHE: STK_CMD_SET_UP_MENU:{"title":"SIM Tuenti","items":[{"identifier":1,"text":"Consulta saldo"},{"identifier":2,"text":"Recarga"},{"identifier":3,"text":"Bono"},{"identifier":4,"text":"Att cliente"},{"identifier":5,"text":"Tuenti Movil"},{"identifier":6,"text":"Tuenti Sitios"},{"identifier":7,"text":"Agenda Tuenti"}],"presentationType":0}
E/GeckoConsole(  949): Content JS WARN at app://settings.gaiamobile.org/js/icc_cache.js:21 in debug: [DEBUG] STKCACHE: STK Proactive Command:{"commandNumber":1,"typeOfCommand":37,"commandQualifier":0,"rilMessageType":"stkcommand","options":{"title":"SIM Tuenti","items":[{"identifier":1,"text":"Consulta saldo"},{"identifier":2,"text":"Recarga"},{"identifier":3,"text":"Bono"},{"identifier":4,"text":"Att cliente"},{"identifier":5,"text":"Tuenti Movil"},{"identifier":6,"text":"Tuenti Sitios"},{"identifier":7,"text":"Agenda Tuenti"}],"presentationType":0}}
E/GeckoConsole(  949): Content JS WARN at app://settings.gaiamobile.org/js/icc_cache.js:21 in debug: [DEBUG] STKCACHE: STK_CMD_SET_UP_MENU:{"title":"SIM Tuenti","items":[{"identifier":1,"text":"Consulta saldo"},{"identifier":2,"text":"Recarga"},{"identifier":3,"text":"Bono"},{"identifier":4,"text":"Att cliente"},{"identifier":5,"text":"Tuenti Movil"},{"identifier":6,"text":"Tuenti Sitios"},{"identifier":7,"text":"Agenda Tuenti"}],"presentationType":0}


Since settings is not opened, this messages were lost !
Comment on attachment 685087 [details]
Patch which cache the data without loading all settings app and shows the correct STK menu entry correctly (cache in system version)

I made some comments on github. Close though!
Attachment #685087 - Flags: review?(21) → review-
Comment on attachment 685087 [details]
Patch which cache the data without loading all settings app and shows the correct STK menu entry correctly (cache in system version)

Github comments applied.
Attachment #685087 - Flags: review- → review?(21)
Landed: https://github.com/mozilla-b2g/gaia/commit/9c4387f1568a2a90c0319d590f894890afa21d33
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: General → Gaia
Defect is verified as fixed on the Unagi device, using build 20130114073222
Status: RESOLVED → VERIFIED
I have I think a related issue where the STK is opened automatically after 2 seconds when opening the Settings app. See Bug 869429
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: