The docs say:
"Include this key if your app requires (or specifically prohibits)
access to the networking features of the device."
It uses WiFi when available, but also 3G / mobile data.
I am afraid if I specify this key, it effectively means that the app doesn't work without a WiFi connection. Which would be wrong. It just requires internet access.
Related
I tried to configure a bonding pincode on my Movesense 2.0.0 sensor and I was expecting being asked for it when trying to connect to the sensor with MDS or apps like nRF Connect.
But what I got looks identical to Just Works mode, and the bonding PIN is being asked only if I try to pair the device through system's Bluetooth settings. Does it happen because in the first case there's only connection and no pairing? What are the pros/use cases for having the sensor paired at system-level?
I'm looking for a way to prevent unauthorized access (connections, API requests) to sensors from devices not knowing a secret access code (like a PIN). Do BLE/Movesense provide such a mechanism?
Neither Bluetooth nor Movesense offer a way to securely "log in with a secret password". The passkey bonding mechanism that is present in Bluetooth, is only designed with the purpose of avoiding man in the middle attacks, and the passkey must be random everytime since the protocol reveals the key after each attempt. A static passkey which some people use is not allowed per the specification. It might keep away your grandmother from accessing the device, but is not secure at all at a protocol level.
If you bond the device at a system level, the further communication will be secure (encrypted and authenticated) and will for example prevent spoofing attacks. It will also result in quicker device connection setup since GATT caching can be used.
You are not saying what "system" you are using so this is just a general answer.
First and foremost,
I am looking for a resource to use Private API's.
this is an enterprise application and will never go to the app store
I need to take as much configuration out of the users hands as possible.
That being said, I have a device that an ipad will be connected to and communicate with via an adhoc wifi network supplied by the device. the ipad connects to this device and sends raw data to it via socket connections. I also need to connect to the internet for data syncing.
80% of the time, the ipad will be connected to this adhoc wifi device. Management software on the ipad does not allow the user to adjust wifi settings so I am trying to make sure I am connected to my device without limiting my server syncing. I know I can determine the connection using apples Reachability class, this is not what i am looking for. I need to use BOTH 3g AND wifi.
Is there a way to enforce this in code? Or is there a resource for the private API's that I can look at to find a way?
This will be in iOS 5 and the most preferable method would be to just route my http requests via some private api method to use 3G and let the socket requests use wifi to the adhoc device.
code samples would be awesome, links / class names to research would be very much appreciated.
and once again this is not going into the app store, it is an enterprise app
the resolution i found was to assign an ip in the privately assigned ip range the ipad uses (169.254.x.x) to the adhoc device then let the ipad determine an ip. Then see if i can open a socket connection to the device (to determine if its available) and then issue a print.
Going this route, i am still able to use 3g data as well as communicate with the device via wifi.
Is it possible to identify devices around me that have their bluetouth enabled?
I don't need to communicate with them, just know they are there.
I am looking for something similar to android's BluetouthDevice.startDiscovery()
Is something like this possible?
Apple turns out to be very restrictive about Bluetooth communications for iOS platform.
Focusing about a native application with Xcode (but not PhoneGap based - PhoneGap is a Xcode plugin that allows web apps to be converted into native ones; btw it gives a quite nice but limited access to underlying hardware resources) for a iOS device to communicate with bluetooth devices (even with discovery actions) the following conditions have to be met:
-) The device you're trying to discover must be equipped with Apple Bluetooth authentication chip (you can ask to Apple directly for the MFi program);
-) Internally your app must declare a protocol name (e.g.: net.yourcompany.proto0) which the devices you connect with must conform to;
-) You must use Apple's External Accessory Framework to establish communication with such devices.
In short, by this procedure Apple guarantees that the only Bluetooth communications an iOS device can establish are just with authorized and certified Bluetooth devices.
I've gone 400 Mph about this thing but I hope it can give you some pointer to start your search.
The topic is too wide to be treated here in its full length.
One thing you might want to look into is Bonjour and NSNetServiceBrowser.
You can publish a service and also search for other services around you. There are ways to run Bonjour in the background (http://stackoverflow.com/questions/6345554/bonjour-in-the-background).
The only limitation with this approach is that everyone else would also need to be running the app as well. Also, by default Bonjour discovers over both WiFi and Bluetooth, something else you would probably need to look into.
Is it possible to communicate two instances of an app:
In nearby devices (Android or iPhone)
Without user intervention (aside from starting the app once)
Without internet (but not network) connection?
How?
Android to Android?
iPhone to iPhone?
Android to iPhone and vice-versa?
Let us ignore the issues associated with implementing the network communication at the application level and focus on the system design problem your question raises.
You want an application on one device to connect to another associated application on another device without any user intervention/interaction beyond launching the device. In order for this to work your system is going to need a 3rd party separate from the two devices/applications that provides a lookup service.
What will need to happen is each application will need to communicate with this service, ask for the data regarding other device it should connect to, if it exists, and then attempt that connection. This is basically how a bittorrent tracker works.
Keep in mind that there's quite a bit more involved in the implementation than that simple scenario suggests. For example, the proper registering/unregistering of devices, registration timeouts, security, etc.
Unless I misunderstand your question, you should be able to just use standard sockets (TCP or UDP depending on your needs) for communication between any/all devices. For iPhone, you could probably use the NSStream classes and for Android you'd use the Socket classes.
Can the new NFC feature be an answer to this?
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