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.
Related
Just wanted to ask if there is any advantage for either using mouse click event or touch tap events, when writing apps for mobiles or tablets (for the iphone especially)?
I know that both of them should work fine, but in term of performance, is anyone better? Are there any things I should be aware of when choosing either?
By the way am using actionscript3 to implement the app.
This is probably the best documentation on Adobe AIR touch support:
http://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-6ffb37601221e58cc29-8000.html
Midway through that page it states:
Note: Listening for touch and gesture events can consume a significant amount of processing resources (equivalent to rendering several frames per second), depending on the computing device and operating system. It is often better to use mouse events when you do not actually need the extra functionality provided by touch or gestures.
The only benefit of touch, I would think, would be multi-touch. The TouchEvent has a touchPointID which allows you to track the movement of each touch point. If you don't care about multi-touch, it sounds like Mouse Events would be the way to go.
Excellent question! Tap events are "technically" slower as they monitor multiple input points. If your only concerned with a single touch input, the standard mouse event system is just fine. For touch events, there's a couple objects being created per listener to assist in handling the multitouch functionality (however this is close to a tiny fractional ms loss in performance).
i think that the touchEvent is better than mouseevent when implement the app on tablets!i try it many times!you can have a test
We are developing an app that has heavy GPS usage, and we are unable to optimize the battery life.
Even when the device is not moved, there is significant battery drainage that, according to the code, should not happen.
Here is the code:
locationManager = [[CLLocationManager alloc] init];
locationManager.distanceFilter = 100;
locationManager.desiredAccuracy = kCLLocationAccuracyHundredMeters;
[locationManager startUpdatingLocation];
Ideally we want to trigger GPS every 20 minutes (if there is no location change then save battery) OR every 5 minutes if there is location change. According to my developer this cannot be done
Previously we were using kCLLocationAccuracyBest, which was consuming battery very fast and now we are using kCLLocationAccuracyHundredMeters.
startUpdatingLocation - is to get the GPS coordinates. There is another call startMonitoringSignificantLocationChanges which is to get AGPS coordinates which I believe returns the coordinates whenever cell tower will change, and hence consumes battery really fast.
distanceFilter - The minimum distance (measured in meters) a device must move laterally before an update event is generated. On the basis of distance filter we get the GPS fix from the device and then we send the updated GPS coordinates to the server.
Any help will be greatly appreciated
Thank you!
There is another call startMonitoringSignificantLocationChanges which
is to get AGPS coordinates which I believe returns the coordinates
whenever cell tower will change, and hence consumes battery really
fast.
That's exactly what it does, but you're jumping to conclusions about the power required for that. The GPS receiver and WiFi transceiver can be used to help determine location, but they're extra devices that have to be powered to be useful. But mobile phones like the iPhone need to keep in touch with the nearest cell tower anyway in order to receive phone calls, so using cell towers as a source of location information should be very efficient with respect to power. Here's what the CLLocationManager reference page says about -startMonitoringSignificantLocationChanges:
This interface delivers new events only when it detects changes to the
device’s associated cell towers, resulting in less frequent updates
and significantly lower power usage.
It also describes the service as providing "tremendous power savings," so it seems the right tool for the job you describe. Of course, if you're also using the standard location updating mechanism at the same time you won't see that power savings, so make sure you're not using both.
Ideally we want to trigger GPS every 20 minutes (if there is no
location change then save battery) OR every 5 minutes if there is
location change. According to my developer this cannot be done
It sounds like there's some sort of misunderstanding here. You can certainly fire up the GPS every 20 minutes to get a fix if that's what you want, although you can't do that from the background. The significant location change service will notify your app even if it's running in the background, so perhaps your developer is talking about background updates.
Your belief that startMonitoringSignificantLocationChanges consumes the battery really fast is likely incorrect. Cell tower changes usually occur far less frequently than movements of 100 meters. And an iPhone checks for this event even when idle and all apps are sleeping.
However, keeping a cell phone on (e.g. Airplane mode off) when far from any tower (barely 1 bar) will drain the battery of the device whether or not an app is doing any location monitoring.
On stock iOS devices, an app cannot trigger location monitoring purely on a timer basis such every 20 minutes or every 5 minutes, without keeping the device on and your app running in the foreground, which will drain the battery.
If you require a good level of precision, you should startUpdatingLocation and as soon you get the first fix you should then stopUpdatingLocation and then startMonitoringSignificantLocationChanges.
This is enough for most app purposes.
Ideally we want to trigger GPS every 20 minutes (if there is no
location change then save battery) OR every 5 minutes if there is
location change. According to my developer this cannot be done
This could be done using an NSTimer that calls a startLocating (a custom method that creates the CLLocationManager and calls startLocating on it) method every 20 minutes. Make sure you call CLLocationManager's stopLocating once you've found a CLLocation with an accuracy of your liking.
However, doing so mean that for 20 minutes you might be using a location that is totally off. It depends on how you plan to use the location and how precise it needs to be, but maybe what your dev means by "not possible" is that your app needs the user's actual location at all times.
I made a board game with includes just some little animations. I reduced the fps from 60 to 30 to reduce the processor load. But the device still gets very warm.
Another application made without cocos2d is not heating it so much.
Are there any methods to calm the iPhone down?
The device state is as follows:
Wifi is always enabled
The app uses gamecenter
GPS is inactive
fps is always on 30
I use cocos2d-iphone as engine
It might be worth experimenting with different director types, e.g. kCCDirectorTypeNSTimer, and seeing if that helps at all. Those will have the biggest effect on the main loop of the game.
You should also spend some time with Instruments if you've not already, as that will show you where the CPU is spending its time and give you some hints on where you could ease things up.
I've noticed that a sequence of small time animations in cocos2d takes a lot of processor time. I've tried making tips at the level which will pulse in size. 0.1 second pulse up, 0.15 down and 0.2 stay. And i've put it all in a repeat forever sequence. Everything was terribly slow. Then i've just made the animation manually and the device calmed down and fps increased back to 60
When showing menus or dialogs that do not require animation, you can actually lower your framerate even further.
I'm trying to create my own loadbar; It consists of 5 bars, sliding in from the bottom from the left to the right, then sliding out to the top in the same order. There should be a fixed amount of time (say, 0.2 seconds) between all of them sliding in.
Currently, i'm using a timer to start them one by one, and then let themselves repeat. However, if there's some lag during start or something, they get messed up. The first two or sometimes 3 bars go almost simultaneously, the gap is bigger, just name it and it happened. I currently just set fixed times when each animation should start, but some lag makes them go bogus.
Any given bar moves up in about 0.3 seconds, waits there for 0.2 seconds, then moves further up in 0.3 seconds. They start 0.2 second after their left neighbour, from left to right. Once they started, they just repeat it.
So, what could i use to coordinate them in such a way, that there will always be the same amount of time between them?
Other things i have considered was just using a lot of images (but that will need lots of images i suppose), or using Key Value Observing (KVO) to see when the previous bar is at the desired height.
According to the NSTimer documentation, NSTimer objects are not guaranteed to be realtime accurate on iOS.
A timer is not a real-time mechanism; it fires only when one of the run loop modes to which the timer has been added is running and able to check if the timer’s firing time has passed. 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 during a long callout or while the run loop is in a mode that is not monitoring the timer, 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.
It's an issue that effects NSTimer as well as OpenGL based games. Michael Daley mentions something similar in his book about how to set things up properly for an openGL based game. I suspect that this is suffering from the same similar situation.
That said, I would suggest preloading those images a adding them to the view just outside the bounds or frame of the visible view before you need then so that they are immediately available when you need them.
Addendum:
After thinking about this, I'm wondering if the C function wait() will help you here. It's a long shot, but perhaps it's worth a try. If not, then the answer may very well be that there is none.
Addendum 2:
I have no idea if this is going to help you either, but I found this page, which discusses pausing a program for less than a second.
I have a camera application that uses my custom overlay on the UIImagePickerController object.
I am calling the takePicture method to take a picture when the user presses a button on my overlay view. Something like:
[imagePicker takePicture];
[self showProcessingIndicator];
The processing indicator is the usual spinning wheel that shows that a picture is being taken. I notice that often the camera does not take a picture immediately after the takePicture method is called, and the processing indicator is showing.
It seems that the camera tries to adjust its focus (if it is out of focus) and then takes a picture. This is probably the right thing to do. However, I have also noticed delay in taking a picture even when the camera is focused correctly and does not change its focus. This does not happen every time, and its hard to say when exactly it happens.
My question is: is there a way to force the camera to take a picture instantly, ignoring everything else? Also, is it possible that subsequent processing (showing the indicator view, for example) is causing the camera to respond slower on occasion?
Thanks!
I have also seen this and came to the conclusion that taking a picture is a reasonably resource-hungry operation in terms of talking to the camera device, allocating/moving memory, etc. While you can tune your application to not soak up any resources while this piece is running, you can't tell MobileMail, MobileiTunes, etc, to not check for email, etc, at that precise moment.
Is there any particular iOS version or device that this happens on more than others? Taking a picture on my iPhone 3G with iOS 4.0.x took up to 30 seconds, but is much improved on iPhone 4.
The activity indicator will soak up some resources, so this may be a candidate for removal and maybe just use sound instead. Test to be sure.