My iPhone application needs to dial a phone number and send some data to a remote server.
It's important that I:
Trigger the call, and then
set up a background task that will communicate with my server
I've been developing/testing with an AT&T phone, which has no problem sending the data in the background while a phone call is initiated.
However, Verizon customers don't have the ability to call and stream data, so for them, I'd like to reverse my order of operations.
What's the best way to determine which route I need to take? I've seen examples of looking at the iPhone's model number, and if it's 3.3, it means it's Verizon so I can proceed from there, but that doesn't seem robust or future proof. Is Verizon the only carrier that currently has this limitation? Seems like there should be some sort of property like -[UIDevice isMultiTaskingSupported].
There’s no great one-liner like the UIDevice method you mentioned, but there is the Core Telephony framework. I haven’t used it myself, but it seems like you could use the CTCarrier class to find this out, specifically the mobileNetworkCode property. This list should get you started. From the look of it, for some carriers, you can use this code to determine if you’re on EDGE or not. For CDMA or EDGE networks, the answer will be “no” for simultaneously streaming voice and data, but for GSM networks that aren’t EDGE, you’re good. You could also just use the carrierName property and look for “AT&T,” but that doesn’t account for EDGE.
Is there a good solution? Probably not.
Related
I am thinking about a web app to detect the presence of the other iPads/iPhones. This is purely theoretical at the moment, i have no idea how to do this.
My question is what is my best technology/language method of doing this?
Is it going to be bluetooth or gps? How does the App Bump work?
Thanks for any suggestions posted...
Bump's FAQs: http://bu.mp/faq
According to their FAQs, when your phone has the Bump app up and ready, the app listens to the accelerometer for a sharp stop (your hand with your phone in it stopping when it hits the other person's hand with their phone in it), at this point, exact date time information as well as GPS position and characteristics of the bump are sent off to Bump's servers to compare other information from other bump users to see what other bump account shares most of that information. Bluetooth is not used in any capacity to make this happen, not for the transfer or the recognition of who to transfer to.
Your website may have to do the same thing. Have every instance report to your server, and then report back from the server where other people are.
Of course this goes without saying that I'm sure you were thinking about privacy settings and other layers of personal security.
Options I'd explore:
Bonjour discovery. In principle devices that can see each other via Bonjour could actually be in different continents, but usually it means 'same wireless network' and therefore at least 'same building'.
Game kit. Actually, this either uses Bluetooth or the local network, so is probably going to have similar results to Bonjour discovery but in less code.
I wouldn't try location services like Core Location (actually I would, but only if the above don't work), as the results probably aren't going to be fine enough. Especially indoors: the Maps app on my phone places me in a circle of about 50 metres radius with my actual location being on the outer edge of said circle. Someone on the next street with similar resolution could, as far as the app is concerned, be adjacent to me.
We are developing an enterprise application .The phones are connected to a Wifi router. The objective is to trigger an alarm if the phone moves out of the secure area .. (outside the building)
What is the best way to check if the iPhone is always inside the building .
some of the options we tried are
1.using Wifi(continous ping to wifi network),if not trigger an alarm .
2.if coordinates change (using GPS)
Are there any other means to achieve this .
You can use Location Services in iOS 4 (with the background location feature) to determine when the phone has moved to a different location.
#indragie's idea of using Location Services is a good one. If you can be sure that the WIFI SID isn't going to change, you could probe to see which access point the iPhone is currently associated to. If you are going to ping, then a better approach is to make the system service agnostic, and simply issue an HTTP query on a regular basis to your enterprise server. The server can then have a policy language on it declaring acceptable access points (from a variety of metrics). This might be set up to allow people to take their iPhones home.
Your best bet is GPS as the phone will not be able to find its location if you rely on WiFi and the device is not connected to a WiFi network.
Check out Apple's documentation for Location Awareness capabilities here http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html
You will be able to track "significant" or standard location changes in the background, details can be found here http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5
[edit to include]
This might be of interest to you too - http://longweekendmobile.com/2010/07/22/iphone-background-gps-accurate-to-500-meters-not-enough-for-foot-traffic/
It depends on what you want to do. Just to let the iPhone user know that he/she is moving away, using Location Services is good enough.
However, if you want to have a server that makes sure all the devices are within range, then it's more complex because your application may get suspended without a notice from a background state; in other words, you may not be able to catch the moment when your application terminates and take appropriate actions. Therefore you are going to need a heartbeat system like pinging to the server in this case.
Today, the focus of a cell phone's capabilities is drifting away from plain making a phone call.
And somehow, this shows in the API's too. Therefor I'm wondering: if I want to write an app that e.g. pitches up, records, scrambles... an incoming call - you know, the voice on the other side -, what aspect of the API should I use?
I looked into Android, into Windows Phone, iPhone... (briefly), but had no luck. Is this just unintended usage?
This is also not possible with Windows Phone 7. There were, however, API methods for interacting with incoming and outgoing calls and texts in Windows Mobile.
The reason this is not possible in Windows Phone 7 comes down to a deliberate decision around data security and the aim that apps on the phone shouldn't be able to do something without the user specifically knowing about it. This prevents, amongst other things, malicious apps having information about or access to potentially sensitive data.
This is not possible in Android, except maybe via firmware modifications.
There’s no way to do that with the iPhone SDK. It may be possible through jailbreaking, but I’m not familiar enough with it to speak on it.
Given the limited accessibility of in-call audio but ready access to microphone/speaker and data on current smartphones, would probably be easiest to do this as part of a VOIP calling application.
I'm trying to understand the basic steps required for a game I'm trying to make using GameKit for bluetooth connections. I only have 1 device, so I can't test out my ideas very easily.
The game involves a maximum of 2 players over bluetooth via GameKit and the only data to send/receive is a 'shot' which includes position and direction data only.
This is what I think should happen, I really just want someone to point out any mistakes I've made:
The game starts by presenting a GKPeerPickerController with a connectionTypeMask of 'GKPeerPickerConnectionTypeNearby' and setting it's delegate to 'self'.
The GKPeerPickerController delegate method 'peerPickerController:didConnectPeer:toSession:' is implemented and sets the sessions dataReceiveHandler to self. The peerID is added to an NSMutableArray which holds all peer IDs connected. (There should only be 1 peer connected at any time).
To enforce only 1 peer connection per game the method 'session:didReceiveConnectionRequestFromPeer:' checks the 'count' property of the NSMutableArray which holds the connected peerIDs. If 'count'>0 then we respond by calling: 'denyConnectionFromPeer:' else, we call: 'acceptConnectionFromPeer:error:'
To send a shot, the game calls: 'sendData:toPeers:withDataMode:error:'
To receive shots, the game responds to: 'receiveData:fromPeer:inSession:context:'
Are there any steps missing? For example, if a user tries to connect to me before I connect to them, what will happen with my GKPeerPickerController? How do I know to dismiss it?
And without another iPhone/iPod I can't test.
First off, if you want to test Bluetooth in Gamekit you really are going to need a 2nd device. If you're serious about your app, try and buy a cheap/refurbished iPhone or iPod Touch that will support GameKit Bluetooth (the oldest devices don't do it). I actually think you do even better with two Macs for testing, but if you don't already have a second one that's an expensive proposition.
What you've posted above is pretty much correct - actually using the PeerPicker is pretty straightforward and you should be able to get through it easily using Apple's docs. The problem is that in my experience, it's a bit janky. It might be because I'm using a 3GS and a 3G to test and they have different Bluetooth inside, but a lot of times I see weird things when the scenario you outlined occurred - "if a user tries to connect to me before I connect to them." In the end it typically still works, but not without a little overhead of waiting and perhaps the user having to repeat the process a time or two.
When you hold the iPhone to your ear, it detects that there's something (proximity-sensor) and switches off the display.
is it possible to access this sensor in an iPhone app?
It is possible via undocumented System calls, this is how Google's voice search works on the iPhone to start listening when it is close to your ear (or so i'm told). The API isn't publicly exposed though so although google got the app on the store your app might be subject to more scrutiny.
Sorry I can't tell you exactly what the calls are.
I don't think so.
Rather, there aren't any published API's for it.
Google's voice search uses it, but that caused some fuss as they apparently used some unpublished functions.
http://www.iphonehacks.com/2008/11/iphone-app-news.html
EDIT:
To clarify, there are published API's allowing you to turn it on and off, but nothing that will allow you to detect when it has been triggered.
I was able to find this functionality in Apple's documentation here, however I haven't tried it yet.
The UIDevice instance also provides access to the proximity sensor state (described by the proximityState property). The proximity sensor detects whether the user is holding the device close to their face.