(Swift on Xcode 7.3)
I'm currently working on two independent iPhone apps, both of which use events fired by a repeating NSTimer.
Application A displays an analogue clock with a smooth second hand movement. The timer fires every second and advances all three clock hands appropriately.
Application B displays a weather forecast which is updated every fifteen minutes, after first checking the iPhone's current location.
The question is, is using NSTimer for each of these apps an efficient use of the iphone's resources? If not, what alternatives are available for firing regular events.
(The long term plan is to combine both of these iPhone applications - once they have been refined - into a larger iPad application.)
Related
I am writing an iPhone game. When the user makes his first move a timer kicks of with an interval of 0.01 seconds. A UILabel displaying the time also gets updated every time.
I noticed when testing on an iPod touch 2nd gen and an iPhone 3GS that the iPod was slower (after 20 seconds the iPhone displayed 00:20,00 and the iPod displayed ~00:10,00). Is there a way to make this more reliable? If I'm correct, the NSTimer should run on its ow thread and should not be blocked by user interaction.
JNK
The NSTimer documentation states:
Because of the various input sources a
typical run loop manages, the
effective resolution of the time
interval for a timer is limited to on
the order of 50-100 milliseconds. If a
timer’s firing time occurs while the
run loop is in a mode that is not
monitoring the timer or during a long
callout, the timer does not fire until
the next time the run loop checks the
timer. Therefore, the actual time at
which the timer fires potentially can
be a significant period of time after
the scheduled firing time.
So accuracy can be as bad as 0.1, not 0.01 seconds. Not to mention if your thread is blocked for some reason. So if your firing time is crucial you should be looking at other things. Read this SO post for kick-off. Apple had a metronome sample code (in which, obviously, timing is crucial) but I can't find it just now.
In any case, if you are implementing a timer with NSTimer, you should record your start time. Then, whenever you update your interface, simply take the difference of the current time and your start time (with NSDates).
make sure you're not basing a timer off of sleeps or delays. You should always update a timer based on things like number of clock ticks since program start or current time
sorry I'm not more familiar with your language
You can't rely on a timer to run exactly at the specified time intervals, so the time you are displaying should always be calculated by taking time interval differences. And I doubt that a timer on the iPhone can run every 1 ms, in Quartz it is possible to get a timer call every 16 ms or so, making 60 fps - so scheduling it at 1ms probably means "run as soon as possible", which might be quite different on different hardware.
I have developed a test for iPod/iPhone (with MonoTouch if that is relevant) that measures reaction time. But I need to take into consideration the time between touching the screen and actual triggering of the button event. Is there any documentation of that?
It's already very hard to almost impossible to get predictable interrupt latency on real time operating systems.
But on the iPhone? Imho impossible. A capacitive touchscreen is not optimal to get results that are exactly the same for each body and location. And if mail.app decides to poll for emails just at the moment you'll touch the screen there will be a bigger delay.
But to make one thing clear, we are speaking about some micro seconds or even less than that.
If you want accurate results you shouldn't use an iPhone. But I guess your app will be some kind of game, so nobody cares if your result is 0.01 seconds off. But I wouldn't show results as 0.381829191 seconds, that fakes accuracy you'll never get on any smartphone.
What is the lowest reaction time you got in your app?
The time between an actual touch and the system registering it will be negligable.
One key thing: if you are detecting the press using touch events like touchUpInside, consider using the touchesDownInside event because touchesUpInside, will not fire until the user's finger leaves the screen.
This is an embarrassing question but it involes Xcode and the iPhone SDK.
Why would I need to set more than one timer? And do 2 timers take up more 'tics' than 1 timer or are they all based on the same master internal clock?
Is it better to add 1 timer routine and just have it call all the things I need to make happen or have 5 or 6. I'm not new to programing but I'm completely new to xCode and just trying to wrap my head around it.
Eg. If I have a timer updating the clock on the screen, and I also want to update the GPS position, is there any reason not to have the same timer update both?
Thank you.
One is that timer delegate will operate in separate threads. So in your case, when only one timer is used, if the GPS acquisition takes to much time, your screen will feel unresponsive because the clock will be unregularly updated.
I am trying to made a musical iPhone application and I am having some problems playing looped samples.
I have read this question:
audio-on-the-iphone
and several other posts and blogs in the web about the "RemoteIO"/AudioUnits framework but without success.
I have been able to do a sample application that plays a finite sound with a predefined duration (I am using a playbackCallback) but I need the sound to start playing with the user touches the screen and stop playing when the user lift the finger.
Any ideas?
Thanks in advance.
Assuming your code is correct, you're probably omitting one (or more) of these steps:
Stopping reading/writing at the wrong times (because you're likely writing 'a power of 2' samples per render call)
Not providing a fade in/fade out (start at 10 ms fade out and adjust as desired)
Not stopping write on a zero crossing
not resetting the read position to 0 when the user lifts their finger - resuming in the middle of the sample
Your samples are not properly trimmed to zero crossings at start, end, and/or loop positions
Not resetting internal effects, filters, or convertors
You will not need all of these to avoid clicks.
I'm using the cocos2d framework for various of my applications, and have run into the following problem. I have set up a few sequences of actions and CallFuncNDs, the actions have durations set up and when I run it in the iPhone simulator, it works just like I expect it to: transitions take the amount of time I set them to and they go in the correct order.
When I test it on my provisioned iPhone, it all plays out in less than one second. Correct order, timing is proportional between actions, but it's all compressed into one second.
Any one have any idea why the cocos2d animations would behave differently on a device? My code is all set up similar to the cocos2d effect demos, with the difference that I am animating a ParticleSystem and not a Sprite - though the problem still shows up with Sprites.
I have experienced similar difficulties where testing the code in the simulator, it runs flawlessly. But when moved over to the device, the timing appears to be off. I've attributed this difference to the Simulator's use of the desktop CPU and Memory, where as the device is utilizing it's physical hardware and the timing is off because of how Cocos2d processes things (frame by frame, in a 'game loop'). When you start doing a couple things, the frame rate drops and Cocos miscues ... especially when you have schedules that run extremely close to each other, or schedules that cancel themself and reschedule with different timings (in increments as low as 0.1 and below is where I've run into this the most).