Hi Andrew My means is : if current application do not open, but bluez is running, then bluez receive a pin code request or HF device connect signal, then bluez will send the signal like propertyChanged, But application do not open, which module will handle this signal and implement bluetooth update?
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Monday, January 17, 2011 2:09 PM > To: Zhang, Wen (Sky); [email protected]; > [email protected] > Cc: [email protected] > Subject: RE: TP1.2 bluetooth API > > I don't understand the question. What signal do you want to > receive from bluez? > > All the demo and example applications have a UI. That said, > the only requirement for Bluetooth to operate is a > functioning event loop. If you application does not have a > gui, then you have to ensure an operating event loop. > QCoreApplication::exec() will start the event loop or, I > cannot recommend this approach, you can call > QCoreApplication::procesEvents periodically. > > -Andrew > > > -----Original Message----- > From: ext Zhang, Wen (Sky) [mailto:[email protected]] > Sent: Monday, January 17, 2011 3:34 PM > To: Shin Minjung (Nokia-MS-Qt/Brisbane); [email protected] > Cc: Stanley-Jones Andrew (Nokia-MS/Brisbane); > [email protected] > Subject: RE: TP1.2 bluetooth API > > Hi Minjun > After study the bluetooth API code, and I want to know > qt-mobility have a service or daemo for bluetooth which run > on the background to receive the signal from blueZ? > > Thanks! > > > -----Original Message----- > > From: > > [email protected]. > > com > > [mailto:qt-mobility-feedback-bounces+wen.zhang=windriver.com@q > > t.nokia.com] On Behalf Of [email protected] > > Sent: Monday, January 17, 2011 12:48 PM > > To: [email protected] > > Cc: [email protected]; > [email protected] > > Subject: Re: [Qt-mobility-feedback] TP1.2 bluetooth API > > > > Hi Shane, > > > > Thank you very much for your feedback. > > > > The mailing list address has been changed from > > [email protected] to > > [email protected]. > > > > Regarding OBEX, we only provide a simple API to support > file transfer > > in 1.2. We are leveraging the platform OBEX implementation. i.e. we > > won't have a Qt API to fully implement OBEX specification. We will > > look at the extensibility again. > > > > Thanks again. > > > > Kind regards, > > Min > > > > -----Original Message----- > > From: ext [email protected] > > [mailto:[email protected]] > > Sent: Friday, 14 January 2011 11:06 PM > > To: Shin Minjung (Nokia-MS-Qt/Brisbane) > > Subject: FW: TP1.2 bluetooth API > > > > Hi Minjung, > > > > I posted this to the mailing list, but it didn't seem to arrive. > > A lot of these suggestions can be done after 1.2, but there > are some > > issues where the 1.2 API would be hard to maintain. > > > > The OBEX API in particular doesn't look ready for release, > as it looks > > hard to implement other obex operations within that framework. > > > > Best Regards, > > > > Shane Kearns > > > > -- > > Communications with Accenture or any of its group companies > > ("Accenture Group") including telephone calls and emails (including > > content), may be monitored by our systems for the purposes > of security > > and the assessment of internal compliance with company policy. > > Accenture Group does not accept service by e-mail of court > > proceedings, other processes or formal notices of any kind. > > > > Accenture means Accenture (UK) Limited (registered number 4757301), > > Accenture Technology Solutions Limited (registered number > 4442596), or > > Accenture HR Services Limited (registered number 3957974), all > > registered in England and Wales with registered addresses at 30 > > Fenchurch Street, London EC3M 3BD, as the case may be. > > > > > > -----Original Message----- > > From: Kearns, Shane > > Sent: Thursday, January 13, 2011 14:39 > > To: '[email protected]' > > Subject: TP1.2 bluetooth API > > > > Hi, > > > > I have some review comments on the APIs for Bluetooth in the > > 1.2 tech preview. > > My background is having debugged many of the S60 bluetooth > profiles, > > so there may be a symbian bias. I'm fairly familiar with > the bluetooth > > 2.x specifications but don't know how many of the optional features > > are currently implemented in bluez. > > > > The email is quite long, but broken down by class in the API. > > > > * QBluetooth::SecurityFlags > > > > I would expect to see some flags related to "man in the middle" > > protection levels here. > > These are used in Bluetooth 2.1 to determine what types of secure > > simple pairing are allowed. > > With the current API, the backend would need to pick a > default (which > > might prevent a bluetooth profile being implemented > according to spec > > if using Qt Mobility) On symbian, the equivalent is > > TBTAccessRequirementsMitmProtection > > > > If the backend is implemented on top of a pre 2.1 stack, it > can ignore > > these flags and only apply the BT1.0 flags you already > defined. (S60 > > 3.x has a 2.0 stack, S60 5.0 has a 2.1 stack) > > > > * QBluetoothDeviceDiscoveryAgent > > > > Quite OK, but the list of errors is inadequate. (unknown error for > > everything) "bluetooth is switched off" for example. > > > > Possible API extensions: > > There should be an option to skip name lookup (it's much faster, > > suitable for some non UI usage) > > (maybe) There should be an option to filter on class of device (not > > good to rely on, e.g. both a printer and a computer could offer the > > printing service) There should be an option to filter on > service uuid > > > > In the documentation you should warn people that the > > finished() signal could take minutes to come. (e.g. office > environment > > where everyone has a phone and PC with bluetooth > > discoverable) > > > > * QBluetoothDeviceInfo > > > > Needs a DataCompleteness function for the name (name > request can time > > out) > > majorDeviceClass() returns an enum, but that doesn't define all > > possible values. (major classes 9-30 are reserved but could be > > assigned at any time) I don't think > > manufacturerSpecificData() needs the bool pointer, as the > caller can > > use isEmpty() / isNull() on the QByteArray returned. > > > > * QBluetoothLocalDevice > > > > setHostMode and powerOn should be requests (power on can be > slow), and > > they can fail so you need a way to signal failure. > > The hostModeChanged signal can be used for success. > > Should there be a powerOff? or is setHostMode(0) sufficient? > > Should there be a setName? (which can also fail) If the device is > > connectable and discoverable, is the host mode 3 (as in the > HCI) or 2 > > (since being discoverable but not connectable is not > useful)? Either > > way doc needs clarification. > > > > * QBluetoothServiceDiscoveryAgent > > > > Since symbian's SAX style API was so hard to use and S60's API was > > broken, I'm sympathetic to this API returning complete service > > records. > > To avoid excessive memory use, make sure that it is > possible to call > > clear() from the serviceDiscovered() signal handler. > > The combination of all devices and full discovery is particularly > > dangerous. (although some bluetooth stacks stupidly require user > > intervention to allow connections to SDP so it will get > stuck in the > > tar pit in practice) > > > > Why is the bluetooth address a constructor parameter, but the uuid > > filter is a property? > > It would make sense to set bluetooth address in the same > way as uuid > > filter. > > > > * QBluetoothServiceInfo > > > > SDP data element sets can contain data element alternates and vice > > versa. > > The Alternative and Sequence inner classes contain lists of > QVariant, > > you don't appear to publish the integer user type for casting. > > is QVariant::canConvert<QBluetoothServiceInfo::Alternative>() > > and QVariant::value() sufficient for all cases? > > > > socketProtocol() should return an int, and the enum values > should be > > defined to match the bluetooth assigned numbers spec. (e.g. > > QBluetoothServiceInfo::L2capProtocol = 0x100 and > > QBluetoothServiceInfo::RfcommProtocol = 0x3). That way the > application > > can understand protocols that QBluetooth does not. > > > > can protocolServiceMultiplexer() and serverChannel() be > combined into > > a single API? The socketProtocol() tells you wha t protocol to use, > > and these are equivalent to the "port" > > in TCP or UDP sockets. > > > > It would be nice to have overloads of serviceName / > serviceDescription > > / ServiceProvider which take a QLocale::Language parameter > and return > > the language specific description if one is available. (In practice > > most services only have a primary language defined) > > > > * QBluetoothSocket > > > > There are way more errors than ConnectionRefusedError - > > PageTimeoutError,ServiceNotFoundError for example > > > > connectToService() needs overloads which take a > > QBluetooth::SecurityFlags The client as well as the server can > > initiate encryption (and this is mandatory for > qualification of some > > bluetooth profiles) The connectToService overloads which > takes a uuid > > or QBluetoothServiceInfo could result in either an RFCOMM or L2CAP > > socket being opened, so there needs to be some way of querying this > > after connected. (For example, OBEX can be implemented over both > > legacy RFCOMM and efficient L2CAP) > > > > For L2CAP sockets, you need a way to request an unreliable (flow > > control mode) connection, the default should be reliable > ([enhanced] > > retransmission mode or basic mode depending on stack capabilities). > > Unreliable connections are used for isochronous services such as > > audio. > > > > socket descriptors are not ints on symbian - if you hope > for that API > > to be usable to import/export sockets to native code, it > will probably > > only work on bluez backend. > > > > Deriving from QIODevice was the right decision for API consistency. > > > > * QBluetoothUuid > > > > The bool* ok=0 parameters are not very Qt like. > > I hope a qWarning is printed if conversion fails and ok is null > > pointer The user can call minimumSize first to know if the > conversion > > will succeed or not. > > > > * QL2CapServer and QRfCommServer > > > > Consistent with QTcpServer, which is good. > > > > Listen has a default port of 0, which presumably means > "auto assign a > > port and find out what was assigned by calling serverPort()" - this > > needs to be documented. Also need to document what the > default address > > means on a system with multiple bluetooth interfaces (which > you imply > > support for with this API and with > QBluetoothLocalDevice::allDevices) > > > > You should implement errorString() too, to give debug > information when > > a function fails (as in QTcpServer) > > > > * QBluetoothTransfer[*] > > > > Needs a lot more work to be useful. > > Consider how you would handle persistent OBEX connections > for profiles > > such as FTP, PBAP and MAP. > > More operations are needed such as SETPATH > > > > I think these need to be considered before releasing something that > > only works for limited OPP and may not be easily extensible > to other > > use cases. > > > > An OBEX server API is also needed, but could be separate from this > > client only API. > > > > btw, are you using the OS implementations of OBEX? > > > > > > Best Regards, > > > > Shane Kearns > > -- > > Communications with Accenture or any of its group companies > > ("Accenture Group") including telephone calls and emails (including > > content), may be monitored by our systems for the purposes > of security > > and the assessment of internal compliance with company policy. > > Accenture Group does not accept service by e-mail of court > > proceedings, other processes or formal notices of any kind. > > > > Accenture means Accenture (UK) Limited (registered number 4757301), > > Accenture Technology Solutions Limited (registered number > 4442596), or > > Accenture HR Services Limited (registered number 3957974), all > > registered in England and Wales with registered addresses at 30 > > Fenchurch Street, London EC3M 3BD, as the case may be. > > > > > > > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. If you > > have received it in error, please notify the sender immediately and > > delete the original. Any other use of the email by you is > prohibited. > > _______________________________________________ > > Qt-mobility-feedback mailing list > > [email protected] > > http://lists.qt.nokia.com/mailman/listinfo/qt-mobility-feedback > > > _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-mobility-feedback
