For example, I'd like to start the onboard datalogger when a user taps the device, and stop the datalogger when they double-tap.
TAP and DOUBLE_TAP are available in the /System/States -API. However simultaneous TAP & DOUBLE_TAP are not possible from the sensor, so to get both you'll have to do the following:
SUBSCRIBE /System/States/4 (4 == TAP)
When TAP event is received trigger a one_off timer (around 600-800ms is good)
If a second TAP is received before the timer is triggered, reset timer and forward as DOUBLE_TAP event
If timer expires without any TAP detections, forward as TAP event
Other things to consider are:
Users usually want some kind of feedback that the command went thru (e.g. LED blink or mobile sound). Without it they tend to try again and again.
It's a good idea to test the TAP sensitivity etc. with many test subjects. Each person tends to tap differently.
If the IMU (Acc, Gyro / Magn) are subscribed as well, the TAP detection works on the sample rate of measurement subscription. DOUBLE_TAP detection is not reliable with 13 or 26 Hz sample rates.
Full Disclosure: I work for the Movesense team
Is there any way to keep an Apple Watch awake for more than 70 seconds? I understand the purpose of turning off the face to save battery life but I'm trying to sample motion data continuously for about 3 minutes and the sampling is interrupted as soon as the face turns off. I've set the watch to stay awake for 70 seconds every time I tap it, but is there any way to prevent it from turning off for > 3 minutes? I found this post from Feb. of 2016 but haven't found any updates confirming or denying the possibility of preventing the watch face from sleeping in watchOS 3.
If you're looking at sampling motion data like the accelerometer or gyroscope, you can create a HKWorkout Session that will keep your app running in the background. While your Watch face will still eventually turn off without tapping, you will still continue to be able to keep sampling your motion data. Note that only one HKWorkout Session can be run at a time. Hope this helps!
I'm working on apple watch app using CMMotionManager and HKWorkoutSession to get both the accelerometer and the heart rate data. The app works fine for a short period of time (70 seconds), but when the screen is turned off, both the heart rate and the accelerometer data just stops.
My question is how could I get a 5 minutes data from both the accelerometer and the heart rate sensors?
To take more time when app is going to background you can use performExpiringActivityWithReason. This is described here https://developer.apple.com/videos/play/wwdc2015/228/?time=345 On my watch it just takes approx 30 seconds
NSProcessInfo.processInfo().performExpiringActivityWithReason("Reason") {
expired in
if !expired {
let delay: Int64 = 30
let delayTime = dispatch_time(DISPATCH_TIME_NOW, delay * Int64(NSEC_PER_SEC))
dispatch_semaphore_wait(semaphore, delayTime)
} else {
dispatch_semaphore_signal(semaphore)
}
}
Since the release of watchOS 2, HKWorkoutSession is the only way to keep an app running when the watch screen goes off. HOWEVER, the app is in a suspended state. Timers and any other process execution is paused until the screen turns back on. Memory allocations for the app however is preserved. During the time the app is suspended, the device's hardware is still collecting data and storing it on the watch's hard drive. When the screen turns back on the the app come out of suspension and any data that was collected by the hardware is returned at that point to the app (assuming the appropriate listeners were subscribed to).
There is not currently a way to continue to send heart rate data (or any data) from the watch to an iPhone after the screen turns off.
watchOS 2 does not allow apps to run while the screen is off. Although there are ways you can get a bit of extra time, such as with performExpiringActivityWithReason, there is no way to ensure that your app runs for a full 5 minutes.
Now, Apple open an API for recording your Accel data Click:CMSensorRecorder
. whenever your app is suspended or killed, the API will continuous run in 50Hz almost 3 days.
If I'm on iOS4, not using a specific handler, and needing the same update interval, what is the difference using the Device motion instead of specific Accelerometer, Gyroscope and Magnetometer updates ?
What happens if one of those 3 features is not available on the device if I use the Device motion ?
I mean, what will return deviceMotionAvailable if one of those feature is not available ?
In iOS 4 the magnetometer is not yet included in device motion API but handled by CLLocationManager (this changed in iOS 5). So if you have a gyro and an accelerometer, deviceMotioAvailable will return true independent of magnetometer. On the other hand if the gyro is missing you will always get false and you need to stay with accelerometerData.
Because Device Motion has one timestamp for both sensors, you will get reliable interpolated values for both sensors. Otherwise Device Motion wouldn't be able to do sensor fusion, the main advantage why this is the preferred way.
You can not rely on a fix frequency for CLLocationManager. didUpdateHeading is called whenever the system 'thinks' it should be. To get the different time coordinates between CLLocationManager and CMDeviceMotion normalised, you can have a look at NSTimeInterval to unix timestamp
Can the iPhone SDK take advantage of the iPhone's proximity sensors? If so, why hasn't anyone taken advantage of them? I could picture a few decent uses.
For example, in a racing game, you could put your finger on the proximity sensor to go instead of taking up screen real-estate with your thumb. Of course though, if this was your only option, then iPod touch users wouldn't be able to use the application.
Does the proximity sensor tell how close you are, or just that something is in front of it?
There is a public API for this. -[UIApplication setProximitySensingEnabled:(BOOL)] will turn the feature on. BTW, it doesn't seem to be using the light sensor, because proximity sensing would tweak out in a dark room.
However, the API call basically blanks the screen when you hold the phone up to your face. Not useful for interaction, sadly.
Assuming you mean the sensor that shuts off the screen when you hold it to your ear, I'm pretty sure that is just an infrared sensor inside the ear speaker. If you start the phone app (you don't have to be making a call) and hold something to cast a shadow over the ear speaker, you can make the display shut off.
When you asked this question it was not accessible via the public API. You can now access the sensor's state via UIDevice's proximityState property. However, it wouldn't be that useful for games, since it is only an on/off thing, not a near/far measure. Plus, it's only available on the iPhone and not the iPod touch.
Evidently the proximity sensor will never turn on if the status bar is in landscape orientation.
i.e, if you call:
[UIApplication sharedApplication].statusBarOrientation = UIInterfaceOrientationLandscapeLeft;
You will no longer get the proximity:ON notifications.
This definitely happens on OS 3.0, I can't test it on a 2.X device since I don't have one with a proximity sensor.
This seems like a bug.
The proximity sensor works via measuring IR reflectance. If you hold the iPhone up to a webcam, you can see a small, pulsing IR LED.
There's a lot of confusion between the proximity sensor and the ambient light sensor. The iPhone has both. The Touch does not have a proximity sensor, making it a poor choice for user input. It would be a bad idea anyway since Apple isn't obligated to locate it in the same place in future devices; you aren't supposed to know or care where it is.
The proximity sensor works by pulsing an infrared LED and measuring the amount of reflectance. You can see this using your iSight camera (most digital cameras are sensitive to IR.) Just launch Photo Booth, initiate a call (or play a voicemail) on the phone and point it at your iSight camera. Note the flashing light next to the earpiece; cover it with your finger and the screen will go black.
The ambient light sensor's API is evidently private at this point.
Just to update, this is possible.
device = [UIDevice currentDevice];
// Turn on proximity monitoring
[device setProximityMonitoringEnabled:YES];
// To determine if proximity monitoring is available, attempt to enable it.
// If the value of the proximityMonitoringEnabled property remains NO, proximity
// monitoring is not available.
// Detect whether device supports proximity monitoring
proxySupported = [device isProximityMonitoringEnabled];
// Register for proximity notifications
[notificationCenter addObserver:self selector:#selector(proximityChanged:) name:UIDeviceProximityStateDidChangeNotification object:device];
As benzado points out, you can use:
// Returns a BOOL, YES if device is proximate
[device proximityState];
There is no public API for this.
In iPhone 3.0 there is official support for the proximity sensor. Have a look at UIDevice proximityMonitoringEnabled in the docs.
If you aren't aiming for the AppStore, you can read my articles here on getting access to those:
Proximity Sensor: http://iphonedevwiki.net/index.php/AppleProxShim
Ambient Light Sensor: http://iphonedevwiki.net/index.php/AppleISL29003
Evidently the proximity sensor will never turn on if the status bar is in landscape orientation.
i.e. if you call:
[UIApplication sharedApplication].statusBarOrientation = UIInterfaceOrientationLandscapeLeft;
You will no longer get proximity:ON notifications.
This definitely happens on OS 3.0, I can't test it on a 2.X device since I don't have one with a proximity sensor.
This seems like a bug.
answered Jul 22 '09 at 5:49
Kevin Lambert
I've encoutered this problem too. It took me a long time to figure out the real reason of why the proximity sensor is not working. When orientation is UIInterfaceOrientationLandscapeLeft or UIInterfaceOrientationLandscapeRight, proximity sensor does not work; while in portrait mode it works well. My iPhone is iPhone 4S (iOS SDK 5.0).
Those proximity sensors are basically a matrix of conductors. The vertical "wires" are tracks on one side of a thin sheet of insulator, the horizontal ones are on the other side. The intersections function as capacitors. Your finger carries an electrostatic charge, so capacitance of each junction varies with proximity. FETs amplify the signal and biasing sets a threshold. In practice the circuit is more complex than that because it has to detect a relative change and reject noise.
But anyway, what the sensor grid tells you is that a field effect has been sensed, and that field effect is characteristic of object about the size of a fingertip and resting on the surface of the display. The centroid of the capacitive disturbance is computed (probably by hardware) and the coordinates are (presumably) reported as numbers on a port most likely brought to the attention of the device OS by an interrupt. In something as sexy as an iPhone there's probably a buffer of the last dozen or so positions so it can work out direction and speed. Probably these are also computed by hardware and presented as numbers on the same port.
#Dipak Patel & #Coderer
You can download working code at
http://spazout.com/google_cheats_independent_iphone_developers_screwed
It has a working implementation of proximityStateChanged a undocumented method in UIApplication.
Hope this helps.
To turn the screen off it's conceivable that more than one sensors is used to figure out if the screen should be turned off or not. The IR proximity sensor described by Cryptognome in conjunction with the Touch screen sensor described by Peter Wone could work out if the iphone is being held close to your face (or something else with a slight electric charge) or if its just very close to something in-animate.