We Keep Coding

Device detection NOT based on UA

I'm looking to restrict the use of my webapp for handheld devices only, and completely disable for desktop.
There're a ton of libraries available for device detection, but all of the sniff User-Agent which can easily be faked. Is there any library that goes beyond UA and uses other checks to make sure the device is indeed a handheld?

Not sure if it would be helpful, but I would like to address your question in two sections:
I'm looking to restrict the use of my webapp for handheld devices
only, and completely disable for desktop.
Well, that is technically not feasible because of the reasons mentioned by #guest271314 (and other comments). Moreover, there are many software applications whose only task is to simulate a mobile environment on desktop devices and almost all of them make use of UA sniffing. Moving back to your second query,
Is there any library that goes beyond UA and uses other checks to make
sure the device is indeed a handheld?
If you want to know about the nature of browsers and devices accessing your services, there are a few different approaches to this task:
User-Agent Sniffing
Feature Detection
Device Detection
Now unfortunately, some confuse these at times. Yet each of these approaches to discover properties of the HTTP client works differently and, above all, they often play different roles in the technology stack.
User-Agent Sniffing
With "User-Agent Sniffing" (UA Sniffing), one can derive properties of the client by looking at the User-Agent header in the HTTP request. UA Sniffing usually involves searching for a specific string or pattern in the UA string and basing choices on the result of that search. While UA Sniffing can be done with JavaScript on the client itself, nothing prevents people from performing UA Sniffing on the server. UA sniffing also have some downfalls. First one is: going down the slippery slope of constantly updating your sites and services to follow the never-ending evolution of the browser and device market. Secondly, UA can also be faked(as you mentioned in your post).
Feature Detection
Its the approach where we don’t test the User-Agent string but rather, we test for features that a browser claims to support. Feature detection is about checking for certain functions or features of the browser using JavaScript. Seeing the context of your query, this is what you might be looking for.
Feature Detection also has downsides. The most deadly one is called “false positives”. For example, your test of the browser tells you “yes, I support this feature! Fire away!”, only to discover that Geolocation is not really supported.
The most common tool for Feature Detection is Modernizr.
Device Detection
Device Detection is about having a framework that maps HTTP requests to the full profile of mobile device properties, including properties that relate to browsers and OSes. It happens on the server typically and has the added advantage of sending only content and formats that client can easily parse and use to the browser.
Some tend to confuse UA-Sniffing with Device Detection. In fairness to those, Device Detection does exploit analysis of the HTTP request (and the User-Agent string particularly) to operate. But the similarity ends there. A fully-fledged device detection framework, such as WURFL, will go out of its way to avoid false positives and above all, it will return device properties and capabilties that cannot be derived by UA analysis.
Hope it helps

I'm looking to restrict the use of my webapp for handheld devices
only, and completely disable for desktop.
Abandon all hope. This is not possible. For example, an RDF application at the "handheld" could be accessed by separate "desktop" computer. Even if access were successfully restricted to "handheld devices" access to the device hardware , software may, or may not be simultaneously restricted, allowing the "handheld" operating system , browsers, display, etc. to be viewed at a local or remote "desktop".
adb , or similar interfaces for non-android platforms could also access "real-time", or saved html ,js viewed at "handheld" device - at "desktop".

