I recently have been very interested in developing iOS apps (for iPhone specifically) that can "communicate" with nearby (geographically) apps.
My networking skills/resources are limited, so I was really hoping to make it a peer to peer app, avoiding the need to host my own server.
It seems like I have a few options, including the newish Multi-peer Connectivity framework, and Location services.
I was hoping someone who has experience writing peer to peer apps could direct me to what they think the most logical approach would be.
Additonal info:
*I am only looking to send text/small pictures (speed is not a priority)
*Detecting nearby (within a mile or so) geographically is the main goal
*Possibly communicate with Android devices (I know multi-peer connectivity lacks this)
Peer-to-peer communication is limited to a range of about 50 meters. To extend the range you can create a mesh using intermediate peers to relay messages. That is how the Firechat app works.
If you want to communicate over greater distances without a mesh I believe you will need to go via the cloud
In terms of communicating with Android, the people who made FireChat are coming out with their SDK. Not sure how/what pricing will be but I assume they will offer this cross platform function. There are of course other ways but I am not that advanced in app development to know them yet.
For a simple chat app there are many free online tutorials that help you create iphone to iphone chat app that can also send images. Range will be limited however to whatever is max for WiFi. Like Keith said, mesh is another option but I believe everyone in the network has to have the app for the data to bounce.
Related
We are developing a mobile application that tracks users while they are picking up and delivering commodities. We have overcome many issues, including poor connectivity in rural areas, the app going into the background, and so on.
One issue continues to befuddle us. When receiving calls some drivers lose connectivity, other drivers will gain connectivity, and others (most) have no change in connectivity.
I remember earlier that Verizon iPhone users couldn't access data while on a call. Naively I thought that this issue was completely overcome, but perhaps it is not.
My understanding is that a) there are still some cellular protocols that cannot handle voice and data and b) there are (or were) some settings in mobile phones that give the user a choice.
I have searched for some list of cellular protocols and iOS and Android settings but so far come up empty.
Any guidance would be greatly appreciated.
Hopefully this will provide some more clarity; it all depends on the Radio Access Network (RAN) technology they're using (2G/3G/4G) and the terminal itself's capabilities.
There's 3 umbrella terms of technologies, each with their own revisions and variants, but this should cover it:
LTE (4G) only supports voice calls via VoLTE (Voice over LTE). Calls made over VoLTE will allow the user to continue accessing data at the same time. Many devices & some networks don't yet have VoLTE capability, so they use Circuit Switched Fall Back (CSFB) to drop to a 2G/3G Radio Access Network for making voice calls. (If your terminal does this you then have that RAN's ability to allow simultaneous voice/data.)
3G - There's a few flavors of "3G", depending on the terminal and the RAN variant (UMTS / EDGE / CDMA / HSDPA / HSDPA+) you may be able to access data and be on a call at the same time.
GSM (2G) does not have this functionality, the handset is either in Circuit Switched (Voice) or Packet Switched (Data) mode but not both.
The decision of which RAN to use is based off the priorities stored in the SIM/USIM, the received signal strength of the available networks and the capabilities of the terminal.
This means for example your users who may gain connectivity may find themselves using a 3G access technology on a 4G enabled terminal, with VoLTE support, jumping up to VoLTE to make the call. (Some operators resell to MVNOs but default to slower / older RAN technology like the 3G family)
Others may loose connectivity as you've seen, if they're happily using LTE on a device with no VoLTE support and need to drop to 2G/3G for a call (CSFB) they may loose data services as they're back to the limitations of these older RAN technologies.
for Android, several apps exist that show such information, like https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer does it:
I need similar functionality in my iOS app but can't find any information about that. It this forbidden by Apple?
Apple doesn't allow apps to access the hardware like that. A fairly common workaround is to measure network throughput instead. You could take periodic samples of the current network speed, and then display that data over time.
Network Multimeter, for example, is an app that will give you info on your network as you walk around. It does that by sending data across the network and displaying the throughput.
Apologies in advance for the general-ness of the question.
I'm writing a multiple client iOS app for viewing the video feed from a single camera. Can the QX10 api support two (or 3) iPad's discovering/viewing the same QX10 at the same time?
I've been looking QX10 sample code, the camera api docs, StackOverflow, and of course the dev website and haven't seen an answer. I'd just buy the bloody thing to test with, but there are none nearby and I was hoping to avoid having to mail order/return it if it didn't work.
....And we're not locked into HW. If there's a better option, I'm open....
I don't believe it does. For ios, the camera creates a network that the ios connects to. (In ios settings/wireless) Any further attempts to connect to the camera from another device fail. Since the API only works after a network connection is established, I don't see how the API could possibly allow 2 devices could connect at once.
(No extraneous words in this post b/c that will get edited which auto down votes the question.....ahhh internet)
I did not try it, but you could use a computer with nat. For example an openrwt router to open up multiple wifi interfaces, one to connect to the camera, using the 10.0.0.0 network the camera uses and then an other network to connect your clients with NAT.
The question would be when the API would start to get confused.
So depending on what you want, maybe some mapper on that helper-computer could
do some proxying of information.
So in theory with an external box, maybe, but as Oldmicah said, it seems that only
one device can connect at the time (at least my QX100 also behaves like that). :(
I'm a newbie to iOS, and I'm somewhat lost in the sea of networking libraries available.
I'm interested a library that will allow me to:
discover other users using the application nearby
send activity (for example the coordinates of where the user last touched the screen)
receive activity (for example the coordinates where another user last touched the screen)
send/receive activity with relatively low latency
not require a command and control server of some sort to coordinate all this if possible
Is there one library that will do this?
You should look into the Multipeer Connectivity framework:
https://developer.apple.com/library/ios/documentation/MultipeerConnectivity/Reference/MultipeerConnectivityFramework/Introduction/Introduction.html
It lets you construct peer to peer connections over bluetooth, cell, wifi, and peer-to-peer wifi. I'm going to start investigating this myself very soon so feel free to stay in touch if you want to trade experiences.
I don't think you can avoid a server side in this case if you want to
discover other users using the application nearby
Unless you use technology like bluetooth? Otherwise, AFNetworking is a high level, easy to use framework with very good documentation.
I have just delivered a prototype for a big client, everything was fine but I'm now curious to know if the solution/architecture I've chosen was the right one or there's place for improvement in case the project will keep on.
The task was to build two iOS apps: one running on 5 different iPhones, and another running on 2 iPads. Basically the iPhone applications had to communicate information to the iPads, and occasionally they also had to send information between each other (iPhone to iPhone). All the infos where small JSON objects/chunks whose size was small, really small.
The app was not intended to reach the app store, is a working prototype to test out some ideas in a user testing environment.
I discarded bluetooth because we are talking about a peer-to-peer communication, not a one-to-one.
What I did was to use web sockets thanks to SocketIO, through a small Node.js server that was running on my mac. The server was really simple, just receiving the messages from the clients and broadcasting information to the other ones.
What do you think? Is the solution I've chosen ok, or there are better ones?
For example, this morning I've just found out these thread here on SO, and I've discovered I could have used GameKit. What do you think?
Socket.IO is nice because it is fairly simple to implement but it has the downside of requiring a central server. If you wanted to avoid that, you could use the Multipeer Connectivity framework that was introduced in iOS 7.
It will let you create one-to-one communication channels between devices on either the same WiFi network or Bluetooth. Once the channel is created, you can send whole NSData objects (or create streams but it doesn't seem relevant to your use case).
A good read : http://nshipster.com/multipeer-connectivity/
The WiTap sample from Apple demonstrates peer-to-peer networking over Wi-Fi and Bluetooth. Using Bonjour, the application both advertises itself on the local network and displays a list of other instances on the network. Supports infrastructure networks, peer-to-peer Bluetooth, and peer-to-peer Wi-Fi (on compatible hardware).
I have personally tested it and it works fine and well documented.
I think socket.io is the best choice. It is built on top of engine.io (which in turn is built on the fastest websocket implementation: ws) It has oldest to newest fallbacks, so it starts with long polling and works its way up. This guarantees a quick initial connection instead of needing to poll the device for features. You can read more on this here. Best of all, it handles everything seamlessly. You write your code as if websockets are supported on connecting devices and if not it will use other methods behind the scenes.
This post details many of the websocket libraries you could use with your server. Which websocket library to use with Node.js?
I am convinced Bonjour is the best solution:
Apps can also leverage Bonjour to automatically detect other instances
of the app (or other services) on the network.
However I've never used it myself; perhaps someone who has can comment?