I am trying to figure out how to connect to a cellular network and what classes of iOS I should use?
And, does iOS 7 support apps checking data in the background? It would be similar to checking if you were in a certain location.
Thanks!
Your phone will connect to a cellular network when you make any networking (internet) calls in your code. It will also connect to the internet through wifi, it doesn't care what type of connection you have, what you are trying to do is get info from the internet.
To do this, you must use some sort of networking library. The standard Apple-supported library is called NSURLSession and came out (an improvement upon the older NSURLConnection) with iOS7 and it works great. Suffer through the reading and you'll be rewarded - Link to Apple Docs
There's also a 3rd party library called AFNetworking created by Mattt (yes, 3 t's) that's awesome and probably the most used 3rd party iOS library there is. Highly, highly recommend looking into this and giving some consideration when wanting to talk to the internet through an app. - Link to AFNetworking
Related
I want to build an iOS application that people can video call or audio call to each other. Stable calling is my goal, and it means I need less connection interrupt as much as good, I also need light application (not too high application size because of video libraries)
I've googled about "ios video chat' keywords since last few days. Researched and found that the most popular framework (technology, library) for video/audio calling are XMPP and WebRTC (I'm I right or do guys have something better?)
XMPP - Client/server TCP communication
WebRTC - P2P Connection
The information about these libraries make me confused, so which library I should use for better performance, light application, stable?
Any idea?
XMPP is about signaling (reaching from A to B, indicating the desire to have a "call", disconnecting, etc).
WebRTC is about media (actually sending voice and video).
You need both signaling and media in your app.
For media use WebRTC. There's nothing else that will make sense. On iOS, it is kind of tricky at the moment, as iOS 11 incorporates WebRTC already, so how this will apply and help you in your development is yet to be seen (see here).
My suggestion is to aim for a web app and then figure out if you need to go for a fully native implementation and port WebRTC to iOS - or just use a webview inside an app (Cordova or Crosswalk should do).
For signaling, you can use XMPP. Or anything else for that matter. My own personal preference is a proprietary protocol. Look at Matrix or SimpleWebRTC for that.
Also - don't forget that you will need to deal with STUN and TURN - NAT traversal, but that's a simpler thing to handle.
XMPP Framework: https://github.com/robbiehanson/XMPPFramework/wiki/IntroToFramework
WebRTC Native Code: https://webrtc.org/native-code/ios/
its not about which is best its about what fulfills our requirements
I’m not talking about Reachability.
What I’m talking about is figuring out how to create a network connection from an iOS device across the cellular interface.
Why? Because I have conditions where the device connects to a WiFi access point so it chooses WiFi… but that access point is not internet connected and goes nowhere. I have data which I must make every effort to deliver and it some cases it’s getting lost in the WiFi gateway to purgatory. In both cases of using Reachability and relying on MPTCP, Apple has already given priority to WiFi in the stack.
I know NSURLSessionConfiguration can set allowsCellularAccess to allow cellular access — I’m looking to require cellular for the routing.
Even at the CFNetwork level I’m looking at kCFStreamPropertyConnectionIsCellular for status, kCFStreamPropertyNoCellular to disable cellular.
I can’t find anyway to give preference to the cellular radio. I realize Apple has gone to great lengths to prefer WiFi and I’m going against that — which is why I’m having such difficulty finding an answer to this.
I'd like to keep this up in the Cocoa level, but not opposed to going into Foundation or deeper levels. I would like to avoid trying to parse an interface table (if it's even accessible) to figure out which is the cellular interface.
Has anyone successfully created a network connection across the cellular link despite WiFi appearing to be present?
Is some configuration of Multipath TCP the answer here?
To bind to a particular interface, as far as I'm aware, you'd have to drop all the way down to the raw socket level, and there's no way to provide a custom socket for NSURLSession purposes, so you'd basically be rewriting it from scratch. You should file a bug asking for support for binding an NSURLSession to a source IP.
The behavior you're experiencing is a known problem with iOS and disconnected networks. iOS 9 and later do a better job, but even then, they can be highly problematic; the devices sometimes refuse to talk to the Wi-Fi network, and sometimes refuse to talk to the cellular network. Specifically, it seems to fail spectacularly if either signal is weak. Just this morning, I actually had to force my iPhone (iOS 10) to talk to a disconnected Wi-Fi network by putting it in Airplane mode and enabling only Wi-Fi.
I'm told that you can fix this by configuring the network's DHCP server to not provide a router advertisement; that said, every time I've tried that, the iOS device would just keep asking for an offer repeatedly. Maybe that bug got fixed at some point. If so, it might be worth a shot, but don't expect it to work in older versions of iOS.
Failing that, assuming you don't need to support web browsers in iOS 3 and earlier, you might try eliminating the DHCP server on that Wi-Fi network entirely, and just rely on DNS service discovery with zero-conf IPs. That way, the device won't see a router, and it won't try to send data out that interface except to those link-local IPs.
If that isn't possible for some reason, ordinarily I would suggest using a customized copy of libcurl, except that I doubt this will work in your case, because POSIX networking doesn't wake the cellular hardware.
In iOS 12 and later you can use the Network Framework. Sample code is here.
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?
I am currently using an adapted reachabilty framework based on Apple's sample code.
The framework works fine, however it provides false postives.
If the user is attached to a wifi network where they are required to login before having a valid connection, the framework shows as an active connection when in fact it isn't.
An example of this is Starbucks' wifi where you must provide an email address before you get online.
Is there a way around this without pinging a certain address?
Currently I am using the reachabilityWithHostname function
Thanks
Daniel
Update as provided by the link below i see this is a limitation of the framework. Are others finding away to alert the user of this?
If your computer is connected to a Wi-Fi access point, but that access point's internet connection is down, reachability will tell you that yes, you have a network connection
Check out this link
Networking is playing an ever more important role in application
development, and Apple's reachability API is a valuable tool in making
network-centric apps play nicely with varying real-world conditions.
Today I'm going to give an overview of the reachability API, what it
does, and how to use it.
This should help you.
If I want to have my iOS device act as a "server" and broadcast its bluetooth services to other iOS devices, how would I use the core-bluetooth framework (or any other iOS framework) to implement this? So far, all I've seen from the corebluetooth framework is how to write the client-side of things. (Scanning, connecting to existing bluetooth services)
You can make use of the OSX sample project called DNSSDObjects. The core classes (three of them) work just fine under iOS. The code requires a few small changes to work with Bluetooth (as-is they only work with WiFi). See my answer to another question for the required code changes.
Basically you use whatever code you need to setup your server and begin accepting socket connections. You then use the DNSSDRegistration class to advertise your server via Bonjour.
The other two classes, DNSSDBrowser and DNSSDService can be used by iOS client code to find the server, or any app or program that can find Bonjour services will also be able to find your server.
There are two great WWDC video that show how to act as either the client or the server using an appropriate iOS device. They can be found here, you're looking for sessions 703 and 705.
Downloads of the source that they use can be found here. You'll need a developer account (free works) to login and view/download.