Closed Bug 1128891 Opened 10 years ago Closed 10 years ago

[B2G] Attach the telephony object to the specific window

Categories

(Firefox OS Graveyard :: AudioChannel, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1129882

People

(Reporter: alwu, Assigned: alwu)

References

Details

Attachments

(1 file, 1 obsolete file)

In the new audio channel architecture, we create a new interface, BrowserElementAudioChannel, which can be used to control audio channel directly.

The usage way is to get the specific iframe first, then you can access its audio channel by the new interface.

However, the telephony is a special case. It doesn't belong to anyone, so we don't have method to access it. 

What we want to do is to attach telephony object on the specific window. The system can manage it by accessing the child window.

Therefore, we will expose a new function from nsIAudioManager. The TelephonyService could use it to pass the reference of the specific window.
Assignee: nobody → alwu
Depends on: 1113086
Hi, Baku,
The question we faced is that if the agent don't have a window, we can't find the specific window data by the window ID. And you suggested me to add an agent in the telephony.

I have an idea for this situation. 
Could I move the telephony data out of |mWindow|, then create a |AudioChannelConfig| to save it? 
Because the telephony object is unique, every time we want to modify the telephony data, we could access this config directly without using the window ID to find the specific window data.

I want to do that is because I don't want to modify the telephony service. If we add an agent on there, the gaia developers also need to change something for fitting our design. (They need to send a window to us, tell the agent who is using the telephony)

How do you think?
If there are any mistakes, please correct me :)
Thanks a lots!!!!!
Flags: needinfo?(amarchesini)
I found my idea is totally unworkable, I'm very very sorry!
If the agent don't bind to a window, we can't send the event "audiochannel-activity-active" correctly to the BrowserElementAudioChannel!

So I have another idea, that is passing the window parameter to the BrowserElement when we check its manifest. If the apps have both "telephony" and "audio-channel-telephony", then we send its window to the AudioManager. This window can be used, when the telephony audio agent is created in the |AudioManager::setPhoneState()|.

I think it could be a better solution (and I hope so...:( )

-----

And let me describe more details about why I don't want to create a agent on the Telephony.idl.

(1) The app developer need to send a window to Gecko. I discuss this with Evan, he says that sounds not well. They never use a window as a parameter.

(2) If we implement (1), that means we mixed the telephony logic with its app logic. It is also not a good thing.

-----

Hope you could give me some suggestions,
Very appreciate!!!
Flags: needinfo?(amarchesini)
Sorry!
Seems the flag is not set correctly, so reset the "ni" again.
Flags: needinfo?(amarchesini)
WIP. The concept of this patch is on the Comment2.
Question for you. Can we add AudioChannelAgent in the TelephonyCall object?
I didn't read all the code of Telephony API, but it seems to me that when an app makes a telephony call it has a TelephonyCall object.

Then, second question: What do you mean with: "the app developer needs to send a window to Gecko". why?
If telephony has an AudioChannelAgent, the agent knows how to speak with the AudioChannelService.
Is it not enough?

If you prefer we can do a meeting this week and find a solution together.
Flags: needinfo?(amarchesini) → needinfo?(alwu)
Hi, Baku,
I was confused by some error concept before, but I think I have got what you means now.
I would close this bug, and open a new one to discuss "add an agent in the telephony object".
We could discuss more details on skype/IRC/Vidyo.
Thanks a lots :) !
Flags: needinfo?(alwu)
Update the latest version,
this patch could let the AudioChannelAgent know the correct window which is sent from the Browser Element.
Attachment #8559073 - Attachment is obsolete: true
We would have a better idea to solve this problem, but the new method is different with the present method.
In order to avoid people confused by previous discussions, so open another bug to discuss that.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: