The release of IOS5 has this core function listed as deprecated. Does anyone know what will replace it? I'm assuming that apple is not going to remove the accelerometer from iPhone 5.
I did not yet use iOS 5, but already in 4.x UIAccelerometer and UIAccelerometerDelegate were replaced by the CoreMotion framework. It is more sophisticated, takes gyroscope signals into account and performs a sensor fusion i.e. does calibrating stuff like bias calculation for you.
Basically the CMDeviceMotionHandler block callback is now the equivalent. It is called every deviceMotionUpdateInterval seconds or you can go with your own timer loop and pull the data. It is pretty straightforward and easy to use. Look at Simple iPhone motion detect and follow the three links to the SDK docs.
There are three things you have to bear in mind:
Working with Device Motion requires iPhone version >= 4 or newest iPod touch generation because it relies on gyroscope support
When using Device Motion you must not use low pass filtering to extract gravity because it is done for you
If you want to support older hardware, you have to work with raw data. This is done by creating a CMAccelerometerHandler and calling startAccelerometerUpdatesToQueue:withHandler:. Then you have to extract gravity with low pass filtering like in didAccelerate
Related
I'm using the Geolocation API (often referred to as "HTML5 Geolocation") to get the current position of the user. It is updated automatically if you move (checked every second). Primarily targeted (and currently tested) at iPhones, but should work on other mobile devices too. You can see an example here:
http://jsbin.com/uyoyey/
The accuracy, which you can see in each line after the pipe, is around 3000 (meters) when I'm testing (outside). Which is quite bad obviously. The native Maps-App on my iPhone is way more precise. Approximately around 10 to 30 Meters (by looking at the map and where I am standing. Checking long- and lat-values in another app also gives more accurate numbers.
When I now switch back to Safari the accuracy jumps to 10 to 30 but reverts back to 3000 after a second.
Questions:
Can you replicate this behavior?
Why is the location so far off in the first place?
Is there a difference between accessing GPS-Data via Geolocation and CLLocationManager (which I think is used by native apps)?
Thanks!
Update 1:
I'm getting more accurate results when testing on other places (larger city) but am now wondering if the native Apps also use Motion Tracking to update the location. Which would explain why the Maps App can track my steps while Safari doesn't recognize them.
Update 2 (03.08.11):
In an email-conversation with Peter-Paul Koch he wrote that Safari mainly uses wifi for Geolocation to preserve battery life. Which may explain the differences.
Im still not entirely sure what is going on though.
Old: Here are the test result for getCurrentPosition function with wifi turned off on android 2.2, iOS4, and iOS5.
On both android browser and iOS 4 Safari, I'm getting GPS accuracy level in magnitude of 1000 meters. But on iOS 5 Safari, I'm able to get down to 5 meter accuracy. Seems GPS has improved on iOS 5, but it is just a small slice of the market out there. Overall, it is still not good to develop web app that relies on accurate GPS reading.
Something I found during testing - the android browser GPS stops responding after about 70 calls made to getCurrentLocation. This might be a device specific problem but it is another unreliable factor in browser based GPS functionality.
Update: I was testing with the watchPosition function call and it is produced much more accurate result on Android and iOS4. It the way to go... Sample code: http://jsbin.com/ugebif/3
I can’t, but only due to laziness :)
I’m not sure, but I suspect Safari is using the non-GPS parts of the iPhone’s location awareness.
Again, I’m not sure, but Dive into HTML5 mentions that the HTML5 geolocation API lets you pass a PositionOptions object to getCurrentPosition, and that this object has an enableHighAccuracy property.
Setting that to true might make Safari use the same high-accuracy positioning as CLLocationManager. (I’ve no experience with this myself though.)
I've written a small application for using the iPhone's 3GS-and-better magnet.
It is loosely based on Apple's Teslameter sample code.
What I've noticed is that on some iPhone devices it works.
On others, there's a first exceptional reading - and then, no more readings.
What's common to those problematic devices is that they were exposed to magnets longer that your average iPhone...
So, I'm wondering if (1) could this have "broken" the iPhone compass? (2) if yes, is there anyway to fix it? (3) is there any way to "reset" via software?
Thanks!
Is there any way to simulate CMMotionManager's gyroscope output in the iPhone 4 simulator? CMMotionManager's gyroAvailable seems to indicate that the simulator itself won't do it (which is understandable, given that it doesn't simulate acceleration data either), but I figured someone may have written a simple simulator drop-in for testing a project.
The new phone's are in short supply in my city so far and it would be nice to give things a reasonable work out in the meantime!
This is a pretty old post, but may give you a starting point:
http://ifiddling.blogspot.com/2009/01/dummy2.html
I would like to check if the user is using an iPhone 4 or not. How can I do that ?
Thanks !
Sebastian
Apple specifically recommends against this, instead preferring that you check for individual features and act according to these. This makes your life a lot easier when Apple releases new hardware; if for instance Apple releases an iPod Touch with a camera, and you need a camera for your app, your users wont be upset that it tells them "No camera found" when it does have one, all because it reports as not an iPhone. Here is one way to require all the differentiating hardware features. Do not use these for enabling/disabling features that are supported but not required: this can be determined at runtime through the APIs used to interact with that feature.
UIDevice (see here, also the docs) can help you determine if it is an iPhone, but again, don't do this.
To detect the difference between the iPod Touch and the iPhone, we use
if(![UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera])
There might be something similar to check for a the forward camera.
I'm looking for a way to differentiate at runtime between devices equipped with the new ARM processor (such as iPhone 3GS and some iPods 3G) and devices equipped with the old ARM processors.
I know I can use uname() to determine the device model, but as only some of the iPod touches 3G received a boost in their ARM processor, this isn't enough.
Therefore, I'm looking for one of these:
A way of detecting processor model - I suppose there's none.
A way of determining whether ARM neon instructions are supported - from this I could derive an answer.
A way of determining the devices total storage size - combining this with the already known device model could hackishly lead me to the answer.
< ENTER RANDOM IDEA >
Thanks in advance :)
Not exactly what you're asking, but one easy solution is to build your application fat, so that it contains executable code for both ARMv6 and ARMv7. If you do this, the appropriate code will run on the processor automatically, and you don't need to do any runtime checking. Effectively, you're letting the loader do the runtime detection for you.
To do this, change the Architectures setting in your XCode project from "Standard (armv6)" to "Optimized (armv6 armv7)"
Then, in your implementation, you do this:
#if defined __ARM_NEON__
// Code that uses NEON goes here
#else // defined __ARM_NEON__
// Fallback code without NEON goes here
#endif // defined __ARM_NEON__
There is a similar macro that you can use to check for (non NEON) ARMv7 features, which I can't remember off the top of my head.
If you really want to do runtime dispatch, take a look at the sysctlbyname function in libc. Specifically, I think that looking up the HW_MACHINE_ARCH parameter may prove useful to you.
One workaround I can think of, is detecting if OpenGL ES 2.0 is available, since the newer processors enable that.
There's an article at mobileorchard on how to do it.
EDIT: I have withdrawn this answer, as it left out a glaring hole I realized later: what to do when we get an unknown subtype on some future hardware? THIS WAS NOT FUTURE-PROOF. Also, the uncertainty of the documented status of that API doesn't help, given Apple's zero tolerance on usage of undocumented APIs.
You should use Stephen Canon's answer and build your application fat. Reliable, future-proof runtime detection is not feasible at this time (to my dismay, I assure you).
I know this is crummy, but the best that comes into my mind is detect if the device supports video recording. Currently only the ARM7 based iPhone and iPod devices support it, hence its a legit way, I guess.
To do so, use UIImagePickerController's availableMediaTypesForSourceType in conjunction with isSourceTypeAvailable on kUTTypeMovie.