Does anyone know how (if possible) I can find out how much capacity (mAh) is remaining in an iPhone battery at any given time?
Something like the program above?
Is there a value stored in a plist somewhere??
couple ways,
pre 3.0 sdk: http://blog.coriolis.ch/reading-the-battery-level-programmatically/
with 3.0 sdk - the UIDevice batteryLevel property (example: http://blog.coriolis.ch/reading-the-battery-level-programmatically/#comment-4607)
to gauge the mAh you could check the battery level over time using that method.
3.0 has added an event to do that:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(batteryChanged:)
name:#”UIDeviceBatteryLevelDidChangeNotification” object:device];
in general, measuring the open circuit voltage or current is used to gauge the state of charge by the hardware. the capacity of the bat will shrink over time, so 100% will indicate no more charge can be stored, even tho the capacity is lower than a new iphone battery.
The UIDevice API includes a property relating to battery level.
Related
I am working on a mobile game, which appearantly crashes when the Low Battery alert is displayed. It works fine on low memory, incoming calls and other messages.
Its a pain to test and debug this, since I can find no terminal or iPhone simulator way of simulating this situation, so I have to charge my phone up a little bit, launch the app, wait for it to drain its power, and start all over again.
Does anyone know of a way to produce this error in a realistic way? Hopefully something that isn't too stressful on my iPhone battery.
Unfortunately, there is no good way to simulate a low-battery environment. You actually will most likely need to physically charge your device's battery until it is just above the "low battery" state and then debug your application.
To address what others have said:
There is no way to simulate low battery notifications. The project
that #Bo. provided does nothing more than schedule random
UILocalNotifications. It isn't all that much different than just
showing a UIAlertView in your app.
You could try what #Andrew R.
said and use the private methods found in the UIDevice header.
But it is doubtful that you will exactly mimic the effects of a real
low-battery environment.
Although it is a pain to have to wait for you device to actually hit the low-battery state, you could add some battery-draining code to your app to assist you. For example, using the GPS might drain the battery a bit quicker.
Good luck.
Did you try simulating the low battery notifications? There seems to be a project that does that: https://github.com/MegaEduX/LowBattery
Assuming this is for testing purposes only, you could give the following private UIDevice methods a try:
-(void)_setBatteryState:(int)state;
-(void)_setBatteryLevel:(float)level;
You'll have to experiment to see what parameters they expect, or whether they have an impact at all.
In iOS there is way to simulate "Low Battery"
Battery monitoring is enabled by setting to YES a property of the UIDevice singleton:
UIDevice *device = [UIDevice currentDevice];
device.batteryMonitoringEnabled = YES;
iOS provides two type of battery monitoring events, one for when the state changes (e.g., charging, unplugged, full charged) and one that updates when the battery’s charge level changes. As was the case with proximity monitoring, you register callbacks to receive notifications:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(batteryChanged:) name:#"UIDeviceBatteryLevelDidChangeNotification" object:device];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(batteryChanged:) name:#"UIDeviceBatteryStateDidChangeNotification" object:device];
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
Currently, I'm setting the volume to max, and then checking if the volume is at max, or a lower value. If it's at a lower value, then the user must have a Volume Lock on their system.
This works fine, but I'm wondering if there is some method to call, or property to check which tells me this in code for free? I've been looking online as to how to do this, but I can't seem to find anything. Thanks in advance!
Edit: It turns out that my previous method of setting the max volume and then checking if it's lower to see if there is a Volume lock does not work on the device. It seems as though the volume is scaled with the Volume lock, instead of just being cut off.
Now I'm completely stuck on this. Is there even any private methods or properties that I can use in order to detect this?
I think what you are asking for is to find out if the iphone has a cap on the volume limit. I have looked for the answer but could not find one. Here is a way just to check the volume level, hope this helps.
In your XIB you can add a slider to check what the volume level is at, so basically you can tell if it is silent, and know the level of the volume. For more understanding of this class, here's the link http://blog.stormyprods.com/2008/09/proper-usage-of-mpvolumeview-class.html but try this first:
The following code will create something like a volume bar.
- (void)viewDidLoad {
// create a frame for MPVolumeView image
CGRect frame = volumeViewHolder.bounds; // CGRectMake(0, 5, 180, 0);
volumeView = [[[MPVolumeView alloc] initWithFrame:frame] autorelease];
[volumeView sizeToFit];
[volumeViewHolder addSubview:volumeView];
for (UIView *view in [volumeView subviews]){
if ([[[view class] description] isEqualToString:#"MPVolumeSlider"]) {
volumeViewSlider = view;
}
}
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(volumeChanged:)
name:#"AVSystemController_SystemVolumeDidChangeNotification"
object:nil];
}
- (void) volumeChanged:(NSNotification *)notify
{
[volumeViewSlider setValue:[[[notify userInfo] objectForKey:#"AVSystemController_AudioVolumeNotificationParameter"] floatValue]];
}
I heard that for some reason apple doesn't allow you to sell an app if you use a certain class (the one in my example) but I'm not too sure about this, I would double-check and make sure that you are 'allowed' to use it. But the code should work.
There are many answers to this problem but they all seem to have fallen foul of Apple's guidelines or App Store curators at some point as Apple don't provide an official way to do this.
However one feature you can utilise to find this out is that when a device is muted then the OS will not play the sound at all - so if you play a 800ms sound file and you time how long it takes to play if it is less than 800ms then you can infer that the mute switch is on.
I would recommend to use a silent 800ms sound file to use this trick so that the user is not suddenly confronted with an unexpected sound.
See here for the article that inspired me: http://inforceapps.wordpress.com/2009/07/08/detect-mute-switch-state-on-iphone/
In addition you might want to use the Audio Toolbox to do this simply and guarantee that the mute switch is being used.
Consider setting the volume to max, then recording the output channel, and playing a short tone - then compare the peak of that recorded sample to a known sample where the volume limiter is not present. This will work if the iPad scales the output volume before recording gets access to it.
I wish I had more info on how to record the output, but I don't have much personal experience with it. Somebody who is versed in recording input should be able to point you the right way.
HI,
Is there any way to adjust the speed of the song being played by the MPMusicPlayerController?
I've searched everywhere but didn't find anything useful. If there is no way to do it where can I find an example which does it with other components? Some say OpenAL, but I can't find any clear way to use the iPod library with this and change the speed of the song...
Mainly the thing I need is:
The user chooses a song from the iPod library trough MPMusicPlayerController
You have 2 buttons: Slow Down & Speed Up
If the user presses "Slow Down" the speed of the song is slowed down by lets say 5% or something. "Speed Up" visa-versa.
I really hope someone can help me with this!
Thanks in advance!
You could do this as of iOS 3.2 and later -
[musicPlayer play];
[musicPlayer setCurrentPlaybackRate:2.0];
Ref: https://developer.apple.com/library/ios/documentation/mediaplayer/reference/MPMediaPlayback_protocol/Reference/Reference.html#//apple_ref/occ/intfp/MPMediaPlayback/currentPlaybackRate
You can use AVAudioPlayer and AVPlayer for the above purpose.
They have a rate property which can set the speed of the song.
[AVPlayer setRate:1.25]; // 25% faster
However, AVPlayer cannot change the speed by 5% but 25% and AVAudioPlayer works for iOS 5 and above.
If you wish to go for other alternative then Dirac is the best option. Try DIRAC 3 LE which is free.
Use this Link to get an idea on how to use Dirac. For more information, let me know.
#girish_vr
No, you can't do this using only the MPMusicPlayerController.
If you don't mind the pitch going up and down proportional to the speed changes, then you can use the OpenAL resampler after converting your sound file to raw PCM sample files or buffers.
If you don't want the pitch to change, what you are looking for is DSP time pitch stretching/modification/correction techniques. OpenAL can't do this, but there are commercial DSP libraries (DIRAC may be one) available that can do this on iOS. You could also try writing your own phase vocoder, but this is non-trivial digital signal processing code.
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.