An accelerometer measures changes in velocity over time along a given linear path. The iPhone and iPod touch each contain three accelerometers, one along each of the primary axes of the device. This combination of accelerometers lets you detect movement of the device in any direction. You can use this data to track both sudden movements in the device and the device’s current orientation relative to gravity.
Every application has a single UI Accelerometer object that can be used to receive acceleration data. You get the instance of this class using the shared Accelerometer class method of UI Accelerometer. Using this object, you set the desired reporting interval and a custom delegate to receive acceleration events. You can set the reporting interval to be as small as 10 milliseconds, which corresponds to a 100 Hz update rate, although most applications can operate sufficiently with a larger interval. As soon as you assign your delegate object, the accelerometer starts sending it data. Thereafter, your delegate receives data at the requested update interval.
Listing shows the basic steps for configuring the accelerometer. In this example, the update frequency is 50 Hz, which corresponds to an update interval of 20 milliseconds. The my Delegate Object is a custom object that you define; it must support the UI Accelerometer Delegate protocol, which defines the method used to receive acceleration data.
Configuring the accelerometer
The shared accelerometer delivers event data at regular intervals to your delegate’s accelerometer: did Accelerate: method. You can use this method to process the accelerometer data however you want. In general it is recommended that you use some sort of filter to isolate the component of the data in which you are interested.
Receiving an accelerometer event
To stop the delivery of acceleration events, set the delegate of the shared UIAccelerometer object to nil. Setting the delegate object to nil lets the system know that it can turn off the accelerometer hardware as needed, and thus save battery life.
The acceleration data you receive in your delegate method represents the instantaneous values reported by the accelerometer hardware. Even when a device is completely at rest, the values reported by this hardware can fluctuate slightly. When using these values, you should be sure to account for these fluctuations by averaging out the values over time or by calibrating the data you receive. For example, the Bubble Level sample application provides controls for calibrating the current angle against a known surface. Subsequent readings are then reported relative to the calibrated angle. If your own code requires a similar level of accuracy, you should also include some sort of calibration option in your user interface.
Choosing an Appropriate Update Interval
When configuring the update interval for acceleration events, it is best to choose an interval that minimizes the number of delivered events while still meeting the needs of your application. Few applications need acceleration events delivered 100 times a second. Using a lower frequency prevents your application from running as often and can therefore improve battery life. Table lists some typical update frequencies and what you can do with the acceleration data generated at that frequency.
Common update intervals for acceleration events
Isolating the Gravity Component from Acceleration Data
If you are using the accelerometer data to detect the current orientation of a device, you need to be able to filter out the portion of the acceleration data that is caused by gravity from the portion that is caused by motion of the device. To do this, you can use a low-pass filter to reduce the influence of sudden changes on the accelerometer data. The resulting filtered values would then reflect the more constant effects of gravity.
Listing shows a simplified version of a low-pass filter. This example uses a low-value filtering factor to generate a value that uses 10 percent of the unfiltered acceleration data and 90 percent of the previously filtered value. The previous values are stored in the accelX, accelY, and accelZ member variables of the class. Because acceleration data comes in regularly, these values settle out quickly and respond slowly to sudden but short-lived changes in motion.
Isolating the effects of gravity from accelerometer dataIsolating Instantaneous Motion from Acceleration Data
If you are using accelerometer data to detect just the instant motion of a device, you need to be able to isolate sudden changes in movement from the constant effect of gravity. You can do that with a high-pass filter.
Listing shows a simplified high-pass filter computation. The acceleration values from the previous event are stored in the accelX, accelY, and accelZ member variables of the class. This example computes the low-pass filter value and then subtracts it from the current value to obtain just the instantaneous component of motion.
Getting the instantaneous portion of movement from accelerometer data
Getting the Current Device Orientation
If you need to know only the general orientation of the device, and not the exact vector of orientation, you should use the methods of the UIDevice class to retrieve that information. Using the UI Device interface is simpler and does not require you to calculate the orientation vector yourself.
Before getting the current orientation, you must tell the UI Device class to begin generating device orientation notifications by calling the begin Generating Device Orientation Notifications method. Doing so turns on the accelerometer hardware (which may otherwise be off to conserve power).
Shortly after enabling orientation notifications, you can get the current orientation from the orientation property of the shared UIDevice object. You can also register to receive UI Device Orientation Did Change Notification notifications, which are posted whenever the general orientation changes. The device orientation is reported using the UI Device Orientation constants, which indicate whether the device is in landscape or portrait mode or whether the device is face up or face down. These constants indicate the physical orientation of the device and need not correspond to the orientation of your application’s user interface.
When you no longer need to know the orientation of the device, you should always disable orientation notifications by calling the end Generating Device Orientation Notifications method of UI Device. Doing so gives the system the opportunity to disable the accelerometer hardware if it is not in use elsewhere.
IPHONE APPS Related Interview Questions
|C Interview Questions||IPHONE APPS Interview Questions|
|Mobile Testing Interview Questions||Oracle apps Interview Questions|
|Java Native Interface (JNI) Interview Questions||JNDI (Java Naming and Directory Interface) Interview Questions|
|Mobile computing Interview Questions||jQuery Mobile Interview Questions|
|Mobile Security Interview Questions||Objective C Interview Questions|
|Mobile Developer Interview Questions||Mobile Application Testing Interview Questions|
|Apps Associates Manual Testing Interview Questions||Mobile Marketing Interview Questions|
Iphone Apps Tutorial
The Core Application
Window And Views
Graphics And Drawing
Text And Web
Files And Networking
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.