While it gets all the media attention, Google Glass isn’t the only head-mounted display available to consumers and businesses. Between Glass, the Oculus Rift and the newly introduced CastAR from Technical Illusions, the rush is already on to bring headgear to the masses.

Glass takes the approach of adding a single small screen above one’s eye, allowing for an overlay of reality. The Oculus Rift is a set of virtual-reality goggles we were all promised back in the 1990s. The CastAR is a bit like VR goggles turned inside out: It’s a set of glasses with two projectors embedded in the front, allowing images to be projected onto surfaces in front of the user.

Behind all of these new devices is a single concept: augmented reality. In the world of smartphone apps, AR has been used mainly as a supplement to maps and as a marketing tool (as in the Stella Artois app that helps you find bars serving their beer). Although there are many AR apps available for both Android and iOS, AR is still an emerging field, and head-mounted displays will only accelerate the innovation.

Imagine a phone technician sitting in front of a street-side punch-down box of phone lines. Instead of reading labels or tracing lines, a projection of names for each punch-down could be displayed right on the surface of the box. Imagine a facial-recognition app that helped you remember people’s names. Or an app to tour a hotel room via VR walkthrough.

Curiosities? Yes. Consumer-focused? For the most part, yes. However, AR doesn’t have to be. The BYOD trend forced enterprises to deal with smartphones and tablets, and that pushed the companies into not only accepting those devices for e-mail, but also as valuable business tools.

While AR via headset isn’t anywhere near mainstream yet, it’s certainly about to pop into the view of the common person. When goggles become inexpensive, your organization will face a comparable BYOG situation. Look beyond the overhyped privacy issues. Turn goggles from an IT challenge into a business opportunity. These new technologies can be used to make your customers happier, your employees more productive, and ultimately, your organization more successful.
#!
Redefining native code
What is native code? To purists of a certain age, native code means assembly language, C, C++, or any high-level code that is compiled into binaries consisting of machine instructions for the CPU. Anything that is interpreted and executed by a runtime is not, by its very definition, native code. That excludes BASIC, Java, C#, JavaScript, Perl, and so on.

The benefits of native code are well known. Native code can run fast since the binaries are machine instructions running directly on the metal. Performance of native code can be predictable, since you need not factor in issues with the interpreter or runtime. The biggest downside, of course, is that native code is not portable.

Ah, it all seemed simple back in the old days. Today, the lines between native code and non-native code are blurred when we talk about cloud computing, virtual machines, multi-tenant hosting—and especially mobile apps.

With the rise of mobile platforms, “native” has come to mean an experience more than the underlying language and runtime circumstances. That is, the new feeling is that you don’t have to write an application in Objective-C in order to have native code on an iOS, or in Java in order to have native code on Android. And you know, that’s okay.

Consider that consumers using an application on an iPhone can get a native experience from an app that was written in HTML5 or JavaScript because the iOS runtime engine has some native code wrapped around it that gives the app the look and feel of an app created with native iOS tools. What’s more, that same app code can provide a native code experience on Android using a suitable Android run-time engine.

Classically speaking, that cross-platform code is not native. Practically speaking, for all but the most demanding apps, it doesn’t matter.

The native vs. cross-platform argument came to the surface again this month when Embarcadero Technologies released a tool set redefining native code that runs directly on the hardware as “true native (see p. 20).” This, we assume, is to return the phrase to its original meaning of native-as-machine instructions to differentiate from the native-as-experience meaning.

Which is better: native code, or interpreted code that can run on more than one device? The major benefit of the latter, of course, is that developers only need to write the application once, in HTML5 or JavaScript, and it can run in a virtual machine on any device.

There are many platforms already in the market that provide the hooks into the various hardware devices, so developers don’t even have to tackle that anymore. The downside, though, is the performance hit the application takes when code has to be interpreted. Also, developers often will fail to utilize all a particular device has to offer for the sake of having it provide a native experience across multiple devices. In other words, they will “dumb down” the app as a tradeoff for cross-platform usability.

In today’s world, latency has become unacceptable. The turning off of cruise control, for example, has to be immediate. Or someone changing tracks on a music player shouldn’t have to wait. Or, if a GPS app on a phone takes too long to recalculate a route, the driver could miss another turn. Yet this requires developers recreating the same application over and over for the different platforms out there, and then having to maintain several different versions of the code over time.

Which is better? It depends. If you are writing an app for the card game Hearts, and you don’t take advantage of the phone’s vibration capability when the queen of spades is played, or launch a sound effect when a player “shoots the moon,” that’s something people can most likely live without.

But if your application truly needs immediate response time, and it needs to leverage the full capabilities of the device it’s running on, then you must go native.