In an iPhone/iPad app we would like to enable upload of a picture if the user is on wifi or 3g, but not on edge because it will take way too long. I've seen ways to detect if you're on a carrier network or wifi, but is there a good/simple way of detecting which kind of carrier bandwidth you got, like edge OR 3g? Has anyone tried timing the download/upload of a small sample file to test carrier bandwidth? Is it a good idea to test this or just go with a "cancel upload" button the user can click on if running out of patience?
People can drop from 3G to EDGE just as they have tapped to start uploading, or gain 3G, LTE or Wi-Fi coverage just after deciding not to upload. In the real world, the bandwidth can remain stable, yes, but it can also change a dozen times in a few minutes when you're on the move.
I think you would be better served by just allowing the picture upload in any case, informing the user if the upload is slow and letting them cancel at any time. If the model permits it, you could let the image upload run in the background and come in late.
It seems that you can only detect what network type user uses: wifi or 3g/edge (here is sample). If you want to detect the actual speed you'll need to test actual connection by hand.
As for me it is beter to provide "cancel upload" button and do not hurt users with slow internet.
Related
Hopefully someone can help me with this unusual issue. We have a platform that records 1-minute videos, one after the other, on iPhones and uploads to an S3 bucket. We've been using it for some time without issue, but our typical use case was with 1-3 iPhones (recording and uploading). But then we started doing tournaments with 15-20 iPhones. The bandwidth at the facilities are more than sufficient, typically with Gigabit fiber connections. The wifi we relied upon was also good, as we operated out of a prioritized vlan. But when we did this the system essentially overloaded the wifi and we couldn't even surf the web. We setup a different wifi network entirely, and that too didn't work (we had 150-200Mbps to each recording iPhone). But ultimately what did work was us bandwidth limiting each iphone at the router, limiting each to 10Mbps (which was more than enough to upload a 1 minute video file within the next minute). So that solved everything. The theory is that each iPhone was trying to use as much bandwidth as it could to upload, and thereby a few iphones crowded others out. When we throttled the bandwidth, no phone could consume the upload pipe, but had enough upload bandwidth to complete the upload within 45 seconds.
Problem is that setting up a parallel wifi network and setting up bandwidth limiting at the router for each recording iPhone is unrealistic in most settings. So we want to limit it at the device, hopefully using some feature in AWS SDK for iOS. I found some options for AWS, but none that were for iOS (on for C++). Anyone have any ideas? Thanks in advance for your help.
One think I tried was using low data mode on the iPhones but that didn't work.
I am developing an iOS application that the user will be able to upload a movie to vimeo. I don't know to manage the case that during the upload the network changes from wifi to 3G (or GPRS) or vise versa.
Is it possible to handle the upload correctly without pausing or killing it and not having to write "ugly" code?
iPhone handles these network handoffs seamlessly without interaction from the app. In other words, it happens at a lower level so you don't need to worry about it.
We created an external iOS notification light that uses the device’s audio for power.
When you get a phone call on iPhone and the light is plugged in, you still get the ringtone but when you pick up, the audio is rerouted to the headphones (the iPhone thinks our light/device is a headphones set) and the user has to extract myLED for at least 2mm to get the audio from the front receiver of the phone.
We have been exploring alternative solutions to this challange - recently we made a prototype with a particular jack shape so that it could be rotated by the user when getting a call to "reroute" the audio to the iPhone speaker/mic.
Although it may sound a clever option, this hardware solution is far from being neat - this leads to having positions where the myLED does not work/ it is not reliable, plus other complications.
I know of the existence of kAudioSessionOverrideAudioRoute_Speaker however I suspect that this will only direct the app audio to the rear speaker (the “loud” one) and not to the front receiver (because the “receiver” for the iphone is the headphones set if they are detected).
What would you suggest?
Super appreciated!
I think you're in a tough spot:
It's highly unlikely Apple will ever release the option to override audio routing for phone calls. As a key functionality of the phone, they tend to keep the call aspect under lock and key.
The headphone jack (probably - this is how most of them do it) uses the impedance between ground and one or both speakers or the remote control to determine if the plug is in. Other than breaking the circuit, there is no good way to simulate this.
The only options I think you have are these:
Require the user to remove the device when a call comes in.
Provide a microcontroller on the jack to drive a transistor; this transistor can electronically break the circuit to provide the same sort of impedance signature as an unplugged jack.
How, when, and if you can provide the information to the jack that a phone call is in progress is beyond my knowledge: is there an API for "incoming but not yet answered call" you can hook to? Will you have to do a watchdog thing to ensure communication with your app? Would it be possible for you to use the dock connector instead? I think these are really your options. Not a complete answer, but those are my thoughts.
In other words lets say I have an app that allows users to create their own data (like the camera app), what happens when the picture that is taken exceeds the remaining memory on the device ?
That's up to the operating system to handle those situations. Remember, a phone, smart phone, works pretty much like a computer. The same way your computer would notify you that is running out of available space... or an error that can't copy... look into the developer API, there should be a way to handle this exceptions.
There are 2 iPhone applications. One application running in the foreground and the other running in the background. Is there any way to get the background application to send data over USB without coming into foreground? Ideally we want to keep the foreground app in the foreground, while the background app process some data. Once the data is processed it will inform the foreground app that the data has been processed.
No it cannot. It cannot even do this without the use of private frameworks, unless you're in the Made for iPhone program. If you are, then your organization will know, based on the documentation made available to you, what you can and cannot access, when and how.
Should you be in the Made for iPhone program, and are unclear as to what you have access to and when, contact the person in your organization who is the technical contact with Apple for this program, they will be able to give you the details.
If the task is started while the app is in the foreground and you call the appropriate beginBackgroundTask/endBackgroundTask methods, you should be able to have it continue running after the app is backgrounded.
Note that access to USB is restricted (see jer's answer) and that there's no officially sanctioned way to communicate between different apps on the same device. Also, you can only buy/download one app at a time in the App Store and I can't see Apple approving an app that required you to download a second app for it to work. So you may have bigger problems to solve first.
It would help significantly if you told us what you actually wanted to achieve. For example, "I want MyApp on the user's phone to communicate with MyApp on the user's computer".
The absolute easiest way is to send data between the phone and a computer is to require that they're both on the same Wi-Fi network. Several iPhone apps incorporate a web server (this was the easiest way of "file sharing" before OS 3.2), and many more iPhone apps connect to a computer running server software.
Your other options, more or less:
Reverse-engineer the Bluetooth side of GameKit and reimplement it on the computer-side. I'm not aware of anyone who's done this. Loosely, I think it's IP over Bluetooth PAN plus some sort of Bluetooth service discovery.
Audio input/output, e.g. the headphone jack or certain pins on the dock connector. I'm not entirely sure how the mic side works (the resistance was a bit high for a carbon mic when I checked), but you might get lucky and find a way to turn it into "line in" or find "line in" pins on the dock connector.
A webcam pointing at the iDevice screen (and the iDevice camera pointing at the computer screen). Ewwwww.
Join the MFi program.