I'm working on an app project for professional drivers.

Besides all the features we need to offer them, we need to prevent as much as we can our users to use the app while driving.

Can you think of any tricks to reach this goal?

For instance, I was thinking it could be blocked when the smartphone is not still (ie when you detect it's moving)? But if the sensor is not precise enough, it could make it impossible for the user to use the app while walking.

Maybe you could have to wire it to the car to use and you be blocked if the car is moving ?

Sounds silly, but it seems a pretty difficult thing to do...

EDIT : For this particular audience, we know the driver is alone (or at least, is not authorize to have any passenger)

It'll probably end up with a warning message, like in Waze if I remember well. But I was wondering if there were any other technology or idea around here.

  • 7
    The warning solution by @virtualnobi is a default for most GPS applications and a good solution in those scenarios. What tasks and behaviors is the app soliciting that a user might want to use it while driving?
    – Chromarush
    Commented May 20, 2014 at 14:04
  • 28
    What happens if the user is on a train?
    – mmmmmm
    Commented May 20, 2014 at 14:15
  • 13
    It's common enough for truckers to drive in teams of two (and sometimes three) so you should expect your application to be used in this scenario eventually, even if it is not right now. Commented May 20, 2014 at 15:57
  • 6
    What sort of professional drivers use their phones while driving and aren't fired for it?
    – Tim S.
    Commented May 20, 2014 at 18:26
  • 4
    Android's ActivityMonitoring API tells you if you're moving in a car. developer.android.com/google/play-services/location.html. Downside is, this is available only for Android phones.
    – gsb
    Commented May 20, 2014 at 22:18

26 Answers 26


Don't overdo this. How can you distinguish the driver looking at the app vs. the front passenger looking at it? Location / movement will be identical.

Navigation systems warn upon start up, "Don't do this when driving." That should be enough.

I think some thinking is needed in this world. As it used to be back in the times of caves and leopards.

  • 2
    Exactly. You will never stop bad things from happening completely, and if you push too hard, you will only cause them to become more frequent. Commented May 20, 2014 at 14:31
  • 62
    Caves and leopards are still around, unless I missed something recently... Commented May 20, 2014 at 14:43
  • 11
    Failing to look out for a leopard did not result in killing someone who was behaving as they should. If it were even theoretically possible that phones could refuse to be used while a person was driving, how many responsible, law-abiding citizens would not die from someone else behaving foolishly? Answer: a lot. cdc.gov/motorvehiclesafety/distracted_driving
    – BrianH
    Commented May 20, 2014 at 16:58
  • 28
    I, frankly, have never encountered a problem with users using a phone app in a cave while driving a leopard. YMMV. Commented May 21, 2014 at 15:39
  • 10
    @Bob: Can you say the same about a Jaguar, though?
    – Ben Voigt
    Commented May 22, 2014 at 3:24

Having worked on an iOS app like this previously, I'll just relay my experiences and some conclusions. Please note that all of these experiences are developing an iOS app which at the time more heavily sandboxed apps than Android apps. Know the platform you're developing for.

  • You can use GPS to determine if a person is moving, and that's about it. Using a person's current GPS location, you can compare it with the previous coordinate and determine the speed they traveled that distance within the time between the two points. The problem with GPS is that in order to accurately determine a person's speed, you need to be pinging for data points pretty often. Yet the more you use GPS, the more this burns through a person's battery. Also, while I'm not sure about iOS 7, I know within iOS 6, a developer couldn't be pinging for GPS coordinate more than once every minute or so (I believe) if the app was in the background. Having that much time between GPS pings won't give you very much accuracy in determining if the person is moving.
  • Remember to consider the app experience outside of driving. Be careful about asking questions every time someone opens the app to see if their driving. This could get frustrating and could develop into another problem...
  • Be careful to not inadvertently encourage bad habits with your app. That is, if you ask a user if they're driving, they respond honestly, and you shut them down but they really wanted to use the app. So the next time they might just say lie and say "No" in order to get to where your going. Now your data is dirty and unreliable. Every time thereafter they may respond with "No." Now you have a worse problem than before — people are using the app while driving and lying about it. People will figure out a way to get around rules.

It's a great goal that you're shooting for, but think bigger. You don't want your drivers to not use just your app, but you want them to not use any app, text message, or even phone call. Increasing data shows that distracted driving impairs a driver's ability. In fact the response time of someone responding to a text message is worse than a drunk driver. Texting while driving kills at least 11 teenagers a day, and the National Safety Council estimates at least 28% of all traffic crashes every year involve a cell phone. Most responses to this problem though are negative (disable the phone or app). Have you considered a positive response? Maybe some way you could reward drivers for not using their phone?

  • 9
    +1 for suggesting there might be a way to reward positive behavior. Commented May 20, 2014 at 17:05
  • @JonathanStrate, I can't think of such a method off-hand, but reward has been repeatedly show to be a better influence on behavior than punishment.
    – Brian S
    Commented May 20, 2014 at 18:12
  • 4
    +1 for answering the question, having references, relating real experience, and offering over all good suggestions.
    – BrianH
    Commented May 20, 2014 at 18:39
  • @BrianS Such a reward might have to be provided at the business level. Unless the application was gamified somehow in a non-obnoxious sort of way.
    – Travis
    Commented May 21, 2014 at 19:51
  • @PeterHorvath that's a side effect of trying to detect behaviour based on data that's not specific to that behaviour. Has nothing to do with Apple. Think powerboat racers, they go as fast as a speeding car, yet they're not driving.
    – jwenting
    Commented May 22, 2014 at 13:07

You say that your target audience is professional drivers. A professional should know better than to operate the phone while driving. (And if they do violate that bit of common sense, they'd have the skill to still avoid a crash.)

Instruct the user on startup to not operate while driving, and then trust the human element to not be stupid. The universe will always build a better idiot, of course, but the matter is out of your hands regardless.

  • 16
    "...then trust the human element to not be stupid" - um, please don't do that. Seriously. If there is anything one can learn from observing humans, its that we are universally bound to be stupid repeatedly, every day, no matter who you are. Countless major advances in user experience, human safety, product design, and possibly civil society at large, are based upon this fundamental realization. Rule 1) things go better when people behave as they should. Rule 2) people often do not act as they should. Plan accordingly.
    – BrianH
    Commented May 20, 2014 at 17:07
  • 11
    @BrianDHall, As I said, the universe will always build a better idiot. However, no amount of engineering will stop a determined idiot from using your app at an inappropriate time, and over-engineering the app to be fool-proof (ha!) will frustrate a normal user. Considering the target audience and the pitfalls in this task I don't believe it is worthwhile to spend effort protecting the user from something they shouldn't be doing in the first place (with your app or someone else's). A stop sign is good. A razor-wire fence is not.
    – Brian S
    Commented May 20, 2014 at 18:10
  • 3
    @BrianS I actually just think it is not established that, in this case, professional drivers are in fact more likely to behave properly. Perhaps this is drawing upon my experience working with people from the insurance industry, but dual cab cameras (inward and outward) weren't developed because professional drivers are just known to behave properly. I've also personally known truck drivers who used a bungee cord in their steering wheel so they could make a sandwich for themselves while driving down the highway, and who've had a passenger hold the wheel while they "caught a quick nap". Thus...
    – BrianH
    Commented May 20, 2014 at 18:59
  • 9
    Please don't confuse professional with competent. Being paid to do a task does not make one intrinsically better at doing it. I think the OP is perfectly correct in his underlying assumptions. (Speaking as an Advanced Driving tutor). Commented May 21, 2014 at 9:04
  • 3
    And a "professional carpenter" should know better than to get his fingers into a buzz saw, but it still happens and we have protection for that now. A "professional programmer" should never dereference a null pointer, but it still happens every day and we have now languages that catch that behavior and don't result in undefined behavior. And.. well I could go on until the end of all day, why this is handwaving. Heck never read about all those aviation and nuclear accidents that were caused by professionals due to bad design? Humans are imperfect, accept it and design for it.
    – Voo
    Commented May 22, 2014 at 13:47

Calculating the user's speed based on GPS and disabling the app when travelling above a certain speed sounds like the most obvious solution.

The OneProtect app, for example:

OneProtect technology blocks drivers from using their phones while in motion. Once your phone's GPS indicates your car is moving above a speed of your choosing — the default is 15 miles per hour — it will lock up

OneProtect also incorporates an "Attention Verification Test" which allows a passenger to bypass the block and continue using the app.

...which asks you to precisely tap on letters that appear on your screen in a short amount of time. The AVT is tested be essentially impossible for drivers, but doable for passengers.

  • 1
    Would you be checking this regularly? Otherwise the driver pretends to be the passenger at the start, and drives on... Commented May 20, 2014 at 14:11
  • @virtualnobi I guess it depends how strictly you need/want to police it.
    – Matt Obee
    Commented May 20, 2014 at 15:49
  • 4
    The speed-based solution by itself is terrible. I have been blocked from using certain apps while riding on the train, because the train exceeds (by far) 15mph -- yet in no way am I doing anything that could endanger myself or others.The "attention verification test", on the other hand, might not be a terrible idea.
    – Doktor J
    Commented May 21, 2014 at 19:39
  • 5
    The AVT sounds frightening. If a driver tries to do that while driving, it seems at first glance like they would probably crash.
    – Jim Dagg
    Commented May 23, 2014 at 16:23
  • 1
    @DoktorJ it is a terrible idea. The person already decided to be irresponsible and use the app while driving, what makes you think they won't attempt to do the AVT while driving?
    – Andy
    Commented May 25, 2014 at 15:29

Apple was awarded a patent earlier this year that disables certain functions on a mobile device based on the location of the driver within the car. An AppleInsider article on the subject can be found here: http://appleinsider.com/articles/14/04/22/apple-tech-takes-on-distracted-driving-blocks-users-from-texting-while-behind-the-wheel

The summary of the patent, from the article, follows:

The U.S. Patent and Trademark Office issued Apple U.S. Patent No. 8,706,143 for "Driver handheld computing device lock-out," a system that intelligently determines whether a device user is driving and shuts off distracting phone functions accordingly.

The patent is an interesting read. It talks about two methods to determine if the individual using the phone is the driver, or a passenger.

enter image description here

One of the methods discussed requires modifications to the car, using RFID to determine where the user is in relation to other elements within the vehicle (e.g., the wheel or ignition switch).

In your question you make some inference that you might have limited modification ability over the vehicle (you mention wiring the car). If this is the case, one such related solution might be a dongle on the phone (required to be present by the app) and receiver in the cigarette lighter (or whatever they call it these days, since they don't include the lighters anymore). Based on the proximity to that, you could figure out where they are in the car. Hey... I didn't say it was an easy solution!

The other method discussed in the patent related to a "scenery analyzer", and is a little more abstract in its definition.

One discussion uses the camera to determine when a device holder is in a "safe" or "unsafe" operating area. An example of this is given by the above linked article:

For example, the analyzer algorithm may find that a user is in the driver's seat by analyzing a photo or video that shows one face and a steering wheel.

Ultimately, the answer falls to what others have said on how much effort you want to (or can) put into the effort and how much we just have to rely on drivers being smart about what they're doing. To find the "unsafe operating area" would be very difficult and fraught with potential error and circumvention.

  • This answer has a few problems, on is that it relies on modifications to the vehicle and two the the approach suggested is being patented.
    – Andy
    Commented May 25, 2014 at 15:31
  • If you read the answer, linked article, and/or patent you will see an option that does not require modification exists. Regardless of patent status the solution provides insight into possible solutions - be they newly developed or provided by device providers (e.g., Apple). Commented May 25, 2014 at 15:57
  • Yes, the second option is so vague to be useless to the OP, and is also patented. Since it is, its value as a possible solution is limited.
    – Andy
    Commented May 25, 2014 at 17:50
  • From the OP: But I was wondering if there were any other technology or idea around here. - to which insight into an emerging solution was provided, that may be the ultimate solution (using a 3rd party system is no less "correct") or may get the asker going in the right direction. A reasonable answer format for UX.SE without being problematic. Commented May 25, 2014 at 18:09

I think the motion sensor showing a warning message should be good enough, like in Waze.

I don't think the app should be "responsible" in a way for not letting the driver use the app while it's moving because we can simply never tell what the scenario would be and the possible exceptions... Right?

  • 1
    This is a gray area right now for mobile applications. Legally can mobile app developers be held liable for distracting drivers while driving because they created an application that was designed to be used in the car?
    – Hynes
    Commented May 22, 2014 at 13:14
  • I think that would be very unfair. It would be like parents suing a movie company for traumatizing some kid with a horror movie since it is the responsibility of the parents in the first place to not let their kids watch such a movie (given the R rating)...
    – guzforster
    Commented Sep 3, 2018 at 12:57

This would only work with vehicles with bluetooth technology, but you could tie it to paired bluetooth devices. Presumably, since these are professional drivers, they're using company phones. Require that bluetooth devices be configured as "is car" or "is not car" and use an admin password that only the supervisor would know so that the driver could not change the setting.

It's not perfect, but it's another approach.

  • so you turn bluetooth off, and you're done...
    – jwenting
    Commented May 22, 2014 at 13:08
  • 2
    It would obviously need to be supported by business policies. The OP clearly has a target audience. The app could fairly easily require bluetooth connectivity to operate, if that's appropriate. Without having more detail, it's impossible to determine if this solution is viable. Fortunately, OP has those details.
    – Travis
    Commented May 22, 2014 at 14:04

In my opinion, these make the app less safe, because instead of taking the message to heart, drivers will push the buttons to get around it, which takes more time and hence moves their attention away from the road even longer.

I would rather focus on making the app usable in as short of bursts as possible, so as to minimize the amount of time the driver spends looking away from the road. Any action should require a minimal number of button presses, and all buttons should be large enough that they can be hit inaccurately. As an added bonus, this will also make the app more useful in non-driving contexts as well.


What service does the app offer? And how can you make that service simply be undesirable when the user is operating a moving vehicle?

Anything you do with GPS or similar motion detection would fail rather quickly - sure, that user is not supposed to have a passenger, but what about when they are the passenger? Is your program of zero value when the user is in another vehicle, like a taxi? Could the "passenger" be another company driver?

The pass codes, quick-enter letters etc. mentioned elsewhere make your app more difficult to use in general, and speaking as a user you would be on a one-way trip to the delete function the third time it came up. Irritating your users never helps. If it's a company-issued phone it might have an unfortunate "accident".

Let me make a couple of guesses - if it's a driver's logbook, make it work automatically based on scheduled shift times and motion. If it receives messages, hold the messages until the phone stops moving for 10 seconds (red light).

Trains used to have a dead-man's switch that had to be held down. This was bothersome so drivers just put a brick in their lunchbox. Or a rope depending on the mechanics. Today the system looks at every control in the train's cab and expects something to be operated on a regular basis. As the driver will operate something on a regular basis anyway the drivers don't bypass it anymore.


Step 1) You are going to need to determine how much control you can have over the phone itself.

Step 2) Clarify reasonable assumptions. Can you assume you know when the person is actually supposed to be driving? At the time, before hand, or only after the fact? This ties in to...

Step 3) Can the user of the app be individually identified - is it registered to a known person's identity/phone?

Depending on these answers, you have a variety of tools from the phone at your disposal - or do you?

  • Clock
  • GPS
  • internet connection
  • truck/car mounted equipment that can be communicated with

The best solution for a situation where you have a known driver, a set schedule, and a phone where you have access to time, GPS, and reasonable internet, would use a combination.

You might first get a driver schedule for the day, and use it to determine when a driver should be working. You can then use the GPS (or vehicle equipment) to determine movement beyond human walking (anything over 10-20mph would be pretty obviously "not walking"), and if this is within a time period the person should not be driving you either refuse use of the app, and preferably report it to the company for human inspection with applicable information.

If you have vehicle equipment, when the vehicle is not parked the phone/app cannot be used. Even easier!

Each individual thing has human failings or is easy to beat - a person can just say they aren't working, falsify or not enter a work schedule, turn GPS off to hide their movement, not install this app on their own phone or use a second one, etc. But if it is combined with a company system that can combine documentation, and the company takes this as seriously as they should, then you have a hybrid solution that combines all available knowledge.

"You were tooling around with your phone while you were scheduled to be driving, and were in fact actually driving. If this happens again you will no longer be employed with us."

If this is just a casual or non-mandatory app, then obviously many of these solutions won't suit your use case at all - but this is precisely why the use case must be clearly defined so you know what tools you have available to solve your problem.


A somewhat over engineered solution, but mentioned for completeness:

You could use the forward facing camera and image processing to detect how long the user is looking at the screen compared to looking elsewhere (i.e. the road). I think that the pattern of attention for a driver using the app would be significantly different to a front seat passenger using the app.


The Waze solution seems to be a good one, in that normal menu/button related actions are allowed but when a keyboard-related task is required when over a certain speed, a warning dialog saying something like "not available while driving" is displayed. The clever bit is that it has two buttons, the 'ok' one but the other is a "Passenger" one.

Done that way, it makes it's point without getting in the way when being used when moving when the user's not the driver...


Whatever you do, don't make it hard to use the app while driving. Making it impossible is fine, making it hard isn't. The reason: There will always be someone who really wants to use your app while driving. And we all know that's stupid because it removes concentration from driving. But if you make the app hard to use while driving, these people will lose even more concentration from driving, making it more dangerous.


Well besides Apple and their patent there exists a system called Mirror Link This will handle your issue actually. The phone is connected to the car and certains functions just aren't allowed. You can find mor information on the website. It might not help you for your current project but maybe for the next one.


Nobody yet has mentioned the possibility of using sound. I can think of a few ideas:

  1. Sample a few seconds of sound, then do some signal processing, listening for those characteristic frequencies that occur inside a car (the drone of the engine, tyre hum etc.). You don't mention your budget and you'd probably need a fair bit of research and testing to get this to work.
  2. Alternatively, make the speaker beep and listen for the echo. That will give you the distance to the nearest reflective wall. If it's less than a metre or so, he's either in a car or in a very small room.

Can you combine a GPS reading to detect motion, with a Bluetooth connection to detect if a car is present? If the GPS says you're moving, and the car device is always in the vicinity, would that satisfy the criteria? Can your platform use these two features?

I agree with the other answers posted here, but I took it you were curious about the engineering aspects, rather than the question if it was a good idea in the first place. Assuming your target is "professional" drivers this could be a good safety measure. Some cars won't let you play movies in the front seat if the car is moving, so it doesn't seem like too far-fetched a requirement.


It's really difficult to prevent users using their phone and or apps while driving and there is no 100% way to stop them from doing so.

However, there are many roadblocks we can implement to attempt to stop them or at least discourage them from using the apps while driving.

The first thing you could implement is a pass code to access the app, something along the lines of a 4 digit code that they would have to first enter before opening the app.
Another option you could take that is more direct is a prompt when the app opens that asks the user if they are currently driving with a yes or no button and upon pressing yes would automatically close the app.

You could also simply display to the user that the app is not to be used while driving every time it opens with an ok button that would be pressed to move onto the app.
It is not a good idea to make the app unusable when the phone is in motion though, as the passenger could be using the app or they could simply be in a train or walking. Just some suggestions, hope this helps.

  • 1
    Setting up road blocks seems like an over-reaction. It'd be super-expensive and inconvenience other road users. ;-) Commented May 20, 2014 at 16:05
  • Would setting up passcodes etc not run the risk of it being more likely they'll have an accident while driving? (Maybe the actual solution is to make the app easy to use while driving. If people are going to do it anyway then you might as well make it as safe and easy to use!)
    – JonW
    Commented May 21, 2014 at 12:07
  • This idea was more of a way to replace his current idea at the time which was determining by movement. Meant to be more deterrent than actual stops, but yes I see your points.
    – Nick_M
    Commented May 21, 2014 at 16:15

I'd just go with a warning message that pops up once. If you have it popup every time it'll just annoy user.

Besides that, you could opt for a non-obtrusive banner at the top/bottom of the screen that give you the same warning when it detects you're on the move.

A one time warning message by itself would probably not stop me but when it's always on the screen (not getting in my way), it's a constant reminder of what I'm doing isn't safe.

I definitely wouldn't lock the app completely when a person is on the move as this will probably give you an opposite result. The person might be fiddling with the app while driving just to get it working again.


You don't. It's not your job, even if it is a driving app. How do you stop knife-users from killing people? You don't; you trust them.

  • 2
    It's not the job of the person designing the user experience to try to keep the user safe? As UX Designers that should be a high priority, not no priority. If you build a GPS navigation system that directs people the wrong way down a one-way street and they crash would you still say "that's nothing to do with me, they should've been paying attention"?
    – JonW
    Commented May 21, 2014 at 12:01
  • 2
    The function of a GPS app is to direct, therefore if your app doesn't direct then that is obviously wrong. But that's taking the question out of context IMO - by your logic why not also warn the user that fire is dangerous? Where do you draw the line? Some things are simply outside the scope of the UX design. We are designers, not nannies.
    – user43251
    Commented May 21, 2014 at 12:14
  • 1
    Using your phone while driving is illegal, so no they won't say that and if they did, the burden of proof is on them, not the app creators. Again 'I killed a guy with this gun - it didn't say I couldn't!' Seriously? How many hypothetical situations do you design for?
    – user43251
    Commented May 21, 2014 at 12:49
  • 4
    I think its funny the lowest ranked answer and the top ranked answer are pretty much saying the same thing. Just goes to show that how you say it makes a big difference. Commented May 21, 2014 at 17:03
  • 1
    @burnttoast11, amusing indeed! :) The difference is that the top answer is logical breakdown, but this answer outright claims that keeping users safe is "not your job" as a UX professional - which shows a dangerous ignorance of the job description. Commented May 21, 2014 at 17:37

