Closed Bug 1130332 Opened 11 years ago Closed 8 years ago

[Telephony] Retrieve telephony call inforamtion in a synchronized approach

Categories

(Firefox OS Graveyard :: RIL, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED WONTFIX
tracking-b2g backlog

People

(Reporter: aknow, Unassigned)

References

Details

Attachments

(6 files, 1 obsolete file)

As mentioned in Bug 1128823 Comment 2
Summary: [Telephony] Use callback for nsITelephonyService.enumerateCalls instead of nsITelephonyListener → [Telephony] Use callback for nsITelephonyService.enumerateCalls
Blocks: 1000485
Assignee: nobody → bhsu
[Tracking Requested - why for this release]:
Blocks: 1061089
Hi Aknow, The link below is the my WIP branch, since there are too many commits, do you mind having a quick review on github first. After we reach a consensus, I'll merge those commits into bigger patches which are easier to manage. https://github.com/driftersprt/gecko-dev/commits/1130332
Flags: needinfo?(szchen)
(In reply to Ben Hsu [:bhsu] from comment #3) > Hi Aknow, > > The link below is the my WIP branch, since there are too many commits, do > you mind having a quick review on github first. After we reach a consensus, > I'll merge those commits into bigger patches which are easier to manage. > > https://github.com/driftersprt/gecko-dev/commits/1130332 Please see my comments on github
Flags: needinfo?(szchen)
Ben, The patches in bug 1162426 use enumerateCallState. You'll need to change it as well after the patches land on master.
After an offline discussion, we decide to deprecate nsITelephonyService::enumerateCalls, since the method complicates the architecture of its callers to handle the async responeses. On the other hand, using a callback might make things better, but this approach makes the inheritance hierarchy of telephony callbacks become much more complex. Thus, we decide to use a sync approach to get the call information for Telephony Service, which makes the caller become simpler and keeps the clear inheritance hierarchy of telephony callbacks.
Summary: [Telephony] Use callback for nsITelephonyService.enumerateCalls → [Telephony] Retrieve telephony call inforamtion in a synchronized approach
Attachment #8676925 - Flags: review?(btseng)
Attachment #8676926 - Flags: review?(btseng)
Attachment #8676929 - Flags: review?(btseng)
Attachment #8676936 - Flags: review?(btseng)
Comment on attachment 8676925 [details] [diff] [review] Part 1: Move to nsITelephonyService::getCurrentCalls() (IDL) Review of attachment 8676925 [details] [diff] [review]: ----------------------------------------------------------------- r=me with the nit addressed. ::: dom/telephony/nsITelephonyService.idl @@ +167,5 @@ > void unregisterListener(in nsITelephonyListener listener); > > /** > + * Via this method, the caller can retrieve the information of every existing > + * call from Telephony Service. Nit: Just simplify this description to "Retrieve the information of existing calls."
Attachment #8676925 - Flags: review?(btseng) → review+
Comment on attachment 8676926 [details] [diff] [review] Part 2: Move to nsITelephonyService::getCurrentCalls() (Telephony) Review of attachment 8676926 [details] [diff] [review]: ----------------------------------------------------------------- Please see my comment below. ::: dom/telephony/Telephony.cpp @@ +107,5 @@ > return nullptr; > } > > + // Create a Telephony DOM object > + RefPtr<Telephony> telephony = new Telephony(aOwner); we should ensure that the telephonyService is available before creating a Telephony DOM object. @@ +156,5 @@ > + if (erv.Failed()) { > + aRv.Throw(erv.StealNSResult()); > + return nullptr; > + } > + telephony->mReadyPromise->MaybeResolve(JS::UndefinedHandleValue); Do we still need mReadyPromise here? Why don't we just reply a resolved Promise in Telephony::GetReady() since all callinfo will be retrieved in synchronized way? We could file a bug to deprecate |Telephony.ready| from webidl in the future.
Attachment #8676926 - Flags: review?(btseng)
Comment on attachment 8676929 [details] [diff] [review] Part 4: Move to nsITelephonyService::getCurrentCalls() (RIL) Review of attachment 8676929 [details] [diff] [review]: ----------------------------------------------------------------- Please see my comment below. Thanks! ::: dom/system/gonk/RadioInterfaceLayer.js @@ +254,5 @@ > // for more details). Therefore we should hangup all active voice calls > // first. And considering some DSDS architecture, toggling one radio may > // toggle both, so we send hangUpAll to all clients. > + let calls = {}; > + gTelephonyService.getCurrentCalls(calls); let calls = gTelephonyService.getCurrentCalls(); @@ +255,5 @@ > // first. And considering some DSDS architecture, toggling one radio may > // toggle both, so we send hangUpAll to all clients. > + let calls = {}; > + gTelephonyService.getCurrentCalls(calls); > + calls.value.forEach(function(aCall) { calls.forEach(...)
Attachment #8676929 - Flags: review?(btseng)
Comment on attachment 8676936 [details] [diff] [review] Part 3: Move to nsITelephonyService::getCurrentCalls() (Telephony-IPC) Review of attachment 8676936 [details] [diff] [review]: ----------------------------------------------------------------- Please see my comments below. Thanks! ::: dom/telephony/ipc/TelephonyIPCService.cpp @@ +180,5 @@ > + nsCOMPtr<nsITelephonyCallInfo> info = dont_AddRef(allInfo[i]); > + results.AppendElement(info); > + } > + > + results.Forget(aAllInfo); We suppose to allocate nsITelephonyCallInfo* array for aAllInfo and to be free by caller like Telephony.ccp, don't we?
Attachment #8676936 - Flags: review?(btseng)
Comment on attachment 8676936 [details] [diff] [review] Part 3: Move to nsITelephonyService::getCurrentCalls() (Telephony-IPC) Review of attachment 8676936 [details] [diff] [review]: ----------------------------------------------------------------- r+ per comment below. ::: dom/telephony/ipc/TelephonyIPCService.cpp @@ +180,5 @@ > + nsCOMPtr<nsITelephonyCallInfo> info = dont_AddRef(allInfo[i]); > + results.AppendElement(info); > + } > + > + results.Forget(aAllInfo); Per offlined discussion, the allocation has been done in nsCOMArray::Forget().
Attachment #8676936 - Flags: review+
Assignee: bhsu → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: