Why Google Glass will fail and why this won’t stop smartglasses’ success

Smartglasses are probably the most promising kind of wearable devices currently on the market. And Google Glass is the most interesting device among them. Yes, Google Glass is sexy and cool. It has great design; it is small and futuristic. After all, it feels like a typical Google product - simple and great. Nevertheless, I think it won't be successful as a product and will eventually fail.
Disclaimer: the following is my own opinion and does not express the official position of ELEKS or its R&D team. In fact, some of the team members argue with me a lot that Glass is the best device ever, it will conquer the world and other things like that. Of course, I'm exaggerating here a bit, but still it looks very likely for me that Glass will eventually fail as a commercial product.
So, what's the problem with Google Glass? Well, there are two aspects of it:
1. The device itself. I'll dwell upon its drawbacks in the next section.
2. Its positioning and marketing. I'll show you some interesting historic analogies below and try to project them on to the future.

Five Reasons Why Google Glass Sucks

So, what's wrong with the device? When you watch the ads or listen to Google employees who evangelize Glass, it looks so futuristic and cool that you're starting to believe the future is here and search for the Order button. But things change when you actually get it. We bought one for our R&D team a few months ago and... well, I wouldn't say it is a big disappointment but the device is very far from being market-ready. Here is the list of 5 things that we found very annoying about Google Glass:

BYOX, Security, UX, Responsibility

There are 2 sides to adopting mobility. First is desire for innovation, the opportunity to drive better business with new technologies and thus increase revenue. Second is the fear of changes, the threat of holes in new processes which could result in enormous losses. Today I'd like to talk about the balance between these two sides, the balance between usability and security.

The Opportunity 

(thoughts of a typical employee)

My day-to-day job requires lots of documents' processing and working with my company's internal tools. It also requires leaving to other offices, thus spending about 20% of my work time out of the office. I often save copies of documents on my laptop and mobile devices to be able to work with them on the move. It helps me doing my job faster. But recently all our department had to enroll for a program which forbids any storage of work documents. From now on I take pictures of most relevant documents. I realize that it's a security threat, but I'd better get my job done than conform to overrated security policies.

The Threat 

(thoughts of security officer)

My company operates extremely sensitive data. Its exposure may result in my company's bankruptcy. I control its storage by locating data centers in my own premises. I control its flaw by using secure mailing services from providers I can trust. Recently I got acknowledged that this data is under a great threat, because employees use tools to keep it on their mobile device. Fortunately I've overcome this challenge by introducing MDM solution into everyone's device. I've protected the data from any other usages by strict policies, which all of the employees are obliged to follow.

The Conflict
We see a typical clash of interests. An employee just looks for the easiest way to get his job done. Security officer wants to make sure its done in a safe way. Both are right. So where is the solution?
Which one should change the attitude? A user, who has signed security policy and will respond for violating it, or security officer, who's responsible for any data leakage?
I believe from this point I'm switching from objective to subjective thinking.

The Irony
I'll rephrase the last question. If data gets leaked, who will suffer more? The employee, who gets fired, pays fine and potentially goes to jail, or the Company, which will go through numerous courts and potentially cease to exist? Or put it other way - who's more aware of this risk? Whose interest it is to protect the data? Who should adapt to the situation? You see where I'm driving at.
The irony is that regardless of how much we try, we can't force people to drop their habits, change their own ways of doing things and impose our rules. The best we can do, is encourage them to switch to a new way, which would conform them even better. And here's why

The Good, The Bad and The Lazy
Back in 2007, Apple did a wonderful thing. They made it so simple to use a mobile phone, and so functional in a meantime! This have set a very high standards of expectations from users. As things got simpler people got lazier. And now an app can't be considered competitive unless UX is intuitive. If people need to make more than trivial efforts to get what they want from app they simply quit and use another one. That's where we've brought ourselves, that's what consumerization of IT is.

The Clash
And now this big wave of consumerization is getting into the enterprise. The world where large systems with dozens of buttons on one screen and frankly complex UX has been a standard for years, gets hit by these small screens and highly trivial use cases. The employee and simplicity of his actions start to be the priority. Ignoring this priority means that employee will be much less productive, or worse - he'll find another way to complete his action, bypassing all our validation and security rules

thanks for pic @daveslocombe

The Responsibility
But using fancy apps is not the same as using enterprise software. Work is not always fun and simple. And that's the part where users have to realize their responsibility as an employee. This is the difference between enterprise and consumer apps. Employees still have to use the app, even if they don't like it.
Their productivity is another question though.

The End
It's not about who's responsible for failure, it's about avoiding it. It's just that in this case, limitations are less effective than flexibility. It's possible to achieve same security goals without losing much productivity.

The Reality
I'd like to conclude with a real life example of what happens when employees are forced to the job they don't want to. I witnessed it 2 weeks ago, after I started writing this article. It was the middle of Ukrainian revolution 2013, November 11th, Kiev. People were protesting for 3rd week, and one night government gave order to stop the protest by "cleaning" the protesters by force. But most of the policeman didn't feel like fighting their co-citizens, who didn't do nothing wrong. They still couldn't refuse following their orders, otherwise they'd be arrested themselves. So what it ended up with was a very weak attack from police, with policeman uncertainly pushing the people. This resulted in strong victory by the protesters, who stood their ground and defended themselves, thus total failure of government's plans

Introduction to Android NDK

Introduction

To develop applications for Android OS, Google offers two development packages: SDK and NDK. There are many articles and books as well as good guidelines from Google about SDK. But even Google does not provide enough materials about NDK. Among all the existing books, I would like to single out only this one, “Cinar O. - Pro Android C++ with the NDK – 2012.” 

This article is intended for those with a lack of (or some) background in Android NDK who would like to strengthen their knowledge. I will pay attention to JNI. It seems to me that I have to start just from this interface. Also, at the end, we will review a short example with two functions of file writing and reading.

What is Android NDK?

Android NDK (Native Development Kit) is a set of tools that allows you to implement a part of your application using such languages as С/С++.

When to use the NDK?

Google recommends using NDK only in rare cases. Usually, these cases are the following:

• Necessity to increase performance (e.g. sorting of large data volumes);
• Use of a third-party library. For example, many applications are written in the С/С++ languages and it is necessary to use the existing material. Examples of such libraries are Ffmpeg, OpenCV;
• Programming on low level (for example, everything what goes beyond Dalvik).

What is JNI?

Java Native Interface is a standard mechanism for code execution under control of the Java Virtual Machine. The code is written in Assembler or С/С++ and assembled as dynamic libraries. It allows for the non-usage of the static binding. This provides an opportunity to call a С/С++ function from the program on Java and vice versa. 

JNI Advantages

The main competitive advantage of JNI compared to its analogues (Netscape Java Runtime Interface or Microsoft’s Raw Native Interface and COM/Java Interface) is that it was initially developed for ensuring binary compatibility, for compatibility of applications written for JNI, for any Java virtual machines on the concrete platform (while speaking about JNI, I do not mean the Dalvik machine as JNI was written by Oracle for JVM which is suitable for all Java Virtual Machines). That is the reason the compiled code on С/С++ will be executed regardless of platform. Earlier versions did not allow for the implementation of binary compatibility.   

Binary compatibility is a program compatibility type. It allows a program to work in different environments without changing its executable files.

Organization of JNI

Figure 1. – JNI – Interface pointer

The JNI table is organized like a table of virtual functions in С++. The VM can work with several such tables. For example, one will be for debugging, the other for usage. The JNI interface pointer is only valid in the current thread. This means that the pointer cannot move from one thread into another. However, native methods can be called from different threads.

Example:

jdouble Java_pkg_Cls_f__ILjava_lang_String_2 (JNIEnv *env, jobject obj, jint i, jstring s)
{
     const char *str = (*env)->GetStringUTFChars(env, s, 0); 
     (*env)->ReleaseStringUTFChars(env, s, str); 
     return 10;
}

• *env – an interface pointer;
• оbj – a reference to the object inside which the native method is declared;
• i and s – passed arguments;

Primitive types are copied between the VM and native code and objects are passed by the reference. The VM should trace all references that are passed to native code. GC cannot free all references passed to native code. But at the same time native code should inform the VM that it does not need references for passed objects.

Local and Global References

JNI defines three reference types: local, global and weak global references. Local ones are valid until the method is finished. All Java objects returned by JNI functions are local references. A programmer should hope that the VM would clean all local references. Local references are available only in the thread where they were created. However, if it is necessary they can be freed at once using DeleteLocalRef the JNI method of the interface:

jclass clazz;
clazz = (*env)->FindClass(env, "java/lang/String");
...
(*env)->DeleteLocalRef(env, clazz);

Global references remain valid until they are explicitly freed. To create a global reference you have to call a NewGlobalRef method. If the global reference is unnecessary, then it can be deleted by the DeleteGlobalRef method:

jclass localClazz;
jclass globalClazz;
...
localClazz = (*env)->FindClass(env, "java/lang/String");
globalClazz = (*env)->NewGlobalRef(env, localClazz);
...
(*env)->DeleteLocalRef(env, localClazz);

Errors

JNI does not check for errors such as NullPointerException, IllegalArgumentException. Reasons:

• decrease in performance;
• in the most C libraries functions, it is very difficult to be protected from errors.

JNI allows for the usage of Java Exception. Most JNI functions return an error code but not Exception itself. Therefore, it is necessary to handle the code itself and throw Exception to Java. In JNI, the error code of the called functions should be checked and after that ExceptionOccurred() should be called to return an error object: 

jthrowable ExceptionOccurred(JNIEnv *env);

For example, some JNI functions of access to arrays don’t return errors. But they can call the exception ArrayIndexOutOfBoundsException or ArrayStoreException.

JNI Primitive Types

In JNI exists its own primitive and reference types of data.
Table 1. Primitive types.

Java Type	Native Type	Description
boolean	jboolean	unsigned 8 bits
byte	jbyte	signed 8 bits
char	jchar	unsigned 16 bits
short	jshort	signed 16 bits
int	jint	signed 32 bits
long	jlong	signed 64 bits
float	jfloat	32 bits
double	jdouble	64 bits
void	void	N/A

JNI Reference Types 

Figure. 2 – JNI reference types

Modified UTF-8

The JNI uses modified UTF-8 strings to represent different string types. Java uses UTF-16. UTF-8 is mainly used in C because it encodes \u0000 as 0xc0, instead of the usual 0x00. Modified strings are encoded so that character sequences that contain only non-null ASCII characters can be represented using only one byte.  

JNI Functions: 

The JNI interface includes not only its own dataset but also its own functions. It will take a lot of time to review the dataset and functions since there are plenty of them. You can find out more information from the official documentation: http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/functions.html

Sample of using JNI functions 

Below you will find a short example in order to make sure that you have correctly understood the material covered:

#include <jni.h>
    ...
JavaVM *jvm;
JNIEnv *env;
JavaVMInitArgs vm_args;
JavaVMOption* options = new JavaVMOption[1];
options[0].optionString = "-Djava.class.path=/usr/lib/java";
vm_args.version = JNI_VERSION_1_6;
vm_args.nOptions = 1;
vm_args.options = options;
vm_args.ignoreUnrecognized = false;
JNI_CreateJavaVM(&jvm, &env, &vm_args);
delete options;
jclass cls = env->FindClass("Main");
jmethodID mid = env->GetStaticMethodID(cls, "test", "(I)V");
env->CallStaticVoidMethod(cls, mid, 100);
jvm->DestroyJavaVM();

Let’s analyze by string:

• JavaVM – provides an interface for calling functions which allows for the creation and removal of JavaVM;
• JNIEnv – ensures most of the JNI functions;
• JavaVMInitArgs – arguments for JavaVM;
• JavaVMOption – options for JavaVM;

The JNI_CreateJavaVM() method initializes JavaVM and returns a pointer to the JNI interface pointer.
JNI_DestroyJavaVM() method loads the created JavaVM. 

Threads 

The kernel manages all the threads running on Linux; still they can be attached to the JavaVM via functions AttachCurrentThread and AttachCurrentThreadAsDaemon. If the thread is not attached, it has no access to JNIEnv. Android doesn’t stop the threads created from JNI, even if the GC is running.  The thread remains attached until it calls for the DetachCurrentThread method to detach itself from JavaVM.

First Steps

The structure of your project should look as is shown in Figure 3:

Figure. 3 – Project Structure

As Figure 3 shows, all the native code is stored to a jni folder. After a project build, the Libs folder should be separated into four subfolders. It means, one separate native library for each processor architecture. The quantity of libraries depends on the quantity of architectures selected. 

To create a native project, create a mere Android project and follow the steps: 

• Create a jni folder –  project sources root folder with native code sources;
• Create an Android.mk to build a project;
• Create an Application.mk to store compilation details. It is not required but is recommended as it allows for flexible compilation setting;
• Create an ndk-build file that will launch the compilation process (also not required).

Android.mk

As it was mentioned before, Android.mk is a makefile for native project compilation. Android.mk is used to group your code into modules. Under modules I mean statistic libraries, copied into the libs folder of your project, shared libraries and standalone executable.

Example of minimal configuration:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE    := NDKBegining
LOCAL_SRC_FILES := ndkBegining.c
include $(BUILD_SHARED_LIBRARY)

Let’s take a detailed look at:

• LOCAL_PATH := $(call my-dir) – function call my-dir is used to return the path of the folder the file is called in;
• include $(CLEAR_VARS) - cleans all the variables except LOCAL_PATH. It’s necessary to take into account as all the files are compiled in a single GNU Make context where all the variables are global;
• LOCAL_MODULE – The name of the output module. In the above-mentioned example, the output module name is set as NDKBegining, but after the build, libNDKBeginin libraries are created in the libs folder. Android adds a lib prefix to the name, but in java code you should indicate the library name without a prefix (that is, the name should be the same as in makefiles);
• LOCAL_SRC_FILES – listing source files to be built;
• include $(BUILD_SHARED_LIBRARY) points type of the output module.

One may set custom variables in Android.mk; however they must stick to the following syntax: LOCAL_, PRIVATE_, NDK_, APP_, my-dir. Google recommends naming custom examples as MY_. For example:

MY_SOURCE := NDKBegining.c

To call a variable $(MY_SOURCE)
Variable can also be concatenated, for example:

LOCAL_SRC_FILES += $(MY_SOURCE)

Application.mk

This makefile defines several variables that make compilation more flexible:

• APP_OPTIM – optional variable which is set either to release or debug. This variable is used for optimization when building an application's modules. You may manage release as debug; however debug gives more information for settings;
• APP_BUILD_SCRI defines an alternate path to Android.mk;
• APP_ABI – is probably one of the most essential variables. It specifies target processor architecture to compile the modules. By default, APP_ABI is set to 'armeabi', which corresponds to ARMv5TE architecture. For example, to support ARMv7, armeabi-v7a should be used; for IA-32– x86, for MIPS – mips, whereas for multiple architectures support, you should set APP_ABI := armeabi armeabi-v7a x86 mips. With NDK revision 7 and higher, you can simply set APP_ABI := all  rather than enumerating all the architectures. 
• APP_PLATFORM – names a target platform;
• APP_STL Android provides a very minimal libstdc++ runtime library so a developer is limited in using C++ functionality. However, APP_STL variable enables support for the extended functionality; 
• NDK_TOOLCHAIN_VERSION – enables the selection of a GCC compiler version (which, by default, is set to 4.6)

NDK-BUILDS

ndk-build is a wrapper around GNU Make.

After the 4th revision, flags were implemented for ndk-build: 

• clean – cleans all the generated binary files;
• NDK_DEBUG=1 – generates a debuggable code;
• NDK_LOG=1 – displays log messages (is used for debugging);
• NDK_HOST_32BIT=1 – Android supports 64-bit utilities version (for example, NDK_PATH\toolchains\mipsel-linux-android-4.8\prebuilt\windows-x86_64, etc. );
• NDK_APPLICATION_MK=<file> – indicates path to Application.mk.

In NDK revision 5, the NDK_DEBUG flag was introduced. When it is set to “1” the debug version will be built. If the flag is not set, the ndk-build by default will verify whether the attribute android:debuggable="true" is set in AndroidManifest.xml. If you are using NDK above revision 8, Google does not recommend using attribute android:debuggable in AndroidManifest.xml. (As you are using “ant debug” or building the debug version by the means of and ADT plug-in, the NDK_DEBUG=1 flag will be added automatically). 

By default, support of a 64-bit utilities version is set; however, you can force the use of a 32-bit toolchain by using NDK_HOST_32BIT=1. Still, Google recommends using 64-bit utilities to improve performance of the large programs. 

How to build a project?

It used to be a painful process. You would install CDT plug-in and download cygwin or mingw compiler; download Android NDK; configure all this stuff in Eclipse settings; and finally, it won’t work. The first time I started working with Android NDK, it took me three days to configure all these things. The problem was in Cygwin: the permission 777 should have been set to the project folder. 

Now it’s much easier. Just follow this link http://developer.android.com/sdk/index.html and download the ADT Bundle, which provides everything you need to start compiling. 

Invoke the native methods from Java code

To call native code from Java, first of all you need to define native methods in Java class. For example: 

native String nativeGetStringFromFile(String path) throws IOException;
native void nativeWriteByteArrayToFile(String path, byte[] b) throws IOException;

You should put the reserved word “native” before the method. In such a way, the compiler knows that this is an entry point in the JNI. These methods should be implemented in C/C++ files. Google also recommends starting naming methods with nativeX, where X stands for the method’s actual name.  Still, before implementing these methods manually you should generate a header file. You can perform this action either manually or using a JDK javah utility. Let’s take it a step further and not run it from the console, but rather by the standard Eclipse means.

• Go to Eclipse and select Run-External Tools-External Tools Configuration;
• Create new configuration;
• Indicate the path to javah.exe from jdk in Location field (for example, C:\Program Files (x86)\Java\jdk1.6.0_35\bin\javah.exe);
• Indicate the path to the directory bin/classes (for example, «${workspace_loc:/NDKBegin/bin/classes}») in the working directory;
• Arguments should be populated with the following argument: “-jni ${java_type_name}” (with no inverted commas).

Now we can run it. Your header files will be stored in the bin/classes directory. 

As a next step, copy these files into the jni directory of the native project. Next, open the project’s context menu and select Android Tools – Add Native Library. This allows us to use jni.h functions. Later on you can create a cpp file (sometimes Eclipse creates it by default) and write methods bodies that have been defined in the header file.   

You won’t find here a sample of code, as I haven’t inserted it on purpose, for the sake of the article’s length and readability.  Please follow the link on GitHub if you need an example https://github.com/viacheslavtitov/NDKBegining

Google Glass: Consumer Device in Enterprise World

You've heard of Google Glass, you have the basic idea of what it does, but you're not sure how it touches you. Right? Then we have something to talk about.
In this article I'm going to shed some light on what it is(and what it's not), how it fits into the enterprise(and how it doesn't), and finally - how can you benefit from it and what will stop you from doing it. You'll also find lots of examples down the road. So, let's start!

Englishman in New York Google Glass in Enterprise

What it is

Well actually it is anything but glasses - it's just a computer with camera, attached to your head:) But let's go step by step.

First of all, we have Android on board, i.e. a POSIX-compatible operating system, which means we could do almost anything we’ve done on mobile phones or desktop computers. The issue is that, as of now, the only official way to build apps for Glass is limited to showing pictures and text. But, unofficially Google lets us use all the features, and as the community is demanding, it seems like a matter of time when it will be official.

Second, we have a smart screen. Why is it smart? Because it’s there when you need it, and gone when you don’t. At least they say so:). The screen turns on on notifications, which you are subscribed to, and manually, by nodding your head lightly. And actually it’s not a screen, it’s projection into infinity. When I tried Glass it took me 5-10 minutes to get used to this.

Then, we have a voice control! That means that we don’t actually need to press any buttons and can keep our hands free. That’s a huge feature. Of course, there’s still a touch pad to cover cases when you want to remain silent. And speaking of sound…they’ve been experimenting with it. Let’s just say that Google Glass can produce sound.

Next, we have a camera, comfortably sitting on your head and seeing everything you see. Most of glass explorers say it’s a killer feature, actually the one that makes glass worth buying. Sharing video while doing your job, gives us a whole new set of opportunities.

