Tp::Service::ChannelInterfaceSMSAdaptor Class Reference

| Home · All Classes · All Namespaces · Modules · Functions · Files

Public Slots | Signals | Public Member Functions | List of all members
Tp::Service::ChannelInterfaceSMSAdaptor Class Reference
Channel service implementation

`#include <TelepathyQt/_gen/svc-channel.h>`

Inherits Tp::AbstractAdaptor.

## Public Slots
uint | GetSMSLength (const Tp::MessagePartList &message, const QDBusMessage &dbusMessage, int &remainingCharacters, int &estimatedCost)

## Signals
void | SMSChannelChanged (bool SMSChannel)

## Public Member Functions
bool | Flash () const
bool | SMSChannel () const
Public Member Functions inherited from Tp::AbstractAdaptor
| AbstractAdaptor (const QDBusConnection &connection, QObject *adaptee, QObject *parent)
| ~AbstractAdaptor ()
QDBusConnection | dbusConnection () const
QObject * | adaptee () const

## Detailed Description

Adaptor class providing a 1:1 mapping of the D-Bus interface "org.freedesktop.Telepathy.Channel.Interface.SMS".

## Member Function Documentation

bool Tp::Service::ChannelInterfaceSMSAdaptor::Flash | ( |  | ) | const

Return the value of the exported D-Bus object property `Flash` of type `bool`.

Adaptees should export this property as a Qt property named 'flash' with type bool.

If `True`, then this channel is exclusively for receiving class 0 SMSes (and no SMSes can be sent using ChannelInterfaceMessagesInterface::SendMessage() on this channel). If `False`, no incoming class 0 SMSes will appear on this channel.

This property is immutable (cannot change), and therefore SHOULD appear wherever immutable properties are reported, e.g. ConnectionInterfaceRequestsInterface::NewChannels() signals.

Class 0 SMSes should be displayed immediately to the user, and need not be saved to the device memory unless the user explicitly chooses to do so. This is unlike “normal”, class 1 SMSes, which must be stored, but need not be shown immediately in their entirity to the user.

Separating class 0 SMSes into their own channel with this immutable property allows them to be dispatched to a different ClientHandlerInterface —which would include this property in its ClientHandlerInterface::HandlerChannelFilter —avoiding the normal Text channel handler having to decide for each message whether it should be displayed to the user immediately or handled normally.

Currently, no mechanism is defined for sending class 0 SMSes. It seems reasonable to support specifying the class of an outgoing SMS in its header Message_Part, rather than requiring the UI to request a special channel for such SMSes; hence, we define here that channels with Flash set to `True` are read-only.

Returns
  The value of exported property `Flash`.

bool Tp::Service::ChannelInterfaceSMSAdaptor::SMSChannel | ( |  | ) | const

Return the value of the exported D-Bus object property `SMSChannel` of type `bool`.

Adaptees should export this property as a Qt property named 'smsChannel' with type bool.

If TRUE, messages sent and received on this channel are transmitted via SMS.

If this property is included in the channel request, the Connection Manager MUST return an appropriate channel (i.e. if TRUE the channel must be for SMSes, if FALSE it must not), or else fail to provide the requested channel with the NotCapable error.

For example, to explicitly request an SMS channel to a contact. You might construct a channel request like:

>     {
>       Channel.Type: Channel.Type.Text,
>       Channel.TargetHandleType: Handle_Type_Contact,
>       Channel.TargetID: escher.cat,
>       Channel.Interface.SMS.SMSChannel: True,
>     }

Some protocols allow us to send SMSes to a remote contact, without knowing the phone number to which those SMSes will be sent. This provides a mechanism to request such channels.

If this property is not included in the channel request, the Connection Manager MAY return an SMS channel if that is the most appropriate medium (i.e. if the channel target is a phone number).

To some types of identifiers (i.e. phone numbers) it only makes sense to return an SMS channel, this is what happens currently with telepathy-ring. We don't want to break this behaviour when we are not explicit about the type of channel we want. Alternatively, for protocols where there is an SMS fallback for IM messages, it's possible that we don't care what sort of channel we get, and simply want notification of the transport.

Some protocols have a fallback to deliver IM messages via SMS. On these protocols, the Connection Manager SHOULD set the property value as appropriate, and notify its change with SMSChannelChanged() .

Protocols such as MSN can fall back to delivering IM messages via SMS. Where possible we want clients to be able to inform the user that their messages are going to be redirected to the remote contact's phone.

Returns
  The value of exported property `SMSChannel`.

uint Tp::Service::ChannelInterfaceSMSAdaptor::GetSMSLength | ( | const Tp::MessagePartList & | message,
|  | const QDBusMessage & | dbusMessage,
|  | int & | remainingCharacters,
|  | int & | estimatedCost
| ) |  |
| slot

Begins a call to the exported D-Bus method `GetSMSLength` on this object.

Adaptees should export this method as a Qt slot with the following signature: void getSMSLength(const Tp::MessagePartList& message, const Tp::Service::ChannelInterfaceSMSAdaptor::GetSMSLengthContextPtr &context);

Implementations should call MethodInvocationContext::setFinished (or setFinishedWithError accordingly) on the received context object once the method has finished processing.

Returns the number of 140 octet chunks required to send a message via SMS, as well as the number of remaining characters available in the final chunk and, if possible, an estimate of the cost.

There are a number of different SMS encoding mechanisms, and the client doesn't know which mechanisms an individual CM might support. This method allows the client, without any knowledge of the encoding mechanism, to provide length details to the user.

Clients SHOULD limit the frequency with which this method is called and SHOULD NOT call it for every keystroke. Clients MAY estimate the remaining size between single keystrokes.

Parameters

  message |
      The message the user wishes to send.
  remainingCharacters | Output parameter

The number of further characters that can be fit in the final chunk. A negative value indicates that the message will be truncated by `abs(Remaining_Characters)`. The value `MIN_INT32` (`-231`) indicates the message will be truncated by an unknown amount.

For example, in the GSM standard 7-bit encoding, a 162 character message would return 144 remaining characters (because of the space required for the multipart SMS header).

Parameters

  estimatedCost | Output parameter

The estimated cost of sending this message. The currency and scale of this value are the same as the \\\ \\link ConnectionInterfaceBalanceInterface::requestPropertyAccountBalance() ConnectionInterfaceBalanceInterface::AccountBalance \\endlink \\htmlonly property.

A value of `-1` indicates the cost could not be estimated.

Returns

The number of 140 octet chunks required to send this message.

For example, in the GSM standard 7-bit encoding, a 162 character message would require 2 chunks.

void Tp::Service::ChannelInterfaceSMSAdaptor::SMSChannelChanged | ( | bool | SMSChannel | ) |
| signal

Represents the exported D-Bus signal `SMSChannelChanged` on this object.

Adaptees should export this signal as a Qt signal with the following signature: void smsChannelChanged(bool SMSChannel);

The adaptee signal will be automatically relayed as a D-Bus signal once emitted.

Parameters

  SMSChannel |
      The new value for SMSChannel.