I am developing a chronometer app for iPhone which will used by the drivers in races. There will be a countdown. If user receives any call, in that case, the countdown will be paused. so I thought if user run his iPhone in Aeroplane mode, then he will not receive any call. But my problem is that, User will also have to send the data to the server during the race. But in aeroplane mode, it can't be done. I thought that user can divert the calls, it may work but is there any other better way for this or this is the only way? If I am not clear please let me know.
No, there is no other way then with the divert calls, you will need to be connect to the cellular network to send/receive data. On GSM G3 connection you can send data and place a phone call at the same time, on verzions CDMA G3 network you can't.
Related
I am trying to allow a user, who is running my app, to send a contacts vcard (vcf) via bluetooth to another iOS device.
The problem is, that the receiving device should not be required to run the same app.
Is there a possibiliy to accomplish this?
If there is not - is it at least possible to have Gamekit to establish a session, when the receiving device is running the same app, but without requiring the (receiving) user to start the peerPicker-dialog?
Any help and hints are appreciated!
First option: seems to be impossible.
Second option: Works. I implemented a GKSessionDelegate for receiving incoming connections. This session is startet together with the app.
For establishing the connection with a receiver, I used the well known GKPeerPickerControllerDelegate.
One remainig problem is, that the sender sees itself in the list of available peers (because it has also a receiver running in the background). My solution for this is to set its GKSession.available=NO, as soon as the sender starts its GKPeerPickerController.
I want to connect a robot, via Bluetooth, with an iPhone (4S or more) via Bluetooth low energy (BLE) 4.0. This robots require to send all the notifications of the iPhone to the device.
For example: If the iPhone gets a new email, I must send the event to the robot, and it will blink an LED. Stop.
I want to know if the iOS Bluetooth APIs of the Bluetooth framework can do this, or better, can share the Internet connection or whatever that can do this work.
I'm asking this, because I have heard that the APIs have some restrictions.
PS: ANY solution that can do this is very accepted (no Wi-Fi connection solution).
Bluetooth LE would be the way you want to go here, because standard Bluetooth requires your device to be MFi-compliant. Standard Wi-Fi could also work, if you're able to require the presence of the supporting network.
As of iOS 6.0, you can set up your iPhone as a Bluetooth LE peripheral, which would allow it to send notifications to your device, if it is configured in a central role. That would be a pretty power-efficient way of updating your device with new data.
However, there's one large hurdle to doing what you want here. iOS applications have no access to system-wide notifications, so you won't be able to listen for incoming emails or other notifications like that. You'll be able to send data to your device via Bluetooth LE, but you're not going to know when emails come in so that you could send that to your device.
With bluetooth 4, you could control a robot, as well as create a "notification" bot. It could be done quite easily. However as mentioned, you can't access system wide notifications in iOS.
However, you could use an external solution to listen for system notifications and then an API to listen a singular encoded notification and have your app listen to that.
One such system is https://ifttt.com (no affiliation)
There are also some great plug and play BLE options for rapid prototyping.
You can do it. A simple solution would be let a phone check your email periodically. Don't rely or try to use external Apple applications to do that, but use services provided by your mail.
In the case of Gmail, try to go to https://mail.google.com/mail/feed/atom. If you are logged in your Gmail, you will see the unread mail in XML format. The way you would login using a URL is: https://username:password#mail.google.com/mail/feed/atom
So what you can do is periodically parse the output and when <fullcount>0</fullcount> value changes call your robot service via BLE which should act as a callback for this specific event.
I would like to send a messages to all iphones or blackberries or androids that are using my local wifi. Whether it be a bbm or a flash sms etc.... I am even willing to pay for texting etc....
Can I do so without knowing their number? Can I determine their number from their information (ie: mac address and or phone id) being sent a request for phone information?
I appreciate any help. I have a feeling like it is not possible for many reasons, but I am curious....
Overall there is a way to do it, it's called "broadcasting" (or UDP broadcasting). Your wi-fi AP should support and allow it. You also must make sure Android, iOS and BB support this (but there is no reason why they shouldn't).
It looks something like this:
Install your custom app on all devices.
When device is connected to specific wi-fi access point, you send broadcast message "device X is connected, my address is XA, send messages to port XP" every several minutes. You also start listening for such notifications from other device.
If another device is connected, it will send "device Y is connected, my address is YA, send messasges to port YP". Device X will receive message from device Y, and device Y will receive message from device X.
When third device is connected, it sends "device Z is connected, my address ZA, send messsages to port ZP". This Z device will eventually receive messages from X and Y, while X and Y will become aware of Z device as well.
You'll probably need to implement simple TCP protocol in order to actually send messages from one device to another.
To summarize, you'll need to make discovery via UDP and communication via TCP. Those would be two different custom protocols. And it shouldn't be hard to implement. But you'll need to implement this for all mobile platforms you are interested in.
No, it's not possible (not for the Blackberry at least unless you're the NSA, since the BBMs are encrypted and operate on RIMs internal proprietary network before they even get out to any other carriers).
For the iPhone and the non-military Android phones, you'd just need to purchase your own private cell phone repeater/tower. That at least is feasible (although quite unpractical and highly risky), one guy did it successfully at a security conference with every participant's signed consent and with an independent auditor present, but he was lucky he didn't get himself arrested.
You see, by saying that you want to send an SMS, you're automatically implying that you wish to use the SMS infrastructure (which by definition doesn't even operate on wifi, it operates on the cell phone infrastructure).
That being said, if you control the wifi hot spot, you could do something else that might get you 60% of the way there. You could force everyone who utilizes your hot spot to go through an initial web page, and through that, you could communicate to them (although, please be aware, this is highly annoying to the user, at least it is to me especially on a phone).
I want to write an iOS app that can act as a client and a server to other iPhones over the cellular data network (i.e., without a typical centralized server). The goal is to share series of about 200 short event messages, one at a time, from the iPhone server to multiple iPhone clients by some means of notification. Apple Push Notification service would be fine for such notifications, but there is no need to use it specifically.
I think sending push notifications from one iPhone to another is possible by connecting to gateway.push.apple.com from the serving iPhone as described in the Local and Push Notification Programming Guide, but I can't find anyone else discussing this approach (maybe it's too obvious?).
The reason for all this is an attempt to avoid the overhead of infrastructure. If this isn't feasible, alternatives which minimize or avoid additional hardware are welcome.
Requirements:
Communication must be [strictly] over cellular data network
Wi-Fi isn't available
Bluetooth doesn't have enough range
Unidirectional communication with an iPhone server multicasting to many iPhone clients
No jailbreaking
Ideally the serving phone's battery will be able to handle this without a recharge
Update 5/4/11 2:12 AM EST: Just to be clear, I don't have any particular requirement to use APNs; I thought it may have been feasible in this setup, but from the discussion below, it sounds like that's not the case. However, I'm still interested in any other system that could help me achieve the same end result with some type of message passing or similar form of communication.
Theoretically you should be able to write a iOS app that can connect to the APNS and send notifications to other devices running your applications. However, your main problem will be to actually acquire the 'tokens' of other devices. When you have a centralized server doing the job, its always online and thus, the clients can 'talk' to it via http and register them self (giving their tokens to the server in the process). Thus the server knows the client token and it can use them to send notifications to the clients via APNS.
However this is not possible in the scenario you are talking about. But this is not to say its impossible. May be you could use an email account X, to store all client tokens. Every client will send a email to this account with their token in it. So when a another 'client' want to send a notification to another client, it can find out the token by reffering to the inbox of the email account (you can cache this stuff and optimize it in a zillion ways of course).
But the point is some how a (third party(ex: email service provider)/your own) server that is online 24/7 will be involved in the process.
Let us know how you progress with this. It would be interesting to know.
As far as I understand, the only way to place a call from an app is using the tel:// URL scheme, which launches the native phone app. But the Truphone app available on the App Store can place VOIP call even when there is no WIFI available. They say they do it by making a GSM call to their server and routing the VOIP packets over the internet from there.
Rerference: http://blog.truphone.com/2008/12/truphone-on-the-iphone-now-works-without-wi-fi.html
How can I do something similar in my app?
As far as the phone's cell hardware is concerned this isn't a call. Its just a 2 way data stream. They are activating the mic and encoding its input and sending that stream to their server, while they receive another stream and play it on the speaker. Their servers then decode the streams and then connect it to a normal phone system so you can talk to someone who doesn't use their service.
Do you want to allow users to contact people outside your userbase? If so that's going to require you to set up a server to decode your streams and then find a VOIP provider that has an API so your server can stream to them. This is possible but it costs.
If you only want user to user this can be done for free but its almost identical to the previous option, just take out the VOIP provider.