This is a specific question about implementing group messaging via the Signal Protocol.
After device 1 has sent a message encrypted with a sender key distribution message (SKDM) to many recipient devices, can each of the recipient devices use the same SKDM (that was generated by device 1) to encrypt its outgoing messages, or does it have to generate its own SKDM?
About a year ago, I asked this question on the Signal Community Forum here: https://whispersystems.discoursehosting.net/t/can-devices-share-sender-key-distribution-messages/1648, but nobody answered it.
No, each sending device ("sender") must create its own SKDM. Ie, it cannot use an SKDM that was generated by another device. Hence, "sender" is the first word of SKDM.
Related
My questions ..Development in IPHONE
consider two applications APP_A and APP_B..
APP_A wants to send message to APP_B and vice versa.... for communicating like this what is the best approach ...
the communication should be done ..
in watsapp the communication is done by members like . friend_1 and friend_2 sends msgs ..
like the same..but my requirement is one module in APP_A wants to send message to one Module in APP_B or vice versa...
can any one please tell me the best approach to do in IPHONE development
I am not certain what you are asking and what you mean by sending messages, but if you are talking about sharing data then you can use a shared pasteboard (from iOS 7) or shared keychain items. This is assuming that the apps are from the same developer.
If you are asking about opening another app, have a look at URL schemes.
I want to create an application which will be notified by server for new events. (lets say I have a shop and I need to inform all my iPhone users for my sales or something like this) Users who will download my application and run it and then put it in background wil have to be notified by this. Im quite new to iOS and Objective-C but if im not wrong this could be done via apple push notifications. Ive been reading about this and found out there are some providers that let you send this notifications. My question is, are there ways to create your own notification "center" in lets say c# and send notifications to iPhone-s by yourself, also if this could not be done are there any free providers?
and another thing. In objective-c app you have to subscribe your app to listen to that kind of events. Could you create app in phonegap or some other technologies so it will work with notifications? could you lets say embeed your app in objective-c (like web app in objective-c)
For sure you can do your own C# program that will push APNs to your clients (in fact I did that myself in many apps). What you have to understand is that the architecture of APN has 2 critical facts:
APNs are best effort, so no guarantee that they will reach every time.
APNs can not hold a lot of information with them when they reach your client (they have a limited number of bits, refer to the Apple documentation).
Due to these facts you might need to have your own server application (also could be in C#) that will handle sending the real information to the clients and will make sure that the data reached your client as well. Needless to say, this server application should sit and run on a real server. Maybe due to this fact some developers start looking for a third party solution, but personally I prefer not to use a third party and I do everything myself.
Other than having your own server application, your iPhone app will need to have some sort of database (probably SQLite3) to store the received news and display them later on.
EDIT: Answer of your questions in the comments below:
For the first question "why iPhone app must have sql db". In fact it is not a must, as I said in my answer above, it is probable or a possibility. To know if you will need a database or not this depends on the nature of your app itself. For example you might be pushing text and images to your clients and in that case you can not fit such data in the payload of the APN. Another possibility, you might want not to lose the sent notification even if the user discarded the APN message, you might want to show it again when he opens the app later on... So the nature of the app decides whether you will need a server or not.
For the second question "you said you dont need to send notification via third party", let me clarify something in my answer. As an Apple developer I don't consider Apple servers as third party. Put differently, the real APN will only be sent via Apple servers and we can not change this fact (nor do we want to change it too). So at the end of the day the real APN will be sent to Apple servers and Apple servers will work on delivering it to the actual client. What I consider a third party is someone that has his own server, you send the message you want to him, and then he sends it to Apple servers. In that case there is someone between you and the Appl APN servers and this is what I called a third party, and this third party can be avoided as your C# code can directly connect to the Apple APN servers and ask it to send the message to the client. I hope I clarified my point.
Yes, you can use APNS with the phonegap application: Receiving push notification on PhoneGap for iOS
Regarding the server, there is another option for you besides doing everything from scratch. You can use the third-party server via API, seems that pushwoosh (http://pushwoosh.com) guys offer this option (and they provide phonegap integration as well)
I'm working on a messaging app and I have a dilemma about how to send data from server to client.
I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients. So clients use a timer and query the server every 2 seconds to see if new data is waiting for them.
The problem with this approach is that polling the server every 2 second seem to kill the battery very fast, so I thought maybe instead of clients polling the server, to use APNS* so when the server has some new information ** for the client, the server will send a push notification *** to the client, then the client will fetch the data from the server.
* use APNS - if client allows it, client can of course disable this option. So I will check if push allowed every time the app enter foreground and if not I'll return to the polling approach.
** New information can be anything from text messages to server admin messages. (and there are a lot of admin messages...)
For example, in my app users can see their friends status (online/offline), so if user1 and user2 are friends, and user2 just change his status from online to offline, then server needs to send this new info (admin message = user2_offline) to user1.
*** The push notifications server sends are empty (with no data/sound), it's just a trigger for the client to fetch the new info, so if a push was sent to the client and the client app was close, he will not notice anything. (if the app is running, then it will fetched the new info from server)
Will this approach work with a massive messaging app requiring massive push notification uses?
To be clearer my main concerns are:
1. Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
2. Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
NO. Just for the sake of being complete let me iterate over the reasons.
Apple itself disclaims the reliability read the Programming Guide
Also, APNS, has a QoS component which may increase the reliability at the cost of being realtime (For Eg. I can ask APNS to deliver the notification anytime within 4 weeks and retry if devices are not reachable) which is not useful in your case.
As per your requirement, if you send a silent push (a push with no user visible message), it can not be sent as a HIGH priority push which decreases the reliability even further. Here is a relevant quote
"Silent notifications are not meant as a way to keep your app awake in
the background, nor are they meant for high priority updates. APNs
treats silent notifications as low priority and may throttle their
delivery altogether if the total number becomes excessive. The actual
limits are dynamic and can change based on conditions, but try not to
send more than a few notifications per hour."
Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Generally, APNS will not have any issues with this in terms of load, but it has throttling in place and they might throttle your notifications, see point 3 above
IMHO, you should look at XMPP as this protocol is designed just use-cases like yours and they have wide community support on all platforms. I will suggest you look at something like https://github.com/robbiehanson/XMPPFramework and setup an XMPP server at your backend which will handle the messaging and presence messages as well as admin messages.
If you have already evaluated XMPP and do not want to go with it, I would suggest you need to put together an intelligent system in iOS App which employs different strategies based on App State, something like following, you can have following strategies
A Realtime Socket based approach -> Establish a permanant socket connection and keep the data in sync as much as possible (This is when your app is running into foreground or background)
The Polling System You talked about in question, which can be utilised when your app is invoked for background fetch/location updates etc.
Use APNS with user visible messaging + custom data, when your server detects that the device does not have active socket and also have not polled for a very long time
I have worked in this area for a while and from my modest experience I think your approach to solve your problems will reach you nowhere. Allow me first to highlight some important facts on the APN characteristics:
APNs are not reliable, they are not 100% guaranteed to reach the client.
As of Apple's documentation, APNs are best effort, so many times they might not reach.
APNs don't hold data inside them, so even if they reach your client app they hold nothing inside them for the app.
APNs are just notifications for the user that something related to your app has occurred, while there message (the text that appears in the Alert Box of the APN) is handled by the iOS and not your app. This is why devices with iOS 4 will display the APN in a different way than devices with iOS 5, it is OS job not your app.
The badge value that appears on your app icon when notifications come is the responsibility of your server, and not the device OS. Put differently, when an APN reaches the device it should come having the new notification count value for your app. The OS won't do anything for this.
Having said that I would like to explain a bit how usually such applications are designed. First, it is not done by URL Connections and the clients don't check the server every period of time. Usually you have a client/server architecture where your client is the app on the device and the server is a real server program that resides on a server machine. The server could be Microsoft (using C# for example) or MAC (using Objective C). The server has a database that it stores information inside it. Some important information (related to your question) is the APN Count Value, the Message that you want to deliver, the state of the client if online or offline.
When a client likes to send something to another client, or when the server wants to send something to a client (or all the client), a check is made to the recipient client to see if he is online or offline. If he is online the message is sent directly, and usually the communications are done on TCP Sockets. If the user is offline then the server will store the message that needs to be sent to the client, increase the APN Count value, send an APN to that recipient. When that recipient becomes online, the server will notice that (because there is establish connection and handshaking) and therefore will fetch all undelivered messages from the database and send them to him...
It is a long process, I hope I was able to explain things a bit to you. In all cases I don't think your way is practical or enables you to reach real work.
I'm trying to implement an app that can read received SMS and email out. I mean convert the text content to voice. So I need to access to SMS and email first. As far as I know, there is no such API provided in the default SDK. Is there any other way to realize it?
Are the SMS messages stored in database(sms.db)? How to access to them? Is it only possible on jailbroken iphones?
And what about emails? Are they only stored in mail servers? How can I get them in my app?
Sorry for asking so many questions. I have spent many days on this problem, but havn't found any solutions...
You can't. According to the Device Features Programming Guide: Sending an SMS Message:
In iPhone OS 4.0 and later, you can send text messages from within your application. This feature is strictly for sending messages. Incoming SMS messages go to the built-in Messages app.
There are serious privacy and security concerns with enabling app access to emails and SMS, and I am glad Apple choose not to do it.
Yes, you can, (at least with SMS) but only in a jailbreak app (which you suggest is ok in your comments).
The sms.db file can be read by apps that aren't sandboxed.
See my answer to a similar question for how to get SMS content. That answer just shows how to get the most recent SMS, but if you just use the commented out while loop, you can iterate through all SMS.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to programmatically send SMS on the iPhone?
is it possible to send sms through programming in iPhone/iPod applications.
There are two answers to this question:
1 - Not really.
2 - Of course!
Using OS3.x, you can sorta kinda almost do it. You can programmatically bring the user to the built-in SMS drafting application and you can pre-populate the "TO:" field. However, you cannot programmatically generate the message to be sent.
Using OS4.0 (currently in Beta) you can (according to these guys http://iphonesdkdev.blogspot.com/2010/04/mfmessagecomposeviewcontroller-sample.html) present a modal view of the SMS drafting application, or, rather you can show the user something that looks and behaves like the built-in SMS application without actually taking them out of your program (google MFMessageComposeViewController) and populate all of the fields... you can even provide more than one destination address for the SMS/MMS message.
That being said, there is no way of sending SMS messages without first presenting those messages to the user. At which point the user is free to either send them, not send them, or modify them before sending them.
You can set the body in iOS 4. Please cf the documentation.
It is possible to initiate a sms message using the sms:<phone-no> URL. It is however not possible to fill in any content in the sms, nor is it possible to automatically send the sms.
More details are available in this Apple article.