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.
Install the Samsung Android USB Driver for Windows
Enable Debug Mode on the Device
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).
Open a command line end enter: cd %USERPROFILE%\AppData\Local\Temp\ADB
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.
Since we released Icenium a couple weeks ago, a few folks have asked me if it could be used to build apps for the new Kindle Fire HD. The simple answer is “Yes.” The Fire HD is an Android Ice Cream Sandwich (v4.0.x) device, and Android (v2.2 and greater) is a supported operating system for Icenium projects.
In order for Icenium to communicate with devices over USB, and deploy and update apps, the device drives for those devices have to be installed and configured on the PC. For Apple iOS devices, the device drivers are included in iTunes. For Samsung devices, most of these are in Samsung Kies. For HTC devices, these are in HTC SyncManager. You get it.
But what about Amazon? They don’t have a utility like this.
Setting up the Kindle Fire (1st Generation) to work with Icenium LiveSync was pretty straight forward – download the USB driver, update an INI file and wham-o, it works. Then Amazon released the Kindle Fire HD, which included an updated operating system (the original Kindle was based on Android Gingerbread – v2.3.4) and it was proclaimed to be unhackable. This meant that for developers it was going to be a challenge to work with it as a development device in any way not prescribed by Amazon. Of course the official guidance is to use the Android SDK, platform tools and Eclipse as your development environment. Yuck.
When you plug in a Fire HD, it installs a driver that enables you to copy media files to and from the device, but it doesn’t enable the Android Debug Bridge (ADB) to access the device to install apps. Icenium LiveSync uses ADB for the communication to Android devices to enable deployment and updates on devices (don’t worry, you don’t need the Android SDK for this, ADB is installed in C:\Users\<usernmae>\AppData\Local\Temp\ when Icenium Graphite is installed).
I bought a Kindle Fire HD 7” and began following the unofficial steps to connect to it as a development device. Turns out it was very troublesome, especially if I refused to download the Android SDK. I found a few blog posts that all pointed back to a forum post on how to root the Fire HD, so I gave it a shot. Unfortunately for me when I followed the steps it didn’t work. No matter what I tried, the correct driver would get installed, and the Fire HD wouldn’t show up in the ADB device list.
Rather than get discouraged, I experimented and got it to work. The steps in the forum post may work for you, but they didn’t work for me right away. The only ADB driver that I could get to install was the Android ADB Interface (not the Android Composite ADB Interface driver as outlined in the forum post). I had to manually install a different driver (a generic USB Composite Device driver), and then the Kindle Fire HD was recognized by ADB.
After that, I connected the Kindle Fire (1st Gen) that I previously had working, and the Android Composite ADB Interface driver magically appeared. I disconnected both Kindle devices and reconnected them and both of updated to the Android Composite ADB Interface driver.
Now both the Kindle Fire 1st Gen and the Kindle Fire HD were visible to ADB…
…which meant that both devices are ready to by used by Icenium LiveSync.
Now when I click on “Run on Device” the app is compiled in the cloud for Android using the Icenium Compiler Service and pushed through Icenium Graphite and over ADB to the devices.
That’s it. Now you can test your Icenium project on either a Kindle Fire or Kindle Fire HD. As soon as the Fire HD 8.9” arrives, I’ll give that a test.
And stay tuned for a video series on Icenium LiveSync called “Getting to 50’ where I will add various devices to see if we can successfully support simultaneous LiveSync to 50 devices.
In the past couple of days since I announced the release of Icenium, I’ve had a number of people asking me if it supports Windows Phone in addition to Apple iOS and Google Android. I suppose that is because nearly all other Telerik products are dedicated to the Microsoft technology stack, so it would be almost expected that Icenium would get on the band-wagon.
Its All About the Data
Allow me to let data do the speaking:
In the past year Apple and Google have grown in market share by nearly 17% (Source: comScore, U.S. Mobile Subscriber Market Share). In that same period, Microsoft dropped nearly 2% – meaning Apple and Google are outpacing Microsoft by nearly 20%. In fact, Apple and Google are the only two mobile platform providers that have been consistently growing in market share during that period.
So I decided to focus our efforts on Apple and Google. Microsoft will have to wait.
What Will Windows Phone Do?
I used to be a Windows Phone user. I loved my Windows Phone (I missed a lot of the apps from my old iPhone, but I LOVED the operating system and the Live Tiles). In the last year I have regularly switched phones every month or two, trying out several Android devices in addition to the iPhone 4/4S and now iPhone 5. I’m a believer in Windows Phone – I think it is a great operating system. That is completely separate from the business decisions I make.
With Windows Phone 7 already on death row, and the success of Windows Phone 8 nothing more than speculation (like this and this), I didn’t feel like WIndows Phone warranted our time…yet. I am bullish on Windows Phone. Like I said, I love the OS and the new hardware is looking pretty good.
I have maintained a wait-and-see stance on adding Windows Phone support to Icenium.
We’re Not Waiting Idle
Of course, Telerik has a lot of knowledge in Windows Phone, which means we’ve already done some research. We’ve done a proof-of-concept to learn more about what it would take to support Windows Phone, and we know what we need in order to give Windows Phone the Icenium treatment. We’ve already engaged Microsoft to work out some of the details, in the event we decide to move forward.
Over the next few weeks we’ll be watching the early adoption of Windows Phone to see what the consumer reaction is, and use that to make some decisions about how we prioritize our backlog for the remainder of the year, and early 2013.
OK, What About Windows 8?
Having worked on Windows 8 tooling before I left Microsoft, I feel like I know the app-type Formerly Known as Metro (FKM) pretty well. I’m curious to see how consumers and enterprises react to both the app-type and the new hardware. Clearly Windows 8 will be successful in the PC market – although I’m not sure how well PC users will take to the FKM style apps.
For the mobile device market, the success of the Surface with Windows RT (Surface RT) and the OEM tablet form factors will have a huge impact on the success of FKM apps on devices. If the hardware isn’t sexy, the Windows 8 tablet will suffer the same fate as Windows Phone 7.
Like WIndows Phone 8, I am bullish on Windows 8, and the Surface RT – I’d say I am even more bullish on Windows 8 than Windows Phone 8. I’ve already pre-ordered my Surface RT and a Windows 8 Ultrabook with a touchscreen.
Keep Your Fingers Crossed (and Buy a Surface RT)
I hope that helps you understand some of the decision making process I used for deciding what platforms to support in the initial offering of Icenium. We have aspirations to support all relevant platforms – and right now that definition excludes Windows 8 and Windows Phone 8. Let’s hope that changes.
I’d love to see a three-horse race in the mobile market.
Today is a day that my team and I have been looking forward to for a long time. Today I am happy to announce that Icenium, an Integrated Cloud Environment (ICE) for hybrid mobile app development, is now available to everyone!
The Story Begins
Back in July 2011, I left Microsoft and joined Telerik to take on an ambitious idea. In my time at Microsoft I had spoken with hundreds of developers and was able to witness first-hand the frustration that many of them felt working with Integrated Development Environments (IDEs) – they were big, bloated and most were designed with only one platform, or one platform vendor in mind (e.g. Visual Studio, xCode, etc.). For developers that targeted multiple platforms, using these IDEs meant downloading, installing and managing multiple platform SDKs and two or more separate development environments. For example, targeting the most relevant platforms in the world today – iOS and Android – meant using xCode with Objective C and Eclipse with Java, along with all the SDKs and tools that go along with them. Nearly 3 GB of downloads to install and maintain (not to mention, you have to have a Mac OS X environment, automatically excluding Windows-based developers). I was no different from the developers I talked to. I used these tools all the time. They took up a lot of my time to download and configure, they took up a lot of hard drive space, and they required a powerful development machine.
I also observed that while I was writing code, I was also listening to music from Pandora, saving documents in DropBox, and keeping notes in Evernote. Nearly everything I used daily was not only cloud-connected, but the cloud played a significant role in enabling the technology; that is, the technology wouldn’t have functioned without the cloud. Everything except my development tools (OK, maybe I’d deploy an app to the cloud, but the cloud didn’t aid me in my development efforts).
An ICE Age is Coming
The idea that a development environment required all of the SDKs and platform dependencies to be installed locally on a development machine with massive RAM and a big hard drive felt so antiquated compared to the other apps I used which were light-weight and used the cloud in a meaningful way. This made me want to redefine what a development environment was. I wanted to build something that enabled developers to build across a variety of platforms, and now that cloud connectivity was ubiquitous for developers, it was possible.
I left Microsoft in pursuit of a company that would allow me to chase my crazy idea, and Telerik is just that crazy (talking to you Forte). I didn’t want to build just another IDE. I wanted to build something different; I wanted to build an ICE – an Integrated Cloud Environment. I believed that we could improve cross-platform development by decoupling the gestures of writing code from the platform dependencies required when building apps. Specifically I wanted to decouple coding from the big, bloated SDKs that limited the development experience to one where the coding environment and the target environment required affinity.
The primary objective in building an ICE was to enable developers to build apps that targeted any relevant platform from any development. My theory was that we could extract the SDKs from the local coding environment and turn them into cloud-based services that could still function as part of an integrated workflow for developing apps. In other words, it still had to be an integrated development experience, and the cloud – not your OS and RAM – would become the enabling technology. The experience had to be functional, capable and simple. The age of having to master multiple complex development environments and SDKs is coming to an end. The new ICE age will usher in a new type of development tools, and the dinosaur IDEs will die off soon enough.
Icenium™ is the realization of that vision. Icenium combines the convenience of a modern coding environment with the power and flexibility of the cloud to manage platform dependencies. Icenium enables you to build applications without being limited by the development environment having to be compatible with the run-time environment (e.g. Mac OS X to iOS). It enables you to focus on the content of your application without the headache of managing multiple SDKs and development environments. With Icenium you can use Windows, Mac OS X, Linux, or even device operating systems, like iOS on an iPad, to build hybrid applications that are distributable through the app stores, and run natively on iOS and Android devices.
We also tailored the development experience to web developers. Most web developers (me included) prefer to work with capable, text-based code editors (and not WYSIWYG tools that modify your code without your consent), a browser and some debugging tools, such as WebKit Inspector, so we designed Icenium to work the same way. The Icenium coding environment is a simple text-based code editor, packed with advanced capabilities including syntax coloring and formatting, real-time error detection, refactoring, code navigation, and more.
Each development client (Icenium Graphite for Windows and Icenium Mist in the browser) includes a device simulator that enables you to test your application much like you would test a web app in a browser. The device simulators include options for simulating iPhone, iPad, Android phone and Android tablet, including a geolocation simulator and the ability to rotate and flip the device. The device simulators expose the ability to use WebKit Inspector-based debugging tools – the tools you already know. We have tried to replicate the working style you already use for web apps, making the transition to mobile application development simple and intuitive.
Icenium Graphite is an installable development tool for Windows operating systems. It is a WPF app that provides you with the ability to build a cross-platform mobile application, test it in a device simulator, build the app (in the cloud of course) and deploy it to multiple devices at once. When you are ready, you can switch to a “release” build setting, add your icons and splash screens and package your app for publishing to the Apple AppStore or Google Play.
Icenium LiveSync is one of the truly magical features of Graphite. With LiveSync you can build and deploy your app to one or more iOS and Android devices with nothing more than the click of a button. Your app is built in the cloud, and then delivered back to Graphite where it is pushed over USB to all connected devices.
I usually have 10 or 11 connected at once, including iPhone 4S, iPhone 5, iPad 1, iPad 3, Google Nexus, Google Nexus 7, Galaxy S2 Skyrocket, Galaxy S3, Galaxy Tab 8.9”, Galaxy Note 10”, HTC One X, and the Kindle Fire.
Icenium Mist is the browser-based sister of Graphite. Mist provides nearly all of the same functionality as Graphite, and works on a variety of platforms. I use Mist on my MacBook Air, and even on my iPad, when I am away from my office. Mist also includes the modern conveniences of Graphite, such as syntax coloring, statement completion, and version control integration, as well as a browser-based device simulator that can render your app on an iPhone, iPad, Android phone and Android tablet.
Since Mist is browser-based, it doesn’t have access to deploy apps to devices via USB. Instead, you can build your app and deploy it to a device by downloading the app and pushing it to your devices manually, or simply scan the on-screen QR code and the app will be downloaded to your device.
Whether using Graphite or Mist, we’ve included the option to use LiveSync in an “on-demand” way. If your app is on a device and either you’ve disconnected it from USB (when using Graphite) or you deployed the app manually or with a QR code, you can request an app update easily and the content of the app will be refreshed based on your latest saved changes in either Graphite or Mist. If it’s an iOS device, simply press three fingers to the screen for a couple seconds and you will see the download begin. If it’s an Android device, simply press the context menu and the download will begin. LiveSync on demand means you can see your changes on any device, anytime, anywhere.
If you’re familiar with Apple’s iOS development model, you know that in order to deploy an app onto an iOS device you need to first provision that device through the Apple Developer Center. Icenium fully supports working with provisioned devices – in fact Icenium can aid you in creating the Certificate Signing Request required when requesting a device provision. However, if you want to try out your app without provisioning your phone, or you want a stakeholder or beta tester to try out your app and give you feedback, then Icenium Ion is the tool you need. Ion is a development and testing utility (downloadable for free from the AppStore) that enables you to load your app onto any iOS device regardless of whether or not it has been provisioned. Simply scan a QR code provided by Icenium and the app will download and launch inside Ion. Of course, LiveSync on demand works perfectly with Ion too.
Of course a development tool wouldn’t be complete without integrated version control, and a cloud-based tool better integrate with popular cloud-based version control systems, so we did just that. By default all Icenium projects are connected to an integrated Git repository in the cloud, and you can optionally configure your project to use any URL-based Git repository, including GitHub and BitBucket. Both public and private projects are supported, enabling you to collaborate and version your code safely.
Kick the Wheels (for a while)
As I mentioned, today we have released Icenium for everyone to use. In fact, I don’t want there to be any barrier in your way to trying out Icenium, so I decided to make it free for the next 6-months. We won’t begin charging anyone for Icenium until May 1, 2013. So go to Icenium.com, create an account and start building cross-platform mobile apps today. I’ll bet you can build an app faster than it takes to download xCode.
It’s been almost a year since I left my role at Microsoft as Director of Product Management for Visual Studio. Ever since I left, I’ve had lots of people asking what I am working on now, and I’ve been pretty quiet about it (the running joke is that I am the VP of Black Ops). The truth is that my team and I have been very busy solving what we believe to be one of the biggest challenges facing developers today and building a new product that I believe will dramatically reduce the barrier to entry for developers wanting to build applications that run natively on mobile devices.
I firmly believe that mobile devices are the single biggest opportunity today for developers. Cell phones are ubiquitous, and smartphones are becoming so common place, it’s surprising when someone doesn’t have one. According to the March 2012 U.S. Mobile Subscriber Market Share from comScore 234 million Americans age 13 and older used mobile devices, and more than 106 million people in the U.S. owned smartphones. That’s roughly one-third of the US population, and if you are anything like me, your smartphone is the only computing device you have with you at all times, from the time you wake up, to the time you go to bed. While a smartphone (or tablet) may not be your primary productivity device, it is arguably your primary device –the only one you always have within reach.
From a developer’s perspective, this represents a huge opportunity. While lots of developers have already entered the mobile device development arena, only a fraction of the entire developer population is actively doing development for mobile platforms. As businesses embrace mobile devices and start to extend their line-of-business applications, business-to-business applications and direct to consumer applications, more and more developers will have to transition into mobile platform developers.
While mobile platforms are one of the biggest opportunities for developers, they are also one of the biggest challenges for developers. Like the browser-wars of the 90’s, the mobile platform arena is hugely challenging. Every mobile platform provider has their own SDKs, uses a different programming language, and different tools. In fact, if you want to target all of the mobile platforms out there, you need multiple development machines—one for Mac OS X and one for Windows (at the very least you need a Mac and a BootCamp image of Windows). To build one app that runs natively on all platforms requires significant duplication of effort—essentially building and rebuilding the same app on different platforms. None of the platform providers are eager to solve this problem for you—they don’t make developer tools, they make platform development tools.
When I was at Microsoft, my job was to ensure Microsoft built the best platform development tools possible As a result we created awesome tools for development on the various Windows platforms (client, server and phone). What we didn’t do was build great developer tools—tools that made developing applications easier and more enjoyable regardless of what platform was being targeted. The only way to do that in the Developer Division would be to secede from Microsoft and become an independent software vendor (ISV)…and DevDiv would be a big one. Since that wasn’t going to happen I decided that it was time to find an ISV that had the ability to create great development tools regardless of platform. That quest led me to Telerik, where my team and I have been doing just that.
I’d like to invite you to join the Icenium private beta. Icenium is a work in progress (hence the private beta) and steadily becoming the product that I envisioned—a development tool that makes building applications easier and more enjoyable regardless of platform. With Icenium, we intent to build the worlds first Integrated Cloud Environment (ICE) that combines the power and flexibility of the cloud with the convenience of a local coding environment to massively eliminate the complexity of building cross-platform mobile applications. In its current beta state Icenium enables you to build applications for Apple iOS and Google Android, and more platforms will follow. My team and I are very excited about this beta, and we are looking forward to getting your feedback.
Just the other day a colleague and I were having an interesting discussion. After a while we realized we were talking about the same things but we each used different vocabulary to describe the things we were referring to. I hate when that happens.
I thought it would be useful to provide a common definition for the types of device (aka mobile) apps we see in the market to help establish a common vocabulary.
As I see it, device applications can be categorized as being either consumer applications or business applications (my colleague likes the term “corporate applications”). These are then also sub-divided, but I’ll get to that soon.
Consumer applications are exactly what the name implies – applications used by consumers. These are typically purchased through an app store or market place by the consumer directly. I tend to sub-divide these into five types: data snacking, social/mash-up, content/media, casual games and graphical games.
The key attribute here is that these are acquired directly by the user for a specific non-business purpose. Facebook, Angry Birds, etc. are examples of these types. There is some easy confusion here when we start to think about business (or “corporate”) applications, specifically those intended to connect the user to the business. Is Facebook a B2C app? Not really. It is the product of a company, but primarily a consumer app.
Business applications are built for only a couple reasons – B2C or internal line-of-business (LOB), and it can be easy to blur the line (or at least see the line with blurry vision) if you’re not careful. Some may argue that B2B is another type, but my position is that there is no such thing as a B2B device applications. They are B2C applications where the “C” is simply a user from a client “B”.
Business to Consumer (B2C) apps are the apps most easily confused with “direct” consumer apps. Is Facebook a consumer app or a B2C app? I think I could argue this one successfully in either direction, but I prefer to think of it as a consumer app (Facebook’s primary business is Facebook, even though their revenue comes from sources other than the user). For B2C I like to think about the company’s primary business. Is the app their primary business, or are they in the business of something else, and the app helps them provide a better experience for their customer?
Alaska Airlines is a company I do a lot of business with. They have a great B2C app. As the consumer, I got the app from the Apple AppStore, even though it’s not a consumer app (see, I told you it could get blurry). This app is a great example of a company that is primarily in a different business (moving people and stuff through the air),who has a great app for their customers. I can use the app to check my upcoming trips, check in for flights, and—for those of you who aspire to be truly paperless—even use it as my boarding pass.
My colleague likes to refer to these B2C apps as “Corporate Consumer Apps.”
Line-of-Business apps are built by companies (or vendors) for use within the confines of their business. Examples include expense tracking apps, conference room schedulers, and lunchroom debit apps (at Microsoft we even had a game app that the food services division put out enabling you to win a discount on lunch using your Windows Phone). Typically these are developed in house for a specific need, and distributed through some form of internal or enterprise app store.
These are what my colleague refers to as “Corporate Enterprise Apps.”
What Do You Think?
Do you agree with me? When thinking about the different app types for mobile devices, do we agree on the following terms: