1048680 - [Telephony] listen to 'ready' event to notice the initialization of telephony object

Status: RESOLVED FIXED

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

Description

[Szu-Yu Chen [:aknow] (inactive)]

Previously, we abuse 'callschanged' event to indicate that the telephony object is fully initialized. Now we have a specific event 'ready' for the purpose. Please change the usage in current gaia.

Don't worry about the timing you register the event listener. 

1. If the telephony is not ready, the listener will receive 'ready' event as soon as the telephony finishes the initialization.

2. If the telephony is ready, the listener will receive the event immediately after the registration.

Note:
It's possible for one listener to receive multiple times of 'ready' event. Because everytime a new listener is registered, we have to guarantee the 'ready' event will be fired and this event will be broadcast to all the listeners.

Comment 1

[Anthony Ricaud (:rik)]

I can't find any reference to callschanged in the Dialer app. The only references I see are in the Callscreen and they are used for real callschanged work. Do you have any use case where we should be using it?

Comment 2

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Anthony Ricaud (:rik) from comment #1)
> I can't find any reference to callschanged in the Dialer app. The only
> references I see are in the Callscreen and they are used for real
> callschanged work. Do you have any use case where we should be using it?

Using "callschanged" for ready is introduced in Bug 823958. I checked the bugs which are blocked by it. Some of them indeed use the event for the ready purpose at that time. However, the architecture is totally different now and all the changes are not valid at this moment...

Also, there are some reference in system app but I can't find anyone which needs change...

Well... I think all the gaia apps use 'callschanged' really "well". The codes are optimized for the current behavior of 'callschanged'. They handle both "ready" and real "callschanged" at the same place. So we can't find a point that could be easily replaced by "ready" event.

The reason why we introduce "ready" event is that in original design, the app is possible to receive "callschanged" when there is no changes actually. This might lead to some problem, for example, layer order in window manager.

Comment 3

[Szu-Yu Chen [:aknow] (inactive)]

Will it better to distinguish the use of "ready" and "callschanged"? Then in gecko, we don't have to fire dummy "callschanged" event when there is no changes.

Comment 4

[Anthony Ricaud (:rik)]

We could distinguish them in Gaia but from a quick grep, I can't see a case that would benefit from this.

Comment 5

[Szu-Yu Chen [:aknow] (inactive)]

OK, just keep it unchanged.

Comment 6

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: should wait telephony ready

Comment 7

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: should wait telephony ready

Just attached the wrong file. This one is correct.

Comment 8

[Szu-Yu Chen [:aknow] (inactive)]

I got a use case when working on Bug 1061210.

Let me briefly summarize the scenario of that bug:
1. make two call
2. merge them into a conference
3. back to home menu, remove dialer app from card view
4. open dialer again and make a new call

Expect:
Gaia should notice that there is an active call (conference). So, it should hold it before dialing out the new one.

Please see my fix in attachment 8483352 [details] [diff] [review]
|telephony.calls| and |telephony.active| should only be access after telephony object is initialized (by ready event). Otherwise, the value of them are not correct.

Comment 9

[Anthony Ricaud (:rik)]

That sounds like a reasonable use. Worst case scenario, how long can this initialisation take? If it's more than 500ms, we may want to show some feedback to the user that we registered the request.

Comment 10

[Szu-Yu Chen [:aknow] (inactive)]

Well... I found that the user case here is not an urgent one. Current gecko also has limit check and could hold the call automatically.

So, I'd prefer to see whether it is possible to have an ultimate solution:  returning an already initiated telephony object (Bug 986333). This may require a sync ipc message between content and chrome. That means the number of message exchanged should also be optimized (Bug 1061089) thus it won't take too much time.

Comment 12

[Doug Sherk (:drs) (inactive)]

This doesn't seem to be an issue anymore since bug 1081811 landed.