Re: change proposal for Telephony API

On 2013¦~04¤ë18¤é 17:16, Kis, Zoltan wrote:
> Hi Hsin-Yi,
>
> Thank you for looking through the proposal.
>
> On Thu, Apr 18, 2013 at 11:58 AM, Hsin-Yi Tsai <htsai@mozilla.com> wrote:
>> I am not sure I got a clear difference between the interfaces
>> TelephonyManager and TelephonyService. I am a little confused at the purpose
>> and definition of TelephonyManager in this proposal. For example, I am
>> wondering shouldn't onincoming and oncallschanged be exposed on
>> TelephonyService since we can't receive any calls without telephony service,
>> and since you propose a separate API for that service. It seems not
>> intuitive to me that we use TelephonyService to make an outgoing call but
>> receive incoming calls via TelephonyManager.
> In telephony domain all the incoming calls should be handled by one
> object, since only one call will get resources (e.g. audio, video), so
> arbitration is needed - as opposed to messaging, where each messaging
> service can independently receive messages.
>
> For dialed calls, the given service can be used, or by enumerating the
> services through the manager and using them.

Hi Zoltan,

Agree that in terms of arbitration, we need calls being handled by one
object; however that doesn't necessarily imply that TelephonyManager
should be that object nor that we should dispatch incoming events to
TelephonyManager, unless you are talking about letting app handle
arbitration. Otherwise, IMHO arbitration is implementation issue. And
since the position of TelephonyService object is to provide telephony
service, I still think that user should be able to receive incoming
calls via TelephonyService object. It looks incomplete and inconsistent
that a service object provides functionality for outgoing calls only,
excluding incoming calls.

>> Also, shouldn't each telephony service contain its calls?
> It could, but not much use. The dialer is interested to resynchronize
> itself with the list of current calls on startup (since perhaps it has
> crashed). This is easier to do with one call list, then to list all
> services, then list all calls from them. The calls themselves can be
> managed by their TelephonyCall or ConferenceCall  objects, and they
> keep track on which service they are (by the serviceId).

I am not sure if it is expected behaviour that calls are provided by a
service but user cannot get the calls via the corresponding service
object. I am not against having one call list in the manager object;
contrarily, it could be more user-friendly with one call list exposing
to the manager object I believe. However, I feel if we want to have a
separate object for each service, then the service object shall behave
more naturally, as it is a real service, even having separate service
objects might lead to some incapability of exposing central information
or lead to acceptable cost to implementation. The proposal right now
seems not natural enough IMHO.

Best regards,
Hsinyi

-- 
Hsin-Yi Tsai ½²ªY©y
Mozilla Taiwan
T: +886-2-87861100 ext:312
htsai@mozilla.com

Received on Monday, 22 April 2013 03:43:27 UTC