Configuring Icenium LiveSync with the SGS3

Icenium LiveSync enables you to easily deploy an app in development to one or more devices and see changes made–in real-time in both the integrated device simulator and across all connected devices–without having to recompile. In order for LiveSync to work, your development environment must be able to communicate with the device. For Android devices this requires communication using the Android Debug Bridge (ADB). This video shows you how to set up your development environment to enable LiveSync between Graphite and the Samsung Galaxy S III.

This video shows you all the steps outlined in this blog post.

What to Do

The steps outlined in the video are simple and easy to complete.

  1. Install the Samsung Android USB Driver for Windows
  2. Enable Debug Mode on the Device
  3. Optionally Verify with ADB

Install the Samsung Android USB Driver for Windows

This is pretty straight forward. Go here and download the Samsung Android USB Driver for Windows. This is the driver package for many of the Samsung devices, including the SGS3 and other smartphones and tablets in the Galaxy product line.

Enable Debug Mode on the Device

For any device that will be communicating over the ADB, you must enable USB Debugging. On the SGS3 this is in Settings > Developer Options. Check the box for USB Debugging so that there is a green check mark in the box.

Optionally Verify with ADB

When you installed Icenium Graphite part of the installation package included the Android Debug Bridge, which is used for LiveSync communication between Graphite and the devices. You can use ADB in a command line to verify that your SGS3 is visible to ADB (this isn’t necessary, but can be useful if you are troubleshooting any device connection issues).

  1. Open a command line end enter:
    cd %USERPROFILE%\AppData\Local\Temp\ADB
  2. Enter:
    adb devices

You should see a device ID for your SGS3 (for example, in the video mine is 4df1d84539005ffd).

That’s it – you are all set. When you create or open a project in Icenium and your SGS3 is connected, you should see it in the Device list.

Should You Go Hybrid?

Over the past week, since we released the first beta of Icenium, I’ve been talking with lots of web and mobile web developers who are either starting to develop apps for mobile devices, or who are going to be starting soon. These folks, who are new to building apps that run on devices, have lots of questions about the options available to them, and lots of confusion over native-vs-mobile web-vs-hybrid.

For the purposes of this conversation, I’ll use the following definitions:

  • Native apps are built for a specific platform with the platform SDK, tools and languages, typically provided by the platform vendor (e.g. xCode/Objective-C for iOS, Eclipse/Java for Android, Visual Studio/C# for Widnows Phone).
  • Mobile Web apps are server-side apps, built with any server-side technology (PHP, Node.js, ASP.NET) that render HTML that has been styled so that it renders well on a device form factor.
  • Hybrid apps, like native apps, run on the device, and are written with web technologies (HTML5, CSS and JavaScript). Hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in Mobile Web applications, such as the accelerometer, camera and local storage.

What Should I Choose?

One of the most common concerns for web developers new to the mobile app world is the learning curve required to build native apps, or the lack of education on what a hybrid app is. My advice is, before committing down a single path, consider the user experience and what each option provides you. Native apps will always provide the fastest performance, at the cost of being more complex to code when compared to a hybrid app, while a hybrid app will be easier to build, using HTML5 and JavaScript, at the cost of giving up a little bit of speed. If the user experience you want to create is a Need for Speed style game, chances are you’ll want to use native technology to implement the app for each mobile platform you’re targeting in order to get the best graphics performance. If you want to build the next Foursquare, using geolocation and providing a means for displaying data and updating data, a hybrid app is a perfect solution and enables you to build it once, publish it through app stores, and have it work on several platforms.

Like any other technology choice, deciding between native and hybrid requires you to look at the user experience and decide on the level of investment you need to make to achieve the goal. Native apps will always require more investment because they are written with more complex languages, designs and structures. They also need to be written/rewritten for each mobile platform you are targeting. Hybrid apps will always enable you to build for more platforms faster, if you are willing to sacrifice small amounts of performance (e.g. game-level responsiveness).

What is a Hybrid App?

Hybrid, by definition is anything derived from heterogeneous sources, or composed of elements of different or incongruous kinds. A hybrid app is one that is written with the same technology used for websites and mobile web implementations, and that is hosted or runs inside a native container on a mobile device. It is the marriage of web technology and native execution.

Hybrid apps use a web view control (UIWebView on iOS, WebView on Android and others) to present the HTML and JavaScript files in a full-screen format, using the native browser rendering engine (not the browser itself). WebKit is the browser rendering engine that is used on iOS, Android, Blackberry and others. That means that the HTML and JavaScript used to construct a hybrid app is rendered/processed by the WebKit rendering engine (for you Windows 8 folks, this is what the IE10 engine does for Metro style apps that use WinJS) and displayed to the user in a full-screen web view control, not in a browser. No longer are you constrained to using HTML and JavaScript for only in-browser implementations on mobile devices.

The real secret sauce of hybrid apps is the implementation of an abstraction layer that exposes the device capabilities (read: native APIs) to the hybrid app as a JavaScript API. This is something not possible with Mobile Web implementations because of the security boundary between the browser and the device APIs. Apache Cordova (formerly PhoneGap) is an example of a JavaScript abstraction layer over native APIs (for you Windows 8 folks, WinJS is another example of a JavaScript abstraction layer on top of native APIs). Through this abstraction layer a common set of APIs is exposed in JavaScript, and these JavaScript APIs work on any device supported by the framework (for WinJS that’s only Windows 8, but for Cordova that is seven mobile platforms including iOS, Android, Blackberry and Windows Phone 7). When the native wrapper is compiled around the HTML, CSS and JavaScript resources, there is an interop layer added that connects the JavaScript APIs with the platform specific APIs.

What this really means is that, for example if I build a mobile app with Apache Cordova, I can use JavaScript to access a native API, like the camera, using a single API call regardless of what platform the app will run on.

navigator.camera.getPicture (onCameraSuccess, onCameraError, { quality: 50,
    destinationType: Camera.DestinationType.DATA_URL
});

function onCameraSuccess (imageData) {
    var image = document.getElementById('myImage');
    image.src = "data:image/jpeg;base64," + imageData;
}

function onCameraError (message) {
    alert('Failed because: ' + message);
}

Under the covers the JavaScript is making an interop call that access the native API for the camera. That means that on an iOS device this JavaScript is calling into the native layer to instantiate a  UIImagePickerController and on Android it creates an Intent to use MediaStore.ACTION_IMAGE_CAPTURE to take a picture. When developing a hybrid app you don’t need to worry about this level of detail. All you need to do is call the JavaScript function (navigator.camera.getPicture() in this case), and respond to the outcome (the imageData passed to the onCameraSuccess call back function in this case).

Summary

Hybrid apps are a great option for you if you:

  1. Want to target multiple mobile platforms
  2. Want to take advantage of device capabilities like geolocation, accelerometer or the camera
  3. Want the app to be useable when the device is offline
  4. Don’t need the advanced graphics performance that you can only get from a native app.

Hybrid apps are built with web technologies which means there are millions of web developers who already have the base skill set to build mobile apps.

Here is a graph that highlights the differences in native, hybrid and mobile web applications.