I don't want to use any of the normal touch events in the iphone sdk.
When an user touches the screen I want to find where he touched and all of pixels he touches. Is there a way to do it in iphone ? may be using a low level SDK.
i want this to do it for some thing like a drawing app with finger on iphone.
There is no low-level API. IIRC, the data in a touch object is actually returned by the hardware. In other words, that is all the data that software can get.
Having done some touch UI experiments in the distant past, I can tell you that processing real world touches in software is a lot more complicated than you would expect on first glance. It's not like tracking a mouse. A finger is actually a very blunt and imprecise pointing instrument on the scale of a mobil screen. There is a great deal of variation in finger size, pressure of contact, contact area, angle of contact and consistency of contact. It takes a lot of processing to turn that blunt imprecision into a single point or collection of points that an API can easily use.
I wouldn't try to reinvent the wheel even if you find a way to extract more data from the hardware. If nothing else, (puts on interface-nazi hat) if your touch interface behaves different from other apps, users will be confused when the have to switch back and forth.
A touch is a rather imprecise gesture, so getting all the pixels that one encompasses is not really possible. However, you can get the rough 'center' of a touch, and extrapolate an area around that for a group of 'touched pixels'. No need to use a low level SDK, just override -touchesBegan:withEvent: on UIView.
Related
Now i understand we can have 5 touch points by default in iPhone and have varied touch points enabled onto the different SDKs. However i have accomplished registering the touch points and getting distances, actual number of touch points. I would want to know if there's a way to accomplish and get the Diameter of a particular touch point for e.g. calculating the thumb touch in comparison with the index finger, Any ideas?
I think Apple makes it fairly clear that they don't intend to give third-party developers access to low-level multi-touch information. From Apple's documentation on Event Handling in iOS:
A finger on the screen affords a much different level of precision
than a mouse pointer. When a user touches the screen, the area of
contact is actually elliptical and tends to be offset below the point
where the user thinks he or she touched. This “contact patch” also
varies in size and shape based on which finger is touching the screen,
the size of the finger, the pressure of the finger on the screen, the
orientation of the finger, and other factors. The underlying
Multi-Touch system analyzes all of this information for you and
computes a single touch point.
I can’t speak to Android, but the public APIs in the iOS SDK don’t give you any information about a touch other than its position. These guys found a private API (i.e. one that’ll get you rejected from the App Store if you use it) for getting the diameter of a touch on the screen, but they haven’t provided any further information or released the library.
It's likely possible on Android (4.3 I have, but most likely others too), as you can both activate an overlay display of touch properties in the Developer options as Pointer location (in Input category), which shows you coordinates, their Delta (=difference) and two properties you might be interested in: Prs, that is pressure and Size. It seems you can find the thresholds that would recognize a thumb and the index finger in most cases. That's just what I would imply from the values I have seen in that display.
A proof that this is possible within the allowed API is Yet Another MultiTouch Test Android App listed on on Google Play which for me shows the pressure of each touch in it's own interface (so it must be available in the standard API).
How to implement a way to measure distances in real time (video camera?) on the iPhone, like this app that uses a card to compare the size of the card with the actual distance?
Are there any other ways to measure distances? Or how to go about doing this using the card method? What framework should I use?
Well you do have something for reference, hence the use of the card. Saying that after watching the a video for the app I can't seem it seems too user friendly.
So you either need a reference of an object that has some known size, or you need to deduct the size from the image. One idea I just had that might help you do it is what the iPhone's 4 flash (I'm sure it's very complicated by it might just work for some stuff).
Here's what I think.
When the user wants to measure something, he takes a picture of it, but you're actually taking two separate images, one with flash on, one with flash off. Then you can analyze the lighting differences in the image and the flash reflection to determine the scale of the image. This will only work for close and not too shining objects I guess.
But that's about the only other way I thought about deducting scale from an image without any fixed objects.
I like Ron Srebro's idea and have thought about something similar -- please share if you get it to work!
An alternative approach would be to use the auto-focus feature of the camera. Point-and-shoot camera's often have a laser range finder that they use to auto-focus. iPhone doesn't have this and the f-stop is fixed. However, users can change the focus by tapping the camera screen. The phone can also switch between regular and macro focus.
If the API exposes the current focus settings, maybe there's a way to use this to determine range?
Another solution may be to use two laser pointers.
Basically you would shine two laser pointers at, say, a wall in parallel. Then, the further back you go, the beams will look closer and closer together in the video, but they will still remain the same distance apart. Then you can easily come up with some formula to measure the distance based on how far apart the dots are in the photo.
See this thread for more details: Possible to measure distance with an iPhone and laser pointer?.
I am trying to build an app that detects if a user puts their lips on the screen. How could I get an image of their lips when they put it on the screen?
I know how to detect finger touches, would it be similar to that?
Edit: Also, wondering about doing this for Android.
I believe the iphone hardware supports somewhere between 10 and 20 touch points, but the SDK only gives you access to 5. To get a good outline of the lips you'd need a much higher number of touch points.
Could you use the front facing camera and avoid the obvious hygiene issues?!
You can't get the form of the touches, so you wouldn't be able to detect lips on the screens.
As others have posted here, it is not possible to detect all of the contact points of the lips and the screen. Yes, it would be similar, but more difficult. The iPhone screen is capacitive, so it should detect lips, which are similar to fingertips. (When outside in the cold and I need to scroll with my gloves on, I've used my chin.)
As far as the shape, you may be able to map multiple touches, but touches don't take on any particular shape, so you won't be able to draw the lips based on that. You may want to consider preloading generic pictures of lips and then resizing it to match the size of their lips, depending on where the touch inputs are.
Is there a way to capture the amount of screen that is making contact with the users? I assume there is since this finger painting app shows the ipad responding to only the pixels that the user makes contact with.
Thanks so much in advance for your help!
The size of the touch is abstracted away by the framework, and UITouches only contain calculated (“best estimated”) points instead of the raw, actual areas that were touched. I would guess that the “pressure” was calculated from the duration and the direction of the touch.
In a nutshell, there is no public API to get the contact area.
I don't think Apple provides APIs for the size of the touch, or as #nickthedude said (I think) any kind of way to measure pressure. Basically, you need to implement your own algorithm/policy for determining line thickness/opacity/other effects. I believe a common way to do this is to measure the amount of time spent for the stroke, and work from there. For instance, if the user moved more quickly, you might want a thinner line segment. Apple really should just provide a canvas view of some kind. Best of luck!
to get the exact area you may have to roll your own but you can get uievents pretty easily and then do some magic from there. Basically impliment/override touchesBegan, touchesEnded, touchesMoved on the UIView in question and put in your custom code there.
Looking at the video maybe the amount of touches in the UIEvent set might correspond to the "pressure" of the touch, then again maybe not.
What if you laid down a series of successively smaller square uiviews wherever the user touched then if the touches "spilled" into the larger uiviews behind the smaller front ones than you could conjecture that the touch pressure was harder. Something to try I guess. Good luck.
Why not just describe what you want to do and foxus on asking about that instead - it may not have anything at all to do with the example that has you so otherwise enthralled - I can use a camera to monitor your hand from across the table and paint pixels on the screen via BT, completely ignoring any contact between your fingers and the screen.
I'm starting a new project which involves developing an interface for a machine that measures wedge and roundness of lenses and stores the information in a database and reports on it. There's a decent chance we're going to be putting a touch screen on this machine so that it doesn't need to have a mouse or keyboard...
I don't have any experience developing for full size touch screens, so I'm looking for advice/tips/info from you guys...
I can imagine you want to make the elements a little larger than normal... space buttons out a bit more.... things like that... anyone have anything else to add?
A few things to consider:
You need to account for parallax error when touching controls. Basically, the user may touch the screen above or below your actual control and therefore miss the control. This is a combination of the size of the control (eg you can have the active area larger than visual control to allow the user to miss and still activate the control), the viewing angle of the user (which you may or may not be able to predict/control) and the type of touch screen you're using. If you know where the user will be placed relative to the screen when using it, you can usually accommodate this with appropriate calibration.
Depending on the type of touch screen, you may need to ensure that your users aren't wearing gloves or using an implement other than their fingers (eg the end of a pen) to touch the screen. Some screens (eg those depending on conductance) don't respond well to anything other than flesh and blood.
Avoid using double clicks because it can be very hard for users to reliably double click a control. This can be partly mitigated if you've got experienced/trained users working in a fairly controlled environment where they're used to the screens.
Linked to the above, if you are using double clicks, you may find the double click activated when the user only wants to single click. This is because it's very easy for the user's finger to bounce slightly on touching the screen and, depending on how sensitive the double click settings are, trigger a double rather than a single click. For this and the previous reason, we always disable double clicks and only use single clicks (or similar single activation controls).
However big you think you need to make the controls to allow for touch activation, they almost certainly need to be bigger still. Make sure you test the interface with real users in the real deployment environment (or as close to it as you can get). For example, we deployed some screens with nice big buttons you couldn't miss only to find that the control room was unheated and that the users were wearing thick gloves in the middle of winter, making their fingers way bigger than we had allowed for.
Don't put any controls near the edges of the screen - it's very hard to get your finger into the edges (particularly if the screen has a deep bezel) and a slight calibration problem can easily shift the control too close to the edge to use. Standard menus and scroll bars are a good example of controls that can be very tricky to use on a touch screen and you should either avoid them (which is preferable - they're not good for touch screens) or replicate them with jumbo equivalents.
Remember that the user's hand will be over the screen, obscuring some of the screen and controls (typically those below where the user is touching, but it depends on the position of the user relative to the screen). Don't put instructions or indicators where the user's hand or arm will obscure them when trying to use the control they relate to (eg typically put them above rather than below the control).
Depending on the environment, make sure your touch screen is suitably proofed against dust, damp, grease etc and make sure it's easy to clean without damaging it. You wouldn't believe the slime that can quickly accumulate on a touch screen in an industrial or public setting.
The other obvious one is that there's no equivalent of pointer 'hover'. Not that that affects many apps though.
If you decide to put in analog controls (scrollbars, rotation widgets, etc) be sure to put in a digital control also. Some companies think that a touch screen means perfect control over something with your fingers. In real life, this translates to minutes of frustration trying to fix a number that's just a little off.
The most obvious thing is that everything on the GUI needs to be big enough for a fingertip to hit, which is sometimes bigger than you think.
As has been mentioned, there's really no way for a right-click action to happen. Also, double-clicking can be tricky with a fingertip on a touch screen.
The other major thing is that you'll want to create a on-screen keyboard that pops up for text entry and an on-screen numpad for number only fields.
I wrote my own set of controls for a POS application designed specifically to be touchscreen friendly.
Remember to allow enough real estate for stubby fingers and talons. In our application the users can have these manicures that necessitate them to use the pad of their finger instead of the tip. This means that you need to allow more space for activation areas than you would normally consider in any other type of application.
I would also recommend that you accommodate yourself as a programmer from a testing standpoint and from the point of view that things change and there may need to be a keyboard/mouse attached to a non-touch workstation. I cannot tell you how many times I went to touch my flat panel LCD expecting something to happen, before remembering that I had to use the mouse.
Make sure to read your basic UI principles like Fitz law (The time to acquire a target is a function of the distance to and size of the target).
Also consider whether or not the device is stationary or not when it is in use (e.g., like a palmpilot or iphone), research shows that you must accomodate that into your design.
The larger gui elements is the major thing. But it applies to all elements, scroll bars, tabs and even text fields.
The other major thing that I can think of, it's hard for the user to right click. So things that require a right click should be avoided, context menus are the only thing that comes to mind at the moment.
The other responses are pretty good, but are you totally sure that a touch screen would actually be easier to use? There are a lot of devices where a touch screen actually makes them much harder to use, not easier. The main problem is that you can't use the device when you're not looking at it. If users are going to be doing a lot of repetitive actions, a keyboard could be a lot more efficient.
Also, a touch screen might be a lot harder to use by someone with a disability, if you think there's even a small chance that could happen.
Even though this is quite old now, I found it to still be useful, as a starting point for design considerations.
http://www.sapdesignguild.org/resources/tsdesigngl/index.htm
If you've not already done so, have a look at some of the documentation available for developers on mobile platforms, eg Windows Mobile, iPhone.