And last is the connectivity module. We have Wi-Fi to be self-sufficient, but mostly Glass pairs with mobile phone via Bluetooth and gives us 3G or LTE network together with GPS tracking.
I didn't mention some minor Glass' parts, but you can have a look here for more details.

What it's not
There have been a lot of myths going through the Internet about Google Glass, and I’d like to bust some of them. So, what Google Glass doesn’t do?

First of all it doesn’t do augmented reality. You don’t see the world through the Glass, you see Glass’ screen on top right corner of your view field. So it just doesn’t fit.

Second, you can’t use the camera “secretly”. Google has foreseen this threat and made a design decision to avoid such cases. So, to take a picture we’ll have to say “OK Glass, take a picture” or lift our hand towards our head and press the touch pad. Same goes for video, but while recording, the screen is on, so people will notice you filming them.

Similar situation with face recognition. Google has cut out all standard libraries for face recognition, and also doesn’t allow such applications into their official "store". It is technically possible to implement it but is probably illegal. Yet.

And again the screen. I’ve heard lots of complains that a constant screen in one’s view field will drive people crazy. As I said, the screen is off most of the time and turns on when you need it. Period

Enterprise

Now we're getting to an interesting part. How can we apply it to the enterprise. I'll start from the examples.

Healthcare
Recently Philips together with Accenture have published results of their experiment with Google Glass, which was focused on healthcare. Functionality varied from integrating with Medical Records System, helping managing patients, showing vital signs during the operation and much more.

Warehousing

Another giant, SAP, together with Vuzix have produced their own glasses, specialized for this type of workers. As their demo shows, warehouses workers use optimized path finding, identifying needed palette, scanning barcodes, fixing technical issues by connecting to remote technician and streaming their video.

Maintenance/Tech support

Speaking of tech support, the whole procedure could be simplified, by providing busy technicians with this smart assistant. They could contact their peers and share their screen, look up repair history or take a quick look into the instruction guide while working, and all hands-free!
What's even more important, is that engineers, who use handheld devices at work are actually distracted by them. Moving this device to the default view field would make it more safe.

When is it worth it?

So, following these examples, how do we know when it’s actually worth considering investments into wearables?

Let’s take a look at typical enterprise mobility model. We have field workers, and we equip them with mobile devices, mobile applications and access to corporate network. In return we strongly increase their productivity and improve the business process. Now, there’s this type of workers, whose job requires intensive hand usage. If we equip them with wearable, i.e. hands-free devices, we would not just optimize their work flow, we would also increase their safety. So the key driver to adopting Google Glass-like devices in enterprise is the presence of hands-intensive workers, which would benefit from assistance.

But that’s just the tip of the iceberg. Why limit ourselves with B2E apps? It’s actually more probable that wearables will come into the enterprise from customer side, as it’s a consumer device. A very bright example is banking.

Banking

Most of us already know how important mobile banking is for the customers, and Google Glass could take it to another level. My favorite Google Glass ad is from one of the leading Ukrainian banks PrivatBank, where they show how Glass can simplify our lives. It includes buying things by just taking a look at them, loading car with fuel without even leaving it, finding the ATMs and withdrawing money without the card, and much much more. 

Learning

This is an area where glass explorers have already done a lot. I'll give 2 bright examples
1. A doctor making a knee operation while video-streaming his actions to the students.
2. A physicist having a lesson with his class, while cycling around Hadron Collider

There's also a nice article focused on Google Glass' role in education.

Sports

This is an area where we at ELEKS decided to experiment, as one of the most fruitful sources for integrating wearables into the process and thus expanding interaction scenarios. We've shown how race sports can be changed by equipping participants with live map and leader board, or how group sports can be changed by equipping players with live radar and possibility to see what teammates' see and much more. You can see the interactive video at glass.eleks.com.

Advertising

And what about e-commerce? Retail? Advertising? Public services? At this point wearables come into a perfect combination with contextual awareness. Imagine coming into the airport and automatically receiving notification about your registration desk number, departure gate and flight status. I recommend watching the presentation on NoUI concept and wearables for a bigger picture.

When is it worth it?#2

So Glass can be a very good way to reach your audience. And think of it - these people have consciously put a computer on their head and encouraged you to interact with them in such way. So its probably not a mainstream part of your audience.

Challenges

But let’s step away from the perfect world and face the reality. There is couple of major issues with implementing wearables in the enterprise.

Battery

