I was wondering how low battery alerts can be handled during a game. I used Cocos2D to make my game. I have the game pause when an interrupt such as a text or a call come in. But what about low battery alerts? Are they the same as other interrupts? It does not seem to be.
Is there any way I can detect when it comes up so that I can pause the game?
Thanks for your replies.
You can set up "battery monitoring" and get an event when this happens. Some links with info:
http://mobileorchard.com/new-in-iphone-30-tutorial-series-part-5-battery-monitoring
http://mobiledevelopertips.com/device/display-battery-state-and-level-of-charge.html
You know the event you're worried about is when it hits 20%, so I think you can just check for that amount and pause when it happens.
This is perhaps not a perfect solution, as Apple could decide it should happen at 25%, not 20%.
Also, Apple recommends turning this on only when you really need to know. So it should only be activated during gameplay, not on menus that aren't time sensitive.
Thanks guys. The problem however lied elsewhere. It happened to be a problem with one of the flags im checking upon resume. It should get reset when a user starts a new game, which I failed to do.
Lesson learnt: Be extra careful with global variables :) [I try to avoid them as much as possible]
I appreciate your replies and your answers. Thanks again.
Related
so i have built my first application in X Code using swift, and i have also taken the time to add the game centre functionality to it, however my question is, how would i delay the start of my game, in order for game centre to load, as of right now, the game starts, and then the game centre banner appears on top of my game before disappearing.
would it be sufficient to use something like, on the function containing my main game attributes:
NSTimer.scheduledTimerWithTimeInterval()
or
would i be better off adding a splash screen?
if anyone has any other suggestions, that would be helpful.
thanks in advance.
Better to subscribe under GameCenter, listen a complete event and then produce your next initialization. Avoid timers in similar situations, because time of processing depends from many factors, and rely to specific delay is not good idea.
If you are waiting for the game to load, then starting a timer is probably not the best solution, because you don't know how long the loading takes on different devices with different capabilities.
A better idea is to load your game and then have a completion method that is called to start the game when it is ready to be run.
I'm working an iPhone app called RealBaseball. If you're familiar with RealSoccer, it's pretty similar. It will allow you to play baseball with your iPhone with friends around the world.
When you hit the iPhone screen with your conductive bat, it should first detect the touch event then detect the acceleration so it knows exactly when you hit it, and how hard and how fast.
This is where I'm running into some technical difficulties. I have the standard touchesBegan and didAccelerate listeners. The problem is that didAccelerate is firing before touchesBegan. Clearly, something is wrong since it shouldn't start accelerating before the bat touches it. Could I be missing setup code?
I need to fix this, because if the timing is wrong, the batting machine on the other end will be laggy, and it won't be any fun.
Any advice you can provide would be appreciated.
EDIT: I added some NSLog calls with formatted [[NSDate date] timeIntervalSince1970]; Here's the output:
didAccelerate: 1364850400.03221
touchesBegan: 1364850400.21486
So you can see it's a small but clear difference.
How are you ensuring the bat is closing the conductive circuit from the phone to your hand? I'd suggest copious use of the material used to make gloves touchscreen friendly. Silver-threaded nylon is recommended here: http://www.howtogeek.com/130477/diy-touch-screen-mod-makes-regular-gloves-smartphone-friendly/
UPDATE: Oh, you might need to amplify the very tiny current that the bat will experience so it can travel all the way to your hand. I'm not an electrician but a portable car battery attached to the bat via the same thread should do the trick.
I have gotten a NSTimer to fire a selector every second correctly. However, I require it to continue firing even when it goes into the background. I have even tried the jailbreak tweak called Insomnia, which supposedly stops apps from sleeping in the background, but to no avail. So what would be the best way to achieve my objective?
Any help is very much appreciated!
There are only certain things you can do as background tasks in iPhone apps. The Apple documentation explains how it works and what you can do. The apps that use some of the background features don't continuously run - they are woken at 'appropriate times'.
Maybe this can solve out the ugly delay with touchesBegan: to touchesMoved:. It is caused artifically by iPhone OS to check if the user really wants to move. In some situations the finger must be tracked without delay, otherwise it just looks ugly. You see that everywhere through iPhone OS. Sliders, Scroll Views.
Maybe accelerating the system time makes the delay smaller.
You can set UIScrollView:delaysContentTouches to be NO, which will solve this.
You really don't want to change the system time to hack out something like this. Do you want apps you're using to screw up your calendar and alarms and your phone log, etc?
I asked a similar question, still open.
I don't think there's a way around it for now, seeing as even the ultra lickable "slide to unlock" slider suffers from the problem.
At this point I think the only solution is try smoothing this initial bump out with a bit of position interpolation.
I'm programming an puzzle game for iPhone using openGL.
There Is one very weird "bug" ( I'm not sure what It is)... whenever I touch the screen a great number of times in a short period of time my app closes, without giving a warning or error.
What could be the cause ?, I guess It has something to do with the memory, but I would like to know.
Edit:
I also think this happens because I'm calling multiple functions every time the user touches the screen or moves his fingers.
Sounds like you're running out of memory.
A few quick tips that might help out:
Check your memory profile over time using Instruments. If you see a steady incline over time, it's likely to be a memory leak, or an inefficient algorithm that is allocating more memory than you need.
Use a static analyzer to help check for leaks, such as Clang.
Images and image-related files are particularly memory-hungry, so focus on efficiency for them. When you work with textures in OpenGL, use the PVRTC format, which offers awesome compression.
didReceiveMemoryWarning: is your friend - aka a good chance to throw out anything you don't absolutely need in memory. Better to be memory-efficient the whole time, though.
Try setting up an NSUncaughtExceptionHandler. You may also want to setup a signal handler.