In brief - there's no reliable way for a server to tell which devices initiates communication with it. Everything in the HTTP headers/content can be spoofed with the simplest script.
In the client side things are even more open so - naturally any client side code can be viewed, extracted, manipulated, changed and used in any way a skilled developer would like.
But you can try to make life a bit harder for the hacker, my best shot in client side would be to use a few checks using Javascript and Modernizr to detect touch devices and then try to distinguish between these and desktop devices that support touch.
So:
1) Detect only touch devices through Modernizr.touch, docs here: http://modernizr.com/docs/
It's a client side javascript to detect touch devices.
2) To rule out desktops I would test if the device width is smaller than 1024 (javascript: screen.width) . Most handheld devices width are such.
3) Maybe the only popular exception for that exception for this would be iPads. They have 1024px device width, just like some desktops with touch support. In this case you could use user agent check in client side (that's a little harder to spoof than the user agent sent to the server in HTTP but still possible)
isiPad = navigator.userAgent.match(/iPad/i) != null;
Then I'd minimize everything to make it somewhat harder to manipulate and hack, so the average user hopefully won't bother, or won't have the skills to break this, and hope for the best.

How do browsers know where a user begins and ends text selection?

According to an answer to this question, it is technically very difficult to create selection ranges from the user's mouse position. Why is this? How is it that selections can be created from the mouse position in the browser normally, but creating the same range using JavaScript is difficult?

Because the browser can use whatever native OS methods it wants because it only has to work within it's own environment. Your Javascript code on the other hand is constrained by the functionality the browser decided to expose to external (i.e. your) code. This is usually constrained to what's in the published standards (give or take a little...or sometimes a lot). Your code needs to run everywhere, all browsers, all OS's, all devices. The browser code only needs to run on one OS, and often on a small subset of devices.
But - you might say - I can run Chrome, or Safari, or Firefox on different OS's and different devices. Yes, you can, but it's not the same code. They are different versions of the browser optimized for each environment. They may share a lot of code, but they also have significant differences, especially the parts that interact directly with the underlying OS.

Sencha Touch 2 - Android Performance

We are developing a Sencha Touch 2 application which makes use of Phonegap to be able to install it as an application and access the storage of a device. This works really well on the iPad 2 and the iPad 3. However when we tried to run the application on an android device, the performance was very slow. The main elements which slowed down the system were lists and carousels. When we tried to test the same application through the chrome browser, the performance was on-par with that of the iPad.
Do you have any suggestions on what we can do to improve the performance on android, maybe even ditching Phonegap for something which works better. Or if we can force phonegap to run as a chrome browser.
Thank you for your time & help.

The problem you have here is that the Android browser does not use graphics hardware acceleration. This means that the standard tricks that Sencha (and other HTML5 libraries such as jQueryMobile, iScroll etc...) use to provide good scrolling performance, such as CSS 3D transforms to cause a your list to be rendered in a separate layer, which can then be translated in hardware, will not work on Android. Instead, list scroll will be performed entirely in software, which is going to be slow!
The Chrome browser, does however provide GPU acceleration. The Android device is more than capable of delivering a good HTML5 experience, it is simply that the standard browser does not take advantage of GPU hardware yet.
Unless you can force your end users to use Chrome (which I doubt), the only option is to degrade user experience, and deliver a slightly simpler UI for Android users.
For further details, see "IMPROVING THE PERFORMANCE OF YOUR HTML5 APP"

Try setting this flag in your AndroidManifest.xml :
android:hardwareAccelerated="true"

Update: Having now worked with ST2 more longer now the performance challenges on Android are just something you have to accept. There are many things you can do to avoid performance issues such as reduce listeners and events, keep your DOM light (below 2000 nodes) and generally avoid any CSS3 transformations and effects (these in particular don't perform well on Android)
Another thing to consider is rather than using the built in WebView you could use the CrossWalk browser and embed this in APK.
https://crosswalk-project.org
It adds a little size to your APK (15-20MB), but it performs better than the built in WebView and brings stability and consistency to a very fragmented platform. Consider the reality that every WebView on Android depending on device, vendor and OS version may be different in small ways. CrossWalk will allow you to have the exact same version across all Android 4.0+ devices and remove any device or vendor specific issues.
There is no silver bullet for performance on Android. Graphics acceleration won't improve the perform of pure javascript execution or DOM manipulation. If you want to understand why, then start here:
What's the difference between reflow and repaint?
Older Answer (may still be valid):
For ICS and above the following setting on the webview will significantly improve rendering performance for Sencha Touch on Android:
mWebView.setLayerType(WebView.LAYER_TYPE_HARDWARE, null);
However in my experience this will introduce artifacts into CSS rendering depending on the device and platform variation. I haven't specifically found a reason for this and I don't expect Google will resolve it as the webview component will be getting replaced with a newer and better version in Android 4.4.
https://developers.google.com/chrome/mobile/docs/webview/overview

Minimum system requirements to run webGL?

I want to know what are the minimum system requirements to run a webGL application smoothly?
I know this is a broad question,so what would be the minimum requirements to run the following experiments?
1.) http://www.ro.me/
2.) http://alteredqualia.com/three/examples/webgl_loader_ctm_materials.html
I would have done this myself,but i don't have a machine with low specs,and yes i did try google.

There are no minimum requirements in terms of system specs. I guess if you wanted to be really pedantic you could claim that a system needs a GPU capable of processing shaders (roughly DX9 level) but that basically describes every device with a GPU these days. (Except the Wii. Go figure...)
On a more practical level, you must have a device who's drivers have not been blacklisted due to instability issues. You can typically find the blacklist for a given browser by following the "visit support site" link on http://get.webgl.org/
Beyond that, however, it's all a matter of what the WebGL app is trying to render and what the device's bottlenecks are. For example: I've tried several WebGL demos on a Galaxy Tab with Opera and Firefox, and the framerate is limited to 10-12 FPS no matter what I'm rendering. A full, complex scene renders at the same speed as a single cube. This suggests that the device is probably getting stuck on the compositing phase (where it places the WebGL canvas in the page itself) and as such while the device may be capable of some very complex rendering the limitations of the browsers are holding it back. In comparison, I've seen highly detailed scenes running on iOS devices (with a hacked browser) of similar power at a solid 60FPS. So the exact hardware you have is only one part of the overall equation.
But really the best answer you can possibly get at this point is to pick up a device and try it!

Script concatenation performance characteristics on memory constrained devices

We are currently trying to optimize page load times on an memory and cpu constrained windows mobile device (the MC9090, 624mhz cpu, 64meg ram, running WinMo 6 and Opera Mobile 9.5). As one of the potential optimiztions, I wanted to combine external js/css files, but now we are observing that page load times actually INCREASE after concatenation.
Now, that flies in the face of everything I have seen and read about with regards to client side performance. Has anyone ever seen this before? Also, are there different rules for embedded device web optimization then desktop browsers?

Browsers can download across multiple connections (4, sometimes 6 - not sure what this version of Opera allows). By putting everything in one file it forces the browser to download all the javascript in one stream, vs. multiple ones. This could be slowing it down.
Images and other items also compete for these connections. You nelly need a tool similar to Firebug's "net" tab to view the traffic and see how the bandwidth resources are allocated.
Also, see: http://loadimpact.com/pageanalyzer.php
out of date but relevant: http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/