Seriously, Google glass can take 40 minutes watching youtube, 4 hours standard mode(I didn't expect more from Android:)). There is a great struggle between producing more powerful batteries and wearing them on your head. So good luck here.

Security
We are still in the process of handling current security issues, and bringing this new type of device would cause tones of new concerns. Yes, Google Glass has a good theft protection, but authentication needs to be improved. Also, I imagine, coming to a secure workplace with a camera on your head may be an issue.

User Experience
As I said, screen is smaller, and obviously the interaction is different, so we again need to adapt application logic to it. There are special UX guidelines for building apps for Glass. So we can’t, or at least shouldn’t simply port mobile apps to Glass, just like we shouldn’t port desktop websites to mobile phones. They need to be reconsidered and rebuilt with new usage context in mind.

Priority
I believe most of you have more important problems to solve right now, like BYOD, mobile strategy, teaching your enterprise engineers mobile development, learning about your employees’ workflows and habits, choosing between cross-platform tools or struggling to find a reliable third-party vendor to do this for you... I do not think that focusing main efforts on Glass implementation while having that much on your shoulders is the right thing to do. 

Mass Adoption

Currently there is 10 000 Google Glass items on planet. Comparing to several billions mobile devices. For now, Google Glass is kind of a futuristic device, something cool, unexplored and compelling. But people haven’t got used to it like they did with mobile phones. So adopting it now will take time, efforts and probably training.

And let me guess what you're thinking about right now - "last time we saw mass adoption in mobility, we ended up with BYOD!". So I feel a need to at least touch BYOW

Bring Your Own Wearable?

Obviously Google Glass is not the only "Glass". There is a whole set of other wearable devices: GlassUp, Telepathy, ReconJet, Meta SpaceGlasses and many others. So one could wonder whether BYOD will repeat again.

It’s not clear whether wearables have same future. As technology grows, we see a certain resistance from people to accept them as they become too smart. For example - are you OK with what Google Now does? I sometimes feel uncomfortable, lots of my friends turend it off. Let’s take a look at the numbers. In a recent survey 18% said they’d buy the device. 20% of people agreed that Glass should be banned. More than a half had privacy concerns.  And 69% demanded greater regulation of people wearing the devices in public places. So it remains a great question, whether this new kind of interaction will go massive.

But we have to admit it - Google Glass is the first and probably the only wearable device with potential for mass adoption. Google made a really good marketing job here, which I personally admire.

For more information you can also read this article by Forbes on BYOD and Glass.

What can I do now?

First of all, we have a lot of more important problems and brighter opportunities with mobile devices right now. And I don’t recommend focusing on Google Glass before having more or less stable mobile strategy.

But if you do, you have a whole new set of opportunities! Now, whenever you detect hands intensive job, you know that you can improve it by introducing wearables.

Also, if you’re looking for new ways to reach your customers, Google Glass may just be it – the most effective way to please your most modern target audience.

And although Google Glass is not in public sale yet, you can choose other wearables, or you start building apps for it today, without the device itself.

So, let me finish my saying this - implementing mobility into known business processes and changing them is inspiring. But introducing things like Google Glass, applying them  to the areas where they actually bring value, and being among the first people who've done it - that's just awesome! So let's do it, and let's do it together!

p.s. I've been lucky to get involved in introducing Glass into one of the complex business processes. So in near future you'll see a big success or failure story.

Google Glass Development without Glass

Here are the slides of my "Google Glass Development without Glass" presentation. As I promised, here is the follow-up blogpost with some code samples. If you haven't seen my presentation, I strongly suggest clicking through the slides!

0.Intro

Technologies emerge. Extremely. Wearable trend takes over the world. It seems like every week we start with articles about brand new devices, which would change our life! We've heard about lots of glasses, watches, wristbands, you name it. The most popular one is definitely Google Glass. Actually, it is Glass, who started this wearable hype!
You can just imagine, how all the wearbles can impact our daily and extreme activities. Check out, how we imagined that at eleks: https://glass.eleks.com/

From the other point of view, each new device brings new UX, SDKs and APIs. That's why we, developers, have to quickly adopt to the new techs. In this sense, Google Glass is a rather good device for developers. It runs the world-known Android OS. It just has an extremely strange UI and UX.

Google created a set of "best practices" of awesome Glassware. Actually, it can be applied to any wearble software:

• Design for device -- know & test your device and it's abilities. 
• Don't get in the way -- show the best data when users want it and be out of the way when they don't.
• Keep it timely -- platform is the most effective when in-the-moment and up-to-date.
• Avoid the unexpected -- surprising users with unexpected functionality is bad. On any platform.

Glass is different from the regular phone or tablet. The usual way of creating Android apps is through the Android SDK. Because of specific Glass's usage principles, Google introduced Mirror API. We'll dive into both of them later in the post.

1. Obtaining Glass

If you are among those 10000 people, who have Glass, you can skip this chapter. Unfortunately, that's just 0.000002% of the world's population. So, welcome Stranger to this amazing world of Glass hacking without Glass.

Hopefully, you have some Android device. Then, you can install Google Glass UI there (disclaimer: I've tried this with Nexus 7 tablet with 4.2.2 rom and it worked perfectly, but I can't guarantee it will work on other device). In short, Google Glass UI is just another Home screen provider for your Android. In order to set it up, follow these steps:

1. Go to: https://github.com/zhuowei/Xenologer
2. Download Glass APKs: https://github.com/zhuowei/Xenologer#install
3. Install them as you usually install APKs from third-parties
4. Follow steps at http://imgur.com/a/IBqFf to set up your "Nexus Glass"
5. Say "ok glass, take a picture" and share your "woohoo-reaction" with the world #throughglass

You've obtained Glass. Now its time to hack!
Let's dive into Glass development with the help of our friend Mr. Bond. James Bond.

Once upon a time, he was in London. Somehow, he's got his Google Glass and enjoys the experience on a daily basis.

2. Example #1: Mirror API

If you are eager to try Mirror API out and don't want to mess with quick-start projects, I have a shortcut for you!
Let's try inserting a simple card into Glass Timeline:

1. Go to: Google API Explorer --> Mirror API --> mirror.timeline.insert 
2. Authorise via OAuth 2.0. Use Glass scopes:
• https://www.googleapis.com/auth/glass.timeline
• https://www.googleapis.com/auth/glass.location
3. Populate request fields with values from the API.
4. Execute request!
5. Here's a link with some pre-populated data.

Now it's time to have even more fun! Let's try setting up demo-project.

1. Set up a new project in https://code.google.com/apis/console
2. Go to API Access, update project settings:
1. Add to Redirect URIs: 
• http://localhost:8080/oauth2callback
2. Add to JavaScript origins: 
• https://plusone.google.com
• http://localhost:8080
• https://mirror-api-playground.appspot.com (will be useful later) 
3. Clone https://github.com/googleglass/mirror-quickstart-java
4. Update file src/main/resources/oauth.properties with the values provided in Google API Access Console.
5. mvn jetty:run it.

If everything goes smooth, you'll be able to authorize and have fun with your Glass Timeline! If you want to have even more fun with Mirror API, especially with Subscriptions to Location and Notifications, you should deploy your war to the real webserver. Google sends these updates only to https secured web-sites. For development purposes you can use provided ssl-proxy. Just modify MirrorClient#insertSubscription method.

3. Example #2: GDK

Update: Google recently released GDK Sneak Peak. Right now, when you try creating apps with it and running it on Nexus Glass, you'll get [INSTALL_FAILED_MISSING_SHARED_LIBRARY]. We're trying to find the way, to avoid that. As of now, there's no support for the official GDK Sneak Peak (auth, live cards, etc).

Google Glass is just another Android device with 640x360 screen (hello, screen fragmentation), Android 4.0.4, API level 15. Maybe, in the next releases of Glass, this will change. Now, when you want to port your existing Android app to Google Glass, you should just:

1. Build your APK.
2. Install it.
3. Run via adb.
4. Understand, that you need to update touch gestures support.
5. Understand, that your UI is hardly usable.
6. Understand, that your awesome Google Maps stopped working.
7. So, double-check your application on real device! Everything can change in the near future!

It's a good idea to check out Google Glass Quick Start by Google. It explains a lot about Timeline, UI, Gestures and current limitations of the GDK.

In order to support touch gestures of Google Glass, have a look at this article: Touch Gestures. In short, here's the table with events corresponding to keycodes:

Tap	KEYCODE_DPAD_CENTER
Swipe right	KEYCODE_TAB
Swipe left	KEYCODE_TAB + isShiftPressed()
Swipe down	KEYCODE_BACK
Camera	KEYCODE_CAMERA

4. Example #3: GDK + Timeline API

Update: Google released GDKvXE12 update. It has Static Card support, but it is still limited and lacks menus, html templates, etc. The code mentioned below follows hacky way and may not work on the latest version of Glass.

So far, we've tried the official Mirror API way and the hacky GDK road. Now its time to combine both approaches. Let's insert a card into Timeline from withing your app!

I've  set up a sample project at github for you: https://github.com/pif/ukrbash-for-glass. After you fork/clone it, you can see glasslib.jar inside libs folder. This library would probably become the aforementioned GDK. It provides everything you need to know about Timeline UI.

All the magic is done via these steps:

1. Initialise Timeline, get Timeline contentresolver. Look at:
   com.andrusiv.glass.bash.GlassService#onStartCommand(Intent, int, int).
2. Create MenuItems for your card.
3. Create TimelineItem.
4. Insert it into ContentResolver.

Look through the classes & methods provided inside glasslib.jar. I hope, you'll find loads of interesting information!

5. Outro

Thanks everyone, for reading all the way down here. I hope now you have your pseudo-Glass and know how to develop for it. Share your experience in the comments and on github! Ok guys, have fun #throughglass!

https://plus.google.com/+GoogleGlass/photos

Mobile Strategy Choices. Unraveled

This topic is obviously not new. Everyone talks about it. Sooner or later. After making these choices couple of times and talking with customers I noticed common misunderstanding, misuse and mistakes people do(and so did I). There are lots of great articles out there which help out deciding, but still I think it could be brought in a better form. And that's what I'm doing here. I'm delivering mobile technology choices in a form of Binary Decision Tree. I'm starting with the results, further on I'll cover it with the details, and in the end I'll give 4 case studies which demonstrate different choices.

And don't get me wrong. I don't like the idea of silver bullet work flow chart that makes the decision for you(though here's a good one, still I disagree with some points). This decision tree is intended to help you better understand the correlations between your requirements and corresponding technology. You can think of it as unraveling the cables behind that old audio/TV/any system. It's still complicated, but it's much clearer now.

So, how does it work? Basic idea is to define your requirements from the product vision, and then, by prioritizing them, go left or right in a tree. Then you repeat it until you've reached the leafs, i.e. the bottom of a tree. Pretty easy, isn't it?

Now let's delve into details.

Choosing between App and Web Site

I intentionally rooted my decision tree with a Vision, as this is a thing, without which you cannot start choosing the technology. You have to know what you're aiming for before you start shooting. Then, you need to turn the vision into some more specific requirements. I'll help determining the criteria, but there is still work to be done with setting the requirements and understanding them.

The first choice to be made is whether you want a Mobile App or Web App(Site). You probably heard of topics like "HTML5 vs Native." I think it's a bit confusing and too generic comparison, as with HTML5 you can build both web and mobile apps. My point is that you shouldn't choose between Native and Web. Native is a way of implementing Mobile App. Web is a whole family of apps, with its attributes and specialties. Instead, you should choose between Web and App approaches as they deliver more or less equal alternatives, cover different usage scenarios and reflect different marketing channels. And these are basic criteria you want to base upon when choosing mobile strategy.

So, the criteria. I'll start with the easy ones: if you know you're gonna need access to device features(gyroscope, accelerometer, bluetooth, contacts, calendar, push notifications), you care about security or you need non-trivial computation tasks - in these cases you can forget about Web App. You simply don't have required APIs for device features, you don't have infrastructure for security and web has been proven not to be able to deal with heavy-computational tasks.

Please note, I didn't include offline and camera access here on purpose. This is one of most common confusions people make in this field. Web has already grown to an extent where whole websites can go offline(and I'll give you an example later on). And about camera - there is a big progress and workarounds there so before eliminating web as a platform for your app it's better to make deeper investigation. I must say, in my humble opinion, HTML5 s moving(slowly though) towards accessing all these device features, so in future(far future) that will not be a show stopper.

Then, if you don't have a need for any of listed above, you need to define and prioritize the following criteria.

User Experience
Questions: What do you expect from user? How do you want to interact with him? Do you want him just to read information or to input something? How often do you want him to use your app?
Hints: Mobile apps are more adapted for interacting with users and entering information, although skilled web developer can nail it in the web. In contrast, when a user just googles for some information, he doesn't want to download the app, he just needs the piece of advice as quickly as possible. Yes, by the way, one fact you should always keep in mind - mobile users are much less patient than desktop users. As Eric Reiss, usability expert, states, the three-clicks rule is not applicable to the mobile environment. Users will leave your system the moment they feel it doesn't bring much use to them, i.e. possibly after the first click.

Content
Q: What is it that you're showing to your user? Is it a daily newspaper article, or a 3D model of his new house? Or maybe a medical record input form?
H: Content is tightly integrated with user experience, he actually defines it. I highlighted it as a separate criterion to help you better understand your UX strategy. Here's a good popular tip from Prasant Varghese:

If your goal is just to display and show content, I suggest a responsive or mobilized website. If your goal is to show productivity tools, build an app

Distribution Model
Q: How do you want to deploy your app? How do you want to deliver updates? How do you want users to reach your app? What is your maximal time-to-market?
H: Apple has started a very good culture with its AppStore. Apps there are easy to find, to choose between competitors thanks to rating & comments and have good compatibility model. Those are huge pros for mobile apps. The con would be bigger time-to-market because of Apple's and Microsoft's review process(if you're aiming Android, BB or enterprise that's not a  problem). Also, there may be scenario where you want to employ your own distribution model, or you already have good SEO rating for your website and just want it to go mobile. Choice is yours.

Monetization Model

Q: How do you return your investment? Is it a part of your marketing

campaign? Or are you going to monetize your application? Do you want to use built-in methods of payment?
H: Some build apps to sell them. Some to market their company. Some to improve their employees productivity. Anyway, if you want to deal with money, it's better to go the App way, as there are built-in user-friendly ways to handle money transfer from inside the app, or when buying the app itself. Again, if you have your own well-made monetization model you can go your way

Portability
Q: Who is your target audience? What devices are they using? Phones? Tablets? Phablets? Which OS? How much devices are your going to support? Is functionality the same for all devices?
H: Both App and Web can give you great portability, just for different cost. Going Web usually means (if made correctly) that everyone can use it. When going the App way, you'll have to pay more(Native) or less(Hybrid) for every new platform. Learn your audience and what devices they are using. If you have really diverse audience(e.g. you're a food retailer) and your customers have all range of phones from old Nokias to brand new Nexus' it makes sense to have a website which will cover them all. On the contrary, if you have more specific customers, like lawyers, who usually use iPhones, you can save some budget by cutting support of other screen sizes or platforms. One more advice - don't rely on statistics of browsing your (desktop) site from different operating systems too much . It is typical that user who has visited your site and didn't like it, won't visit it anymore. Better learn who do you want to use your system.

Budget
Q: How far can you go to reach the best quality? Where is "good enough" for you? What is the long-term planning?
H: For most people this is final word. Keep in mind cost of development, testing, maintenance, deployment etc. It's not a secret that App way will be more costly. You should also consider in what tools and technologies you want to investigate, i.e. what types of applications you are going to build in future.
Also, consider choosing both ways - Web and Apps for several platforms. Here's a quote from Jason King which describes budgeting very well (source)

Desktop, mobile web, and apps are all different marketing channels. You have to decide where to focus your development budget...If you have the budget, do it all.

A very popular scenario is to develop an app for most important audience and make a web site with limited functionality to cover all the rest. When budget is limited and functionality allows, the killer combination is HTML5 code base with tuning for accessing device features for Hybrid tools(PhoneGap, Titanium) and tuning for workarounds without these features for web site. But don't ask me about maintaining this code base and the number of branches there.

Also, note that I didn't give such popular criterion as availability of developers for right technology. I'm sorry, that's just too obvious for me. If you don't have people to use certain technology - then you can't afford it. Or, if you really need some technology - you'll find the people somewhere.

Just to use the right moment, here's another good source of topic that we were talking about.

So, we've made the most important part - we've set a line between an app and a site. Now we're going to see the difference in technologies for developing each. I like the polish notation, so will go to the apps first.

Choosing technology for the App

First of all, let me give my definitions of Native and Hybrid. I call Native the official way to build mobile applications, as declared by each platform's vendor, i.e. Java + Android SDK for Android, Objective C + iOS SDK for iOS etc. I call Hybrid all the tools to develop mobile apps in any other way. Still on Internet more accepted term for Hybrid is something between Web and Mobile App.

Now, to set the right angle for this conversation I'll start with the following fact. When each mobile platform was out, the only way to develop applications for it were the recommended vendors tools, i.e. native APIs and correspondent programming languages. Later, as the tools were a bit difficult to migrate from mainstream web development to uprising mobile development, people started inventing hacks, which could simplify this procedure. Remember ASP.NET? When Microsoft tried to help shifting desktop developers to web development with hacks like viewstate? Well, this is something similar. 

Another problem Hybrid tools solve is cross-platform development. So that you can build one application which would work everywhere. Without worrying how it works on all these platforms. But these hacking tools don't save people from learning all the aspects of mobile development. At least they shouldn't. And that's a very common mistake - to think that knowledge of language will save from learning the infrastructure. Sooner or later you'll have to deal  with the details. And same way we learned about hurdles with viewstate we'll have to learn about hurdles of Hybrid tools. And that's the way it is.

As for me, the choice between Native and Hybrid is the matter of investment. If you buy something expensive, you get good quality result, no head ache and smooth process. If you buy something cheap, and save money, it has to show up at some point. You get either worse quality, a lot of problems down the road or the high risk of failure. It's like buying tickets from resellers at the concert - they're twice cheaper, but you have no guarantee you'll get inside. So think twice, whether you want such an approach for your business.

Still there are situations where Hybrid can be the right choice without a big loss. I've set 5 criteria for choosing between Native and Hybrid approaches(which intersect at some points with your previous choices)

Future

The big drawback of Hybrid approach is that at some point you just might get stuck and not be able to implement something as when using Native approach. And although in most Hybrid tools there's a space for injecting native parts, it might get really tricky. So my recommendation is not to choose Hybrid if you see great extensions to functionality of your app in future.

Risks

Define the level of risk you can take. The risk of failure, the risk of higher costs of maintenance, of getting stuck and switching to Native, of immature technology and community, all the other risks. If you have a mission-critical project - go Native.

Portability

Again. If you target more then 2 platforms it makes sense to go Hybrid. But don't underestimate the cost of adapting the codebase to each platform. Write-once-run-everywhere is a myth. It's rather write-once-fix-everywhere. There are lots of design differences between Android, iOS and other platforms, which you'll have to take into account. Also building and deploying processes are specific to each platform.

Performance

Obviously, and as it was mentioned before, Hybrid apps are usually slower(although Cross-compiled seem to make a difference). The very well known fact is that Facebook dropped their Hybrid approach because it simply didn't meet the UX expectations from users and they didn't use it. When Facebook switched to Native it was a bliss for users and a shame for HTML5-believers. Though Sencha quickly responded to this. A lot of people use it as an argument for Hybrid apps. But I'll tell you one thing, this demo was built not as a Hybrid app, but as a Web Site. And it's a very well-known fact that hybrid apps are much trickier than websites, because WebViews are more limited then browsers(e.g. no Nitro engine on iOS). So if you got on this side of the tree because of performance or UX then it's very simple - go Native.

Budget

Of course. I've already said too much about it. No more comments.

Choosing between Hybrid technologies

It may be a surprise for someone, but people actually created a lot of ways just not to deal with Objective C:) No, just kidding. The idea of cross-platform development isn't new - we've had it with Java for Linux, Windows and the rest of the company, we had it with HTML5 for different browsers, there's similar problems in gaming world(PlayStation, XBox etc). It's absolutely normal to want your code to work across all the platforms. But the world is not fair, and this comes with the price.

So, there are basically three ways to write Hybrid apps. Two of them are very similar, which is why I've distinguished only 2 in a decision tree. I'm not going into too much details here, but I'll give basic idea about how they work, what are the differences and what are the choosing criteria.

WebView-based, aka PhoneGap

The idea is that you put a single control called WebView on native part(instead of building page control tree as it's done in Native way), and write all your functionality inside it. The WebView is kind of a web browser inside native app. This way, you build mobile application as static web site, but it will be a bit slower. The communication layer between native and WebView environments lets you use all functionality from native part by using special javascript APIs. In return you get a lot of head ache and mystery. For more details see my previous blog post about PhoneGap.

Custom container-based, aka Titanium

The idea is that you have a container on native part, inside which you execute your custom code (in Titanium it's javascript), and you have a communication layer between native and containerized part, so you can also access all native features. This container could be V8, Rhino, a mentioned WebView or many others. All container has to do is execute custom code and provide communication between 2 worlds. With this approach you generally do not build a mobile app as a static web site, you only reuse javascript code base. In further discussion I won't distinguish these 2 approaches as technically they are subset of one another and practically the pros and cons are almost the same, although their philosophies differ. Here's a good article from Appcelerator's employee comparing PhoneGap and Titanium.

Cross-compiled, aka Xamarin

The idea is that you write code in one language that will be later cross-compiled to other platforms' native code. This way you get both cross-platform code and native experience. Although you can reuse only core logic, you'll have to write UI for each platform separately. A fair limitation, imho. A bit confusing, and with a lot of questions(memory management, language specific structures etc), but a very promising approach. I personally like it because unlike containerized approaches it doesn't abstract you away from each platform's architecture. You still have to be aware of how each platform works. You just get your favorite language codebase across the project. A detailed article on Xamarin is soon to be released on elekslabs.com. 

Before comparing these I'll remind you - you're on this part of the tree because you are have the low budget, you accept risks, you don't expect a great performance or you look for great portability. 

To be honest, Cross-compiled looks like something between the Containerized and Native ways. A bit less performant then Native, a bit less portable then Hybrid, a bit more expensive then Containerized. But I decided to leave it on this side of the tree as it still provides great risks of unknown and the most representing platform is still on its maturation journey. If this wouldn't be a binary tree maybe I'd put it in the middle. Now, I see 4 criteria for choosing Cross-compiled vs Containerized.

Native Experience

How close to Native do you want to get? Now that you're in this risky part of the tree, you still can get good performance if you go Cross-Compiled

Platform Maturity

With all respect to Xamarin, PhoneGap is a bit older, and has at least taken its fair place in technology comparison. Not every average developer is aware of Xamarin and how it works, but most of them have heard about PhoneGap(good or bad stuff)

Preferred Tools

Hybrid approach is based on reusing existing skills. So if you are ready for taking Hybrid approach you can choose language and tools you like more. Me, for example, I feel more productive when armed with C#/R#/VS then with JS/N++ although I love both.

Portability

Third time in a row. I'll say it quickly. As Xamarin apps can't reuse UI part, it's a bit harder to migrate code base across platforms with Cross-Compiled.

Few, that's it, we're done with all the apps stuff. Just to take a fresh breath I'll share the beauty which inspired me while writing this article.

Choosing between Web technologies

There are 2 popular ways of building mobile-friendly web site: making a separate web site for small-screened devices or making a web site which would fit to all kinds of screens, i.e. a responsive web site. Let's see how they can be compared and when to choose which one.

Screen Size Range

It's a similar question to portability. How diverse is your user base? Do you need to support every couple of inches or is a common 3-4 inch enough for you? Do you want to support Tablets?

With Responsive approach you'll have a good appearance on all kinds of devices. If you want to achieve it with separate site, you'll have to build couple of them, for different screen sizes each. But usually a separate site is done when only mobile phones are in focus and average appearance on tablets is satisfactory.

Support

If you have 2 web sites, you must understand how much more difficult it is to support them - from fixing bugs to changing content. In terms of support Responsive wins the battle

SEO

As with Responsive you've got only one site, you have the ranking summed up from mobile and desktop devices. That's a big advantage for discoverability.

Full Redesign 

All these benefits come with a prize. To build a Responsive site you usually need a full redesign of you existing site, which would of course cost more then just implementing mobile-friendly version. In case you're building a new site , it's not a problem. But if you're in a middle or running business and have just recently updated your web-site's design you have a tough decision to make.

Budget

There are lots of discussions on Internet about which approach is cheaper. The general agreement is that Responsive is cheaper in a long-term, but more expensive in the beginning, especially if you're dropping your previous design to make a brand-new mobile&tablet-friendly web site.

To keep you reading here are some interesting articles comparing these two approaches.

Ok, now we're done with decision tree, and to wrap it up I'll give you couple of case studies which prove all the text above.

Case Studies

All case studies here are examples of the projects we did here on ELEKS. The fact is that the most popular decision among our customers is opting for the App. But we also had less obvious technology choices, and I'll share them with you to demonstrate how diverse requirements can be and what technologies they fit the best.

An all-platforms App for Time Tracking

Back around 2005, when all enterprises were still on BlackBerry, we were in a middle of a huge project, developing product for lawyers' time-tracking. The system worked well without mobile part, but the time has come and mobilization took it's part. 

The purpose of product was to simplify reporting process for lawyers and help them create and manage records. And mobile phones was a great enhancement to general idea. Records could've been created based on calls received, emails read and meetings attended. And that's exactly what customer asked us to do. As we needed to support only BlackBerry, and the budget was fair, no one even thought about other ways then building apps the way RIM recommends to. And that even wouldn't be possible as we needed access to a lot of device features. Decision was made, application was built, everybody was happy.

And then iPhone came out in 2007. We couldn't reach same functionality because of platform limitations, but still it was a native app. At some point of communication with customer  there was an idea to switch to Hybrid, but the decision from customer was very clear - the product is meant to improve lawyers' productivity, so it needs to be on top of user experience practices. And couple of years later we started developing Android version. So we have an app running on 3 platforms, and it's still Native.

A Mobile Web App for Healthcare

At 2009, we had a lead from one US customer, asking us if we could build mobile medicare software product. The functionality would be not far from common - inputting information about patients, receiving some information from server etc. Although there were tricky parts, like supporting offlline mode and syncing with server when going online. Customer wanted the app for iOS, Android and possibly other platforms. We evaluated the functionality, and identified potential simplification with HTML5  which wasn't so much HTML5 back then. Still even then, there was a documentation on Offline Manifest and local storage with doubtful support among browsers. To make it clear, the idea of cache manifest is to include a file in your web site, which will tell the browser which files it needs to cache locally, so that if user visits web site again without access to internet, the browser opens the cached version. So we made a prototype and it worked! (not without surprises of course). At least on out target browsers, mobile ones, it did. Customer was more then happy for a double cost reduction and a little change in user experience(opening browser bookmark instead of opening the app) was more then ok price for such a big save. So we were glad to win the lead and the customer was glad to save money. As far as we know users are very satisfied with the system too. What a love story! For more details you can read this document.

A Hybrid App with Native injections for Logistics

Somewhere around 2008-2009 we had a task to implement a small app to help couriers do their job more effectively. Each one of them would receive an Android tablet, and every morning all of them would had a list of new orders, which was shared between them. Everyone could pick orders that was closer to him and everybody else would see it. This process was managed by coordinator and his responsibility was to deliver all orders. Also, when courier delivered the order he asked to recepient to sign on the tablet(yes, physically draw the signature over a tablet with a stylus), which would generate a PDF document, that was saved on server then. When choosing, our main priority, brought from customer, was budget. So we looked for ways to do it cheap. The functionality wasn't that difficult, most of development time was estimated for UI controls, as we needed a long grid with checkboxes, buttons and other custom controls. As Android was still raw back then, and we had good web specialists, we decided to try a Hybrid approach, by reusing Ext.js controls and therefore saving a lot of time. But take into account - there was no PhoneGap at that moment. And this solution was even more riskier then it is now. And we had to implement our own communication layer between JavaScript and Java. Surprisingly from retrospective, but it worked, worked well and was still much cheaper then going Native.
But then we got to signing functionality. It was way too slow through WebView layer. But impossible is nothing! We implemented it in Java, the Native way, and injected into the hybrid part of application. And everyone was happy ever after :)
I love this example as it shows how combining different technologial approaches may benefit the final result. For more details you can follow this link.

An ELEKS' Responsive Web Site

Recently our marketing department together with UX department had a great challenge to showcase our expertise in Web Design and Web Development by redesigning our own web site. The main priority of course was the quality of the result. We knew that we will update the content frequently, that we want to reach as wide audience as possible, that all we want is to present information, not to interact with users. So it was clear that we don't need an app, and it was clear that we don't want two separate websites. We wanted responsive. And, in my humble opinion, as a person who didn't participate in this project, the result is awesome. Oh, yes, it's not just my opinion, we won quite nice awards for this work. Here's a nice interactive case study explaining how me made it.

That's all, folks

I was very happy to share this knowledge with you, and I'd be even more happy with comments/critics/discussions on this topic. Feel more then welcome to contact me at markiyan.matsekh@eleks.com and stay tuned for more interesting articles on elekslabs.com. I'm planning to release research articles on Enterprise Mobility, Xamarin, and Wearable Technologies in not to distant future.