Closed Bug 799851 Opened 12 years ago Closed 12 years ago

B2G STKUI: Support Proactive command 'SET UP EVENT LIST'

Categories

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

x86
Linux
defect

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
blocking-basecamp +

People

(Reporter: frsela, Assigned: frsela)

References

()

Details

(Whiteboard: QARegressExclude)

Attachments

(1 file, 1 obsolete file)

Implement the required top level features (on STKUI) in order to support STK Events.
Assignee: nobody → frsela
blocking-basecamp: --- → ?
Depends on: 790543
This is a feature bug and not stabilization work. We should only take this if we can't ship the product without it and in that case we should also surface Stk as not feature complete and identify the remaining work.
(In reply to Andreas Gal :gal from comment #1) > This is a feature bug and not stabilization work. We should only take this > if we can't ship the product without it and in that case we should also > surface Stk as not feature complete and identify the remaining work. STK is a must for VIVO as they already have a number of applications we need to support. We already landed some of the functionality related to STK, and we need to continue with the process. Besides, this task exposes what is being implemented in platform task https://bugzilla.mozilla.org/show_bug.cgi?id=790543 that is blocking-basecamp+. If we do not implement this gaia task, platform task is useless.
(In reply to Andreas Gal :gal from comment #1) > Stk as not feature complete and identify the remaining work. Since this started before the move to bugzilla, Yoshi and me had the list of issues in my Github account: https://github.com/frsela/gaia/issues
(In reply to Andreas Gal :gal from comment #1) > This is a feature bug and not stabilization work. We should only take this > if we can't ship the product without it and in that case we should also > surface Stk as not feature complete and identify the remaining work. We were on Brasil last week to properly implement this functionality and UX with Yoshi and the operator support. This is a important feature, that was the reason of the trip. The trip was delayed because of several reasons that is why we could not make this improvements in advance. Please change this bug to blocking-basecamp+.
blocking-basecamp: ? → +
Priority: -- → P1
This patch didn't work on Otoro so Faked method is added for allow us continue working NOTE: If blocking-basecamp+ is set, just land it for now. [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Testing completed: Risk to taking this patch (and alternatives if risky):
Attachment #671823 - Flags: approval-gaia-master?(21)
Blocking-basecamp+, you don't need my approval. You still need a review though :)
Comment on attachment 671823 [details] [diff] [review] Patch to supoprt Events registration Oh! thats true :) well... a r? is going to you :)
Attachment #671823 - Flags: review?(21)
Comment on attachment 671823 [details] [diff] [review] Patch to supoprt Events registration Review of attachment 671823 [details] [diff] [review]: ----------------------------------------------------------------- ::: apps/settings/js/icc.js @@ +82,5 @@ > + icc.STK_EVENT_TYPE_LOCAL_CONNECTION, > + icc.STK_EVENT_TYPE_NETWORK_SEARCH_MODE_CHANGED, > + icc.STK_EVENT_TYPE_BROWSING_STATUS, > + icc.STK_EVENT_TYPE_FRAMES_INFORMATION_CHANGED]); > + } This is very unclear why you need that. If this is debug only I would live that out of the PR and you may want to write a mochitests instead. @@ +227,5 @@ > + * Process STK Events > + */ > + function processSTKEvents(eventList) { > + for (var evt in eventList) { > + debug(' STK Registering event: ' + JSON.stringify(eventList[evt])); JSON.stringify would be called even if you're not in debug mode. You may want to use the debug done by kaze.
Attachment #671823 - Flags: review?(21) → review-
(In reply to Vivien Nicolas (:vingtetun) from comment #9) > Comment on attachment 671823 [details] [diff] [review] > Patch to supoprt Events registration > > Review of attachment 671823 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: apps/settings/js/icc.js > @@ +82,5 @@ > > + icc.STK_EVENT_TYPE_LOCAL_CONNECTION, > > + icc.STK_EVENT_TYPE_NETWORK_SEARCH_MODE_CHANGED, > > + icc.STK_EVENT_TYPE_BROWSING_STATUS, > > + icc.STK_EVENT_TYPE_FRAMES_INFORMATION_CHANGED]); > > + } > > This is very unclear why you need that. If this is debug only I would live > that out of the PR and you may want to write a mochitests instead. > Well, this FAKE approach is because nowadays Otoro handsets didn't support STK Events but Galaxy SII support them so the implementation should be different on each of them ... We're talking with manufacturer to solve this. With out FAKE events we cann't test the patches on bug #800264 I can remove this, but how to proceed? a different patch on #800264 for add the fake registration? > @@ +227,5 @@ > > + * Process STK Events > > + */ > > + function processSTKEvents(eventList) { > > + for (var evt in eventList) { > > + debug(' STK Registering event: ' + JSON.stringify(eventList[evt])); > > JSON.stringify would be called even if you're not in debug mode. You may > want to use the debug done by kaze. Yeap, on rebase I forgot to change this one ...
Rebased and removed FAKE registration
Attachment #671823 - Attachment is obsolete: true
Attachment #672297 - Flags: review?(21)
Whiteboard: QARegressExclude
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: