I can't find any information on this but really need to know for sure if it doesn't happen, or if the documentation that proves it does happen is just too hard to find!
The background story:
When my app is running on an iPhone that has a weak 3G signal, and therefore switches backwards and forwards from a weak 3G to a strong 2G and vice-versa, it seems to freeze (the app, a complete freeze for 5-10 seconds). I have had reports of this from far and wide but it's something I can't replicate as my 3G signal is too strong in my area!
If I squeeze my iPhone 4 tightly, then I can dim the signal enough that I get an alert telling me that there is no cellular data network ... before it switches to 2G briefly. This DOES cause a freeze, and I tracked it down to the alert causing the app delegate method "applicationDidBecomeActive" to be called after the alert is dismissed, but no "applicationWillResignActive" as I had expected when thinking of the normal suspend/resume process.
I changed some of the logic in my code to deal with this, and that problem is now resolved.
The question:
Are any app delegate methods called when the phone switches from 3G to 2G and vice-versa? Does the app momentarily lose it's active state and then regain it like it does in the above situation? The problem above seems to replicate exactly what my users are experience EXCEPT from the fact that I get the "no cellular data network" alert which obviously changes things a bit. They don't get this alert, but they still get the freeze.
Thanks
You might be able to track this using Reachability.
You can find it here.
Related
I am working on an OpenGL application for the iPhone...
My app has only 2 views:
An OpenGL view and, as a subview for the OpenGL view, a view with the sole purpose of catching touch events...
The problem is that after about 10-15 minutes of keeping the app running on the device, I get a big (0.5s-1s) delay between every touchesMoved:withEvent: call
The animation runs smooth, and CPU usage is also not the problem (10% at most)
I have no idea what might be causing this
That is weird, eh.
This happens ON THE DEVICE right? When you are not running tethered from XCode?
I would guess you are using up a lot of memory, either a leak or just in some way using up more and more memory as time goes on.
Are you familiar with the various memory tools to watch what is going on?
Also, what about this: launch a few other large apps that remain in the background. Run your app until the problem exhibits. Then, kill the other apps. Does the problem suddenly go away? If so that would suggest you're low on memory.
Would be interested to hear.
So I׳m trying to play some effects in my Cocos2D game using SimpleAudioEngine , but after I have added them my app crashes when it goes to background (multitasked).
I searched for this problem in the internet but all the solutions that I found didn't work for me. What I did find out is that this problem happens because my app is somehow trying to play sounds when backgrounded.
In console it shows me (which is the same error I found other people had):
sgx error (background gpu access not permitted):
And another thing, when I run my app on the simulator, or even on my device while debugging carefully (going line-by-line with XCode while the app is running) this doesn't happen.
I just had this issue. I resolved it by having a bool to check if the app is running or in background that I set to true when the app goes to foreground ( applicationWillEnterForeground ) and that I set to false when the app goes to background ( applicationDidEnterbackground ) . So using the bool you can tell if the app is in the background and if it is, I just exit out of drawView function in EAGLView (thus not doing any graphics rendering which was causing the error).
I am a very dodge programmer but that method has worked for me and I hope it works for someone else. I did not need to unload and reload my sounds or anything and my app now has Multitasking XD
I was experiencing this, on about 25% of the occasions that my application re-entered the foreground. Like you, when I removed the sounds, the problem went away. That is how I came across your question here.
I may have found a solution to this. I have made what appears to be an unrelated change, but the problem seems to have gone away. Now, when my app enters the background, I invalidate my main scheduled timer. When my app re-enters the foreground, I then re-schedule the timer (after reloading my sounds, which I completely shut down on entering background).
So far, the problem has not come back. I would be interested to know if this helps.
I just resolved this issue on my end. Here's what was wrong in my case and, from what I can tell from the other answers and comments on this page, many other people's case as well:
By default, when I started my project, CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->resume(); were both being called twice, once by (void)applicationWillResignActive:(UIApplication *) and (void)applicationDidBecomeActive:(UIApplication *) respectively in AppController.mm, and once by AppDelegate::applicationDidEnterBackground() and AppDelegate::applicationWillEnterForeground() respectively in AppDelegate.cpp.
Make absolutely sure that these methods are only being called once, in AppController.mm. In AppDelegate.cpp, instead make sure that you are calling CCDirector::sharedDirector()->stopAnimation(); in place of CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->startAnimation(); in place of CCDirector::sharedDirector()->resume();.
Hope that's helpful to anyone else stuck in this crappy situation!
Are you sure it's related to audio? "background gpu access" sounds like it's using OpenGL.
I had the same issue in my application and spent some 4 hours to find out. Going background was OK the first time, but crash application the second time. With a short error message related to OpenGL. I had the same questions: how audio can crash graphics. But it wasn't a question of audio, but a question of notifications...
I discovered that going foreground was creating 2 timers in my custom level meter class.
I had registered UIApplicationWillEnterForegroundNotification and UIApplicationWillResignActiveNotification. Then, going background invalidated only one, since I registered only on notification... That was it!
One need's count its notifications!
Occasionally in low-memory conditions the UIImagePickerController I use gets 'stuck' with the shutter closed. Generally when this the WatchDog is allready jettisoning other background apps so within a second or two the low memory condition is over, yet the UIImagePicker controller is still stuck.
Has anyone else encountered this and implemented any sort of workaround or found a way to detect when the picker is in this state, so that it can be removed and a new one put in its place.
Thoughts / Ideas / Solutions??
Have you tried allocating (and then freeing) a megabyte or two of memory using malloc() before starting the UIImagePicker? Or claim it slightly earlier in your app, and then release it when you want to show the picker.
I guess you should be able to see roughly the amount of memory UIImagePicker needs to run successfully by running your app inside of instruments.
Whilst not ideal, it should cause other apps to be given memory warnings earlier on and hence the UIImagePicker should then have enough memory to run.
That's a known behavior of the camera application too. I guess you can't do anything to it except freeing as much memory as you can before starting it. You could raise a memoryWarning yourself so every application will receive it and start freeing memory but I have no idea how I can do that. I started investigate sending the notification myself (UIApplicationDidReceiveMemoryWarningNotification) without success. I guess we need to send an object along the notification to define the warning level but I'm really not sure.
I'm working on an iPhone game using OpenGL ES. I recently updated my iPhone 3G to iOS4, and ever since the update, when I've been play-testing my app I've been getting very high latency on my accelerometer and touch events -- my phone will often respond a second later than it should, which makes the game unplayable. This doesn't occur all the time -- about half the time the game works perfectly. I've set up the accelerometer following Apple's guidelines; one of my view controllers calls [UIAccelerometer sharedAccelerometer] in its init method and implements the appropriate delegate method which just grabs the x-component of the UIAccceleration object, and I have another view connected to a view controller that detects touches using touchesBegan:withEvent: and the other touch event handlers.
I emphasize that this worked fine when I was running 3.1.3. I'm totally stymied. Has anyone run into this problem before? Is this a known bug with the 3G and iOS4? Should I update to CMMotionManager?
I think it's been widely reported that 3G and iOS4 don't play nicely... very sluggish lack of responsiveness over all. You would be wise to do iOS4 testing on an iPhone4 or 3GS.
Touch events shouldn't lag. What you might be experiencing is some form of render lag (not sure how deep the render pipeline, but in many PC games it's noticeable at not-so-low framerates), which feels like input lag.
Apart from that, I dunno. CMMotionManager produces much nicer data, but only works on iPhone 4 IIRC.
When my iPhone app resigns active status, the sharedAccelerometer singleton instance of UIAccelerometer stops sending accelerometer:didAccelerate: messages to my delegate.
Is it at all possible to continue receiving those messages, similarly to how the CLLocationManagerDelegate continues to receive updates when the app is inactive?
I would prefer not to have to disable the idleTimer altogether if it can be helped.
No, not in the most recent available form of the iPhone SDK at least.
I would say that it is possible since this app is on the AppStore:
However, since you move differently in
bed during the different phases, the
Sleep Cycle alarm clock is able to use
the accelerometer in your iPhone to
monitor your movement and determine
which sleep phase you are in.
I can't believe it has to run all night with the screen turned on. EDIT: looks like it has to! :P
So they haven't got around that issue either. More chances that you can't achieve it then...
Have you read the documentation of the UIAccelerometer, does it mention anything there? If it just stops sending acceleration events there is not much you can do.
I would however try to set the accelerometer delegate again to my class when my app has lost focus (when the phone got locked). You can get that notification (lost focus notification) from the UIApplication. Try that just in case the accelerometer's delegate gets set to nil when the app loses focus.