I'm developing an application that has feature which involves sending data over bluetooth. I've tested sending data with GameKit framework and it works fine. My question is "Is that correct way to go?" or should I use some other way of transporting data over bluetooth?
An additional question: when I'm sending data, both devices (one sending and one receiving) have to init GKPeerPickerController and show it. Is there a way for receiver to get notification for connection without calling GKPeerPickerController, so that sender can send a file and receiver can just confirm he wants to receive file (without looking for sender aka showing GKPeerPickerController)?
Tnx,
Mario
You can use GKSession class and its delegate protocol to handle peer to peer connection programmatically and implement your own views.
Related
I've got a strange problem using CoreBluetooth on Mac mini. By design, my code should receive a data update notification after discovering a characteristics service once it's connected. The problem is no data will be updated if a event is triggered by hardware within very first 20 seconds.
I've test the same code in the iOS,but it all works fine without any dealy. So the question is:
Does Apple delay the -[didUpdateValueForCharacteristic:] notification after first BLE connection?
In addition, I am using a custom profile ( A self defined UUID).
Thanks.
According to documentation:
This method is invoked when your app calls the
readValueForCharacteristic: method, or when the peripheral notifies
your app that the value of the characteristic for which notifications
and indications are enabled (via a successful call to
setNotifyValue:forCharacteristic:) has changed.
So no, it's not guaranteed that this method will be called after discovering a characteristic. You either have to call readValueForCharacteristic or subscribe to notifications and wait until peripheral sends a notification.
However, after discovering a characteristic, you can get its value in peripheral:didDiscoverCharacteristicsForService:error: method.
I know that push notifications are being sent from a backend server. Is it possible to send notification from client itself? My application goes like this: It acquires its position using Location services API. once it enters a specific circle, the trigger calls a callback function. What i want to do is to use the callback function to push a notification to the device. Is there any way to do this?
Thank you very much in advance!
If you just want a notification when the app is active in the background, you can use local notifications: https://github.com/katzer/cordova-plugin-local-notifications. The plug-in Javascript has to be modified somewhat to work with a Worklight app, but with some simple modifications it works great, and allows your app running in the background to raise a notification without going through the server side round trip involved when using push.
That said, I implemented an app that did exactly what you are looking for (in my case, I needed some server side processing to figure out what the text of the push message should be) The geo-fence callback called an adapter, providing it with event details and the device ID. The adapter determined what message to send, and used unicast push to send it back to the device.
You can invoke a procedure in the client side. I tried to invoke in the client side with httpAdapter and its working.
If the notification doesn't need to come from the server, you can also create a service that will run in the background and show a dialogbox once it enters the geofence.
I have a project coming up where I need to send and receive messages through a specific mobile operator, which only provides an SMPP interface. The whole project will be a hosted website. I have already read quite a lot, but I do not yet quite understand what is actually needed from my side to use the protocol.
Should my application try to maintain a constant connection to the smpp?
Can I simply connect, send a message and then disconnect?
Are receiving messages based on push or pull?
Thanks for the help.
SMPP is a peer-to-peer protocol. That should mean that SMS Gateway (your side) and SMSC (your mobile operator) need to have a proper bind/connection established. Even when there are no SMS or DLRs to send/receive, there is a continous exchange of smpp PDU (enquire_link/enquire-link_resp) that ensure that the bind is established.
In detail, if you send an enquire_link PDU and you get no response (enquire_link_resp) the bind is broken. Your sms won't be delivered (will remain enqueued in your gateway store), and you won't receive MOs (incoming sms) or DLRs (delivery report). To re-establish the connection you should re-initiate the connection.
So, my answer would be that you need a constant connection to SMSC.
You are stating you want to receive messages, as a result at least a bind_receiver is needed. Because you don't know when messages are going to come in, you will have to be constantly connected, rather than disconnecting after each event.
With regards to your question about "push or pull" this depends on how you solve the first problem. If you can build a solution that is constantly connected, the result will be a push (the carrier will push it to you as soon as they receive the message). If (for some reason) you cannot maintain a constant connection, you'll end up building a pull mechanism. You'll connect to the carrier ever X seconds to see if they have a message waiting for you.
I do need to highlight 2 pitfalls though:
A number of carriers in the world, do not store or even accept messages if you are not connected, therefore, depending on which carrier you interact with, you might be forced to use a continuous connection.
Most carriers do not allow you to open and close connections in quick succession. Once you disconnect, you can not reconnect for a time frame of X seconds.
Therefore a constant connection is really the way to go. Alternatively, you can look into a company like Nexmo, which will provide you with a HTTP Call every time a message arrives.
I'm not sure which language your developing your application in, but if you use any of the popular languages (Java, PHP, Perl) there are modules out there that handle basic SMPP Connectivity for you. A quick google search for your language and "SMPP Client" will give you a list of references.
I'm reading Apple's documentation on using QTKit to capture streaming audio and video from input sources. I read that the central class QTCaptureSession handles the input and sends it to every possible output (QTCaptureOutput). The documentation lists six subclasses of QTCaptureOutput (e.g., QTCaptureMovieFileOutput).
I would like to create a subclass of QTCaptureOutput to write to an NSSocket so I could send the video stream over to another machine.
Any ideas would be appreciated.
QTCaptureOutput does not strike me as a class designed to be subclassed outside of QTKit. Instead, you can try dumping the data to a local domain socket in the file system using a QTCaptureFileOutput object, and simultaneously pulling the data from that local domain socket and sending it over to the remote machine.
How to Read SMS/MMS in UIQ ?
I am going to assume that you want information about how to write some C++ source code that will allow an application to receive SMS/MMS and read the content of the messages it receives.
On Symbian OS, the message store can store SMS, MMS, EMAIL...
The API of the message store is generic.
In order to write and read data to/from the message store, you'll need to familiarise yourself with the following classes : TMsvId, CMsvSession, CClientMtmRegistry, TMsvEntry and CMsvEntry.
I am obviously biased but I would advise reading the messaging chapter of http://www.quickrecipesonsymbianos.com in order to get an explanation of how the messaging store works and the sample code to use it easily.
Receiving messages, on the other hand, is more complicated.
Listening for and receiving SMS is done using the generic networking API. That's RSocketServ and RSocket. Mostly, you need to use to the right IOCTL parameters on the socket.
You can specify a specific port in order to only receive SMS that are intended for your application. Trying to receive all SMS could be an issue as the native message viewer engine and the embedded Java virtual machine PushRegistry module could both be listening for all SMS already.
You will find useful classes and constants in the following header files in your SDK:
gsmuset.h smsuaddr.h smsustrm.h gsmubuf.h gsmumsg.h.
TSmsAddr, KSMSDatagramProtocol, KSMSAddrFamily, TSmsUserDataSettings, CSmsBufferBase, CSmsPDU, RSmsSocketReadStream, RSmsSocketWriteStream and CSmsMessage are of particular interest. Asynchronously receiving an SMS is actually done using RSocket.Ioctl().
There are SMS-specific error codes whose names start with "KSmsErr"
Receiving MMS on UIQ is done through a UQI-specific API. One that you won't find on Series60 phones. This is the reason why you won't find much talk of a Symbian-generic MMS API in the litterature. You are better off going directly to the UIQ or Sony-Ericsson development communities when you have more detailled questions.
Your application shouldn't have to use RSocket to receive MMS.
Careful, once again, both the Embedded Java virtual machine PushRegistry module and the native message viewer application engine are probably already listening for all incoming MMS messages.
The interesting header files are mmsclient.h, MmsSettingsStore.h, mmsentry.h, MmsApiExtensions.h
Of particular interest are CMmsClientMtm, MmsApiExtensions, MMsvSessionObserver and MMMSMessageHandler.
Good luck.