According to Cocoa with Love Reachability is needed when an app requires WiFi (rather than cellular network), e.g. if app loads heavy videos and is not meant to be used over 3G.
My app uses internet no matter if WiFi or 3G and only downloads small data from web services.
Can someone clarify under which circumstances an app must do this reachability test?
Reachability is needed if your application needs to know 'when' it's ability to access the network has changed.
I've seen recommendations that say to always try to access your resource first, and if you fail - to use data from Reachability to find out why.
Since you're using internet connection only for small data downloads you really don't need to care if you're using WiFi or 3G.
True, there are some restrictions for cellular newtorks. Take a look at paragraphs 9.3 and 9.4 AppStore Review Guidelines. You need a developer id to view it so i think we're not allowed to quote it here.
Related
I am trying to prototype a solution to a problem and am currently exploring multiple routes I could try. Is it possible for one iOS device, running a certain app, to communicate directly with another iOS device, running the same application - without the need to be on the same LAN?
Solutions I am currently investigating are using Bluetooth and ad-hoc wireless connections.
Ideally, the application when installed would ask the user for the required permissions, and then would accept and/or send data to/from another client after a handshake had happened.
My concern with Bluetooth is that 'pairing' would need to happen with every device, rather than happen in the background once the user has installed the app. I have a feeling what I am talking about isn't possible from what I've been reading elsewhere on Stackoverflow.
Take a look at Bluetooth Low Energy.
https://developer.apple.com/library/ios/#samplecode/BTLE_Transfer/Introduction/Intro.html#//apple_ref/doc/uid/DTS40012927
Here is another example,
https://github.com/KhaosT/CBPeripheralManager-Demo
You might also want to look into GameKit and peer-to-peer connectivity there.
I can't tell you anything about it, but you might try looking at iOS 7. If that's an option, I'd take a look. Can't talk about what it is because of NDA though.
Depending on what you need to communicate, you could try checking out this project, which lets you share arrays of strings between iOS devices over Bluetooth LE.
You don't need to "pair" the devices and it can still communicate while the app is in the background. SimpleShare
Hope it helps!
From the documentation of MultipeerGroupChat:
MultipeerGroupChat sample application utilizes the Multipeer Connectivity framework to enable nearby users to discover, connected, and send data between each other. This sample simulates a simple chat interface where up to 8 devices can connect with each other and send text messages or images to each other. Here you will learn how to bring up framework UI for discovery and connections and also how to monitor session state, listen for incoming data and resources, and send data and resources.
This is an excellent example at developer.apple.com here is the link
https://developer.apple.com/library/ios/samplecode/MultipeerGroupChat/Introduction/Intro.html
Also this tutorial from Ralf Ebert demonstrates how to use Multipeer Connectivity framework for peer communication should help you.
https://www.ralfebert.de/tutorials/ios-swift-multipeer-connectivity/
My iPhone connects over adhoc wifi to a wifi sensor module.
The challenge is to code an app that uses this sensor module. But I'm not sure what specific API's to use to best architect this implementation.
I've started looking into the CocoaAsyncSocket class as it seems to be an appropriate tool for such use.
Does the user always have to manually connect to the adhoc wifi device? (through the Settings app) or can my own app handle the searching, making, and breaking of the wifi connection?
I doubt iOS lets me programmatically toggle whether Wifi is on/off.
Once the sensor data is being received, what container would best handle the stream?
For example, on other platforms, I coded a rotating queue buffer.
Thanks for your input.
Edit: The protocol in question is straight CSV formatted ASCII. Not HTTP, FTP, etc. Just raw data. The app is to simply open a port on the connected IP, and read/write.
Your application cannot turn wifi on/off, or select a wifi network.
Without more information on what protocols this wifi sensor module speaks, it will be impossible for anyone to give more than vague recommendations. If the module can serve data over an http connection, that would probably be ideal. If it requires your software to open a connection on a specific port and communicate over something other than http or ftp, your job will be a bit more complicated. CFNetwork and projects derived from it's usage, such as CocoaAsyncSocket which you mentioned. You can see another implementation of an HTTP connection over CFNetwork in ASIHTTPRequest, that may help as a reference for handling download streams, queuing operations, etc.
As for storing the data, again it's hard to give any concrete recommendations without more information. If you want to store the data to the filesystem of the iOS device, NSData will probably meet your needs. If you need/prefer to use a queue for buffering data, there is a simple category on NSArray which provides queue semantics. The link to CHCircularBuffer in that SO article is dead, but this github project appears to have it.
edit: Here is the official version of the CHDataStructures. I don't know if it's an improvement over the previous link, but it appears to be updated for the more recent iOS SDK.
Add the SSID of your wifi ad hoc networks in settings. When you see the SSID of the network, click the arrow and choose connect automatically. After this, the phone will automatically connect whenever it comes in range. After this, the two devices can communicate using regular socket APIs.
In iTunes, you can see the charge status of the iPhone currently connected:
This updates as the phone charges, and even shows when the phone is done charging.
Is there a way I can discover the charge status programmatically from the Mac? Any programming language or API is fine.
I would recommend setting up a bonjour service in an App on the iOS device to communicate with the computer. The app will then communicate the changes in the batter status using the batteryMonitoringEnabled property of UIDevice. Take a look at the samples code here.
BatteryStatus Sample Code
And here is the class reference
UIDevice Class Reference
And finally Bonjour programming
Bonjour programming guide
As far as I know, the only official way to communicate with the iPhone over USB/Bluetooth is by signing up to the "Made for iPhone" program:
http://developer.apple.com/programs/mfi/
Unfortunately the documentation seems to be closed to registered members so I can't find out if the API for this is public or private. You could contact Apple to check before applying.
UPDATE : As mentioned, this might not work for Mac/PC <-> iPhone communication over USB. There are several apps that do things with the phone over USB (although usually for reading/writing files). I'd start by looking at the source code of those:
http://code.google.com/p/iphonedisk
This should put you at least in a position where you have a connection to the device and are able to send/receive commands. Everyone who's ever done this sort of thing has had to spend time reverse engineering the thing :) The jailbreak community might be able to provide some insight too, although having to actually jailbreak the device is probably unacceptable.
I'm working on an application that downloads some data from the internet using NSData's initWithContentsOfURL method. At startup I'm using some code from Apple's Reachability sample to check if a wifi connection is available; if not, then the app just shows an error message and refuses to really start (as requested by my client). All is working fine on iPod and iPad, but on iPhone, my client reports much, much slower download speeds, unless he turns on airplane mode, in which case download speeds are on par with iPod / iPad speeds. So it seems that even though a wifi connection is available, the iPhone is probably using the cellular network to download the data. Which is really weird. Does anyone have any idea about what I might be doing wrong?
I believe your answer is SCNetworkReachability which you already have access to since you are using Apple's Reachability code.
The SCNetworkReachability API allows an application to determine the status of a system's current network configuration and the reachability of a target host. One of the flags returned by the API, kSCNetworkReachabilityFlagsIsWWAN, will tell you if a network connection to the target host uses the carrier network. The Reachability sample code shows how to determine the active network connection.
You could also use this to enforce WiFi if that's what you want.
Have a look at UIRequiresPersistentWiFi
Could someone suggest a tutorial/sample on how an Iphone application can send data to a remote server using Carrier Data Network only? In other words is there a way an application can programmatically force to enable Carrier Data Network communication, use it to send its request to the remote server and switch it back to user specific communication settings.
I am taking this approach because my application needs to send user's personal info to my server and sending it over public WiFi does not sound right. Please let me know if there is better approach to it....
Thanks
Since no one's writing a full answer ...
I don't know if it's possible to detect CDN vs Wi-Fi, although at some level it must be because the App Store is capable of determining such to prevent large CDN downloads. Of course, the App Store app has access to the private APIs; this functionality may not be exposed publicly. (I don't know if that is the case or not, but be sure you do not use private APIs for your app; the store won't accept it.)
That said, think about the use case of your app, and the marketplace. The iPhone OS and the iPhone App Store are more than just the phones themselves -- they're the iPhone and iPod Touch devices. iPod Touches do not have a CDN; they're Wi-Fi only for connectivity.
As Marc W said in a comment, not all Wi-Fi is public, not all public Wi-Fi is free, and you will likely upset a significant portion of your audience -- people (presumably and hopefully) giving you money.
A better solution would be to use SSL to provide encryption of the private data during transport. This is widely available, works over CDN or Wi-Fi, and provides all the security you should need.
If you look at the Apple Reachability example code, you can test for how you would access a host - however I agree with the other posters that you should consider encrypting your data and let your user's determine how they want to connect to the Internet, and not force one form of connection.
-t