Android OS has a way of indicating if the device is docked in a car (it has to be a specific dock, though).

You can consider that a device docked this way is in a position where the driver can always see it (used as a GPS or a radio), and therefore should not allow the use of the app.

But then again, the car could be stopped.

Among the more complex methods, detecting if the device is paired with the car audio system (via Bluetooth, likely) and reading the speed on the GPS can work too (although in the car and unless placed at the right position the GPS is not likely to be very accurate).


I wouldn't change the App experience at all for when someone is driving or not, teh experience should be the same, but I might add a warning message to the App header when motion over x speed is detected. I would then warn the user that App usage over x speed is logged and reported. This log could be accessible to a manager or employing company. This is very much what happens when tracked vehicles go off course or stop too long. Simple people management. Then it's a management and trainign issue.


enable both thumb fingure presence on the screen. Atleast somebody dare to leave both hands from the stearing. or monitor the eye contact of the user on screen if the user have front facing camera in his device.

  • 2
    People take both hands off the steering wheel, and look away from the road, all the time to do things they shouldn't while driving. Commented May 24, 2014 at 14:30

If the phone has internet connection (even better if your app requires internet connection) then you can use a combination of GPS and OpenStreetMap to determine if a user is on a road, and how fast they are traveling.

If an internet connection will not be available you could require that the app be "initialized" at HQ where there is WiFi, and download the appropriate road data. If the user travels outside of the available road data, and is in offline mode, disable the app - they will be using it against company policy.

With the integration of OpenStreetMap you may even drop the speed calculation; Being on the road pretty much qualifies as driving according to your rules. As you said, there is a policy against passengers. However the speed calc might be useful if you wanted to briefly enable the app while the driver was stopped, at a red light for instance, or a flat tire.


Actually giving an answer... In android when you request a users location you will also get their speed.

The best answer here gives a class that gets location updates. https://stackoverflow.com/questions/3145089/what-is-the-simplest-and-most-robust-way-to-get-the-users-current-location-in-a

http://developer.android.com/reference/android/location/Location.html#getSpeed() And use location.getSpeed() to get the speed. You can disable the app if the user is going a certain speed. The obvious disadvantage of this is being a passenger in a car.


This is how Waze does it. Surprised no one has brought it up as it's a good reference.

Using mobile phones while driving might be a legal offence in certain countries, therefore it's in your best interest to have a clear UI and stay clear from any legal issues.

And Waze does it pretty good. You are either a "passenger" or a "driver". If you are driver then you need to be in a stationary mode (GPS detection) to be able to type.

enter image description here

Sure, drivers might chose the "Passenger" button and still try to type. But then again, technically in legal terms, Waze is not responsible if the user has an accident while doing that.


I like the idea of GPS, but I would use the accelerometer.

You have to block when you find acceleration over a threshold for a certain amount of time (if calibrated, you can even integrate acceleration and place a lock when a speed 20/25km/h is found).

The accelerometer will use a lot less power, and cannot be easily disabled as Location Services. It is especially true if your app does not use GPS by default.

The drawback is sometimes the app will be blocked if the user shake/drop its phone, or the user is a passenger. However, I think it a minor problem. Just give a way to user to unblock following the idea of precise combination and small time.

  • 8
    This won't work. An accelerometer cannot detect speed, only acceleration. The accelerometer will not be able to tell whether you are flying down the highway at 130km/h or stationary (assuming you don't have acceleration or deceleration). Commented May 20, 2014 at 16:32
  • Integration of acceleration give speed. Of course you have yo estimate orientation, but this come free at least into adroid api @sixtyfootersdude
    – Lesto
    Commented May 20, 2014 at 16:36
  • 3
    Integration of acceleration gives a speed difference, rather than the absolute speed at which a driver is going. An example: I'm running, then accelerate by 1 m/s2 through 5 s. The only thing you can tell is that my speed has increased by 5 m/s, not whether I was running at 5 or 50 m/s. Commented May 21, 2014 at 2:04
  • But we care for big speed change, as is in the nature of the car trip to have them, and ive suggested a deltav of 20km/h, witch is a good low limit. Op never asked to block AT x km/h, but a way to find out if on a car, and this shoul work, just think about how many times you vary your speed over 20/25km/h on a car
    – Lesto
    Commented May 21, 2014 at 7:27
  • Actually, we don't. What matters most inside a car is the absolute speed. Why? Breaking distance increases with absolute speed. Human reaction time sits at approximately 0.7 s so a quick peek at a distraction (say, a phone) is enough to facilitate a car crash, at high enough speed, by failing to notice (and avoid) an obstacle in its path. You could measure acceleration from the start and from it determine the absolute speed, but that implies that the user has to start the app while the car is standing still or at a known initial speed, otherwise the speed results become phased. Commented May 21, 2014 at 22:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.