Skip navigation

RhoMobile Blogs

9 Posts authored by: Edward Correia

Why go open source?

To enable the platform to grow as a whole and not be limited by what just Zebra can provide.

RhoMobile is only one part of a set of tools and utilities that developers can use to build enterprise grade devices. We provide multiple options so developers/customers can choose what best fits their skill set and solution requirements:

  • RhoMobile for cross-platform using web skills
  • EB for web-based applications
  • EMDK for Android, for native apps
  • EMDK for Xamarin, for cross platform apps for developers who have .NET skill set

RhoMobile supports both Zebra enterprise devices and consumer devices.  We recognize that there is wider interest in RhoMobile beyond Zebra devices, as many customers use the platform for consumer OS devices.


Please visit the RMS Open Source Forum.


What are the benefits of going open source?

By taking RhoMobile open source, we believe our customers and partners can better recognize the benefits open

source brings:

  • Innovation Acceleration: Companies and individuals can move faster, build more quickly; customers & partners can gain control of their IT investment; and all parties can benefit from each other’s enhancements, new ideas and challenges to the status quo.
  • Better Software: When work is visible to the world, culturally developers tend to build better code – architecting their open-source code to be extensible, have minimal dependencies, and stable APIs.
  • Community Learning: Encourages adoption for both Zebra & non-Zebra devices – advancing the platform as an industry platform, not just a Zebra platform.
  • Share Challenges: During an era of scale, complexity, and ever-evolving operating systems, open source allows for collaborative creation of scalable solutions to new problems – making projects evolve faster.
  • Control: Provides control to customers and partners using the platform – opening up the option to add new features, new OS support and more, specific to their solutions.


What are the migration options?

There are three migration options: 

  • Stay on Zebra releases. For customers who are satisfied with their current version/solution, Zebra will continue to sell and support existing versions of RhoMobile Suite (2.x through 5.4). There is no need to move to open source.
  • Migrate to Enterprise Browser. If you are using older versions of RhoElements for a web-based application, you may continue to do so, or you have the option to migrate to Enterprise Browser if new features or new device support is required and is covered by Enterprise Browser.
  • Migrate to RhoMobile Open Source. If your solution(s) require new platform enhancements, new OS support (such as iOS 10, or Android M) or new device support you will be able to migrate to the open-source platform – based on your own timing/need. Customers desiring assistance on the open-source platform can work with the open-source community as well as our partners, Tau Technologies and Kutir, who are committed to offering support options.


Which components of the current RhoMobile Suite will not be open-sourced?

  • Hosted cloud builds will remain available to customers with subscriptions up to version 5.4. Customers using open source will be responsible for their own build environments or will be able to take advantage of environments if offered by other partners.
  • Support for the Windows M/CE platform webkit is a third-party proprietary component that cannot be open sourced. Customers with solutions that use/need Zebra WinM/CE devices can remain on their current version of RhoMobile up to version 5.4.
  • The WM/CE framework APIs will be open sourced without the webkit – allowing the community to provide their own webkit replacement or work with a partner such as Tau Technologies who is working on a webkit option.
  • The RhoElements RFID plug-in for Windows Mobile/CE will not be available as open source.
  • Open Source components of the current RhoMobile Suite include:
  • Rhodes
  • RhoStudio
  • RhoElements
  • RhoConnect (client & server)

Enterprise Browser and AppGallery use RhoMobile – will they be open sourced?

No. Although built on the RhoMobile framework, both are considered separate products and will not be transitioned to open source. They will remain separate offerings as they are today.


Where can I find the source code?

The open sourced version of RhoMobile can be found on GitHub:


What resources will still exist on Launchpad?

The resources on the RhoMobile space in Launchpad will refer to the RhoMobile 2.x - 5.4 versions of RhoMobile Suite. If you are using these versions, then these resources apply to you. If you are using the open source version, you should consult the readme documentation in the open source repo.


Will the pricing structure change?

Prices for existing closed-source versions will not change. Versions 2.x, 4.x and 5.x will continue to be sold and supported. The open-source release will be free to the public to use and provide contributions. Customers desiring support on the open source line will be able to purchase support from our partners, Tau Technologies and Kutir.


Will my existing Silver or Gold subscription change?

Silver and Gold subscriptions used with version 5.x will continue to receive support. If you want to move to the open-source line, you may work with the community for free, or purchase support from support partners.


What happens if I am using RhoMobile v4.x or v2.x?

There are no changes to RhoMobile v4.x and v2.x – they will not be open-sourced. You  may continue to purchase support and licenses for your solution on these versions.


How will I get bugs fixed?

If you remain on your current version (v2.x, v4.x or v5.x) and have a current support contract, you will follow standard procedures and submit bugs to the ZenDesk Support Portal. If you move to the open-source code line, you will have the ability to hire support from other vendors also using/supporting the open-source software, or, address the bug and submit the fix back to the community.


Isn’t RhoMobile already open source?

Only Rhodes and RhoStudio are currently open source. With this move, we will be open-sourcing all enterprise grade capabilities including RhoElements enterprise API’s and our enterprise grade data synchronization engine RhoConnect and RhoConnect Client.


Will RhoMobile be included in the Gartner MADP Quadrant in 2016? 

No. Once RhoMobile is open source, we will no longer have a commercial offering on the open source release and will not qualify for the quadrant.


How do I engage with partners if there is a customer requirement for RhoMobile?

RhoMobile partners, Tau Technologies and Kutir, have committed to offering support options for the open-source platform.

Dear RhoMobile Users:


To encourage and expand opportunities for innovation, Zebra is committed to building a thriving developer community that enhances RhoMobile beyond what Zebra can do alone. To accomplish this, we will be making RhoMobile Suite an open-source software in Q2 2016.


Zebra will continue to sell and support existing versions of RhoMobile Suite (2.x through 5.4). If you are satisfied with your current version, there will be no need to move to open source.  If you are developing a solution that requires new platform enhancements, new OS support (such as iOS 10 or Android M) or new device support, you will be able to make the move to the open-source platform at your own pace.


The following portions of RhoMobile Suite will NOT be open-sourced:

  • Hosted Cloud Builds: Will remain available to customers with subscriptions up to version 5.4. Open source users will be responsible for their own build environments or will be able to take advantage of environments offered by other partners.
  • Windows M/CE Platform Webkit Support: Being a third-party proprietary component, this cannot be open-sourced. Customers with solutions that use/need Zebra WinM/CE devices can remain on their current version of RhoMobile up to version 5.4.
  • WM/CE framework APIs will be open sourced without the webkit – allowing the community to provide their own webkit replacement or work with a partner such as Tau Technologies, who is working on a webkit option.


For more information on how the transition to open-source will affect your subscription to RhoMobile Suite, please see the attached RhoMobile Suite FAQ. If you are in need of assistance on the open source line, our partners Tau Technologies ( and Kutir ( will be providing support options.


For more info, read the RhoMobile Open-Source FAQ.

Time is running out to get the best price on AppForum, this year's must-attend conference for Zebra partners and developers. It's happening Sept. 21-23 at the Hard Rock Hotel and Casino in Las Vegas, and will feature a keynote from Zach Shelby, co-founder and former CEO/CTO of Sensinode, which ARM acquired in Aug., 2013, to accelerate its IoT strategy. Shelby was recipient of the Nokia Foundation's 2014 award for his pioneering work in developing networks of low-power IP devices and sensors.

Zach Shelby, dir. of technical marketing at ARM, and Tom Bianculli, VP of Zebra's Enterprise Technology Office.

Following Shelby's keynote will be Tom Bianculli, vice president of Zebra's Enterprise Technology Office, and is responsible for exploring new opportunities, development initiatives and strategies. Bianculli himself holds more than 20 U.S. patents, and is a Zebra Distinguished Innovator and Science Advisory Board Associate.

This year's conference also delivers more than 50 talks and hands-on workshops to guide and instruct developers through today's most relevant topics, including two sessions on the Zatar IoT and MSM development infrastructure, more than 30 sessions on Android development, five on the use of Zebra's RhoMobile cross-platform IDE, seven on printing, plus lightning talks covering strategies for targeting healthcare, retail, manufacturing and transportation and logistics vertical markets.


Of particular interest might be sessions on technologies new to the Zebra portfolio, including All-Touch Terminal Emulation, which can enliven older TE apps with a touch overlay; new cordless scanner SDKs; iFactr, a virtualization toolset for running Windows Mobile/CE apps unchanged on Android devices; how to use Xamarin to build new or migrate existing .NET and C# apps to Android; and enterprise use cases for smart glasses, Enterprise Browser and Zebra's emerging tablet strategy.

In case that weren't enough, there's also a Hackathon, which developers can dive into immediately after they register. Developers can work individually or in teams to build a vertically-targeted mobile app using tools and operating system of their choosing. Extra points will be awarded for using Zebra's tools and locationing technologies. The first 100 registrants will receive two Zebra MPack locationing  beacons, and the grand prize will be something truly special.

Hurry. You have until Monday, Aug. 31, to register for
just $99 and lock in a room rate of $84 per night in Las Vegas. And you might even win your very own drone.  Find out more at, or send questions directly to And if you can't make to Las Vegas, you might consider AppForum London, Oct. 12-14 or AppForum Hong Kong, Nov. 16-18.

If you were tasked with designing a car, the first few requirements would obviously be that it start, that it go where the driver intends, and that it stop safely when it arrives. Your initial interfaces might include gas and brake pedals, a steering wheel and perhaps a shifter to control direction. Testers of your new device would immediately complain that it's difficult to drive while standing up. You add a seat. Notice a pattern?


Dilbert cartoons copyright: United Feature Syndicate Inc.

The more something is tested, the greater the revelations of what's required. The same applies to application design. It is therefore critical to involve testers, users and other stakeholders early in development, when it's easy to make changes. This should generally begin with the requirements phase.

Here's a look at some best practices for determining what's required of your application, and some requirements that should be on your list every time. 


The decision to create an app generally stems from a business need. For Zebra customers, that typically involves reading barcodes or RFID tags to register sales, manage inventory, or to track packages, pallets or patients.


Behind all apps are the Product Goals, which might include:


  • Collecting, storing and forwarding data
  • Actions or processing the data
  • Physical output such as an invoice or receipt
  • Additional actions by the user or customer such as swiping a card
  • Information displayed to the user or customer as on a kiosk

User Needs are equally important to the analysis, and the need of the app's intended users should be gathered during the pre-prototype stage. Aside from user-stated requirements, your apps always should include the following attributes:

  • Easily discoverable features and functions
  • An intuitive, efficient workflow that's easy to learn
  • Simple, non-destructive recovery from erroneous actions
  • Interruption handling; recoverability from long pauses in activity
  • Enjoyable, satisfying user experience that includes visual feedback

To build your app with easily discoverable features, present only the functionality that's required to reach the goal. Avoid splash screens that must be manually dismissed, and present all app functions using a single page design, but only if it's possible to do so without clutter. Refer to Touch Target Best Practices for guidance on the presentation layer.



These screens are part of Zebra's tutorial for building a simple inventory app.

An efficient workflow presents the minimum number of steps to get things done, particularly for the app's primary functions. That's one of the keys to a helping you build a satisfying user experience that's easy to remember and that enables workers quickly gain proficiency. Conversely, deleting records and other destructive or irreversible tasks should require at least two steps to complete and be located away from the app's main functions. This helps ensure that erroneous actions don't end in data loss.

Among the most overlooked attributes of an app is how it will respond after long periods of inactivity. If the user is unexpectedly called away from inventory tasks to help out at the register, for example, will your app timeout and cause records to be lost? It's important to design your app to recover gracefully from interruptions in workflow, which are inevitable in most line-of-business usage scenarios.

People should feel confident while using your software and never wonder whether a task has been left undone. Build screens that provide feedback on all activities. This gives the user a sense that the're in complete control of whatever they're doing. If multiple screens are necessary, all screen interfaces should work in basically the same way, and each should have a "Back" button.





With requirements close at hand, develop a prototype of your app that blocks out its basic workflow and present it to all stakeholders as soon as possible after the requirements meeting. The mock-up screens don't have to contain any underlying logic, but should be detailed enough to facilitate a discussion of the application's basic functions and flows. Incorporate suggested changes into the next version of your prototype and present them to the team once more.

Once you've gotten stakeholder buy-in, you can begin building your app putting logic behind the screens. Convene the team at each major milestone to demonstrate that development is on track and confirm that requirements have not changed.



Dilbert cartoons copyright: United Feature Syndicate Inc.

Business and competitive pressures often can lead to changes in features or requirements of an app while it's still in development. Major features or minor, at some point the decision must be made to freeze an application's feature set and implement those changes in a future version. This decision usually varies by project and by company.

One way to fight feature creep is to adopt an MVP philosophy, that is to focus on creating a minimal viable product. Rather than trying to build an app that is all things to all users, narrow the focus to include the business goals and nothing more. Concentrate on doing one or two things extremely well, and leave the rest for an update or another project altogether.


SmarterPlanet: Oft-overlooked requirements

OpenRoad: Mobile-UI Design Best Practices
TechTarget: Defining Requirements
Appmethod Blog: Top 5 Best Practices for Mobile UI Design
Dilbert cartoons copyright: United Feature Syndicate Inc. 

To err is human; to program, devine. Doing both can result issues ranging from user frustration to total app failure. Nobody wants either, of course, and a few simple app-design concepts will help keep your apps easy to use and hard to break.

This first-in-a-series installment on mobile UI best practices covers Touch Targets, the places that put functions at the fingertips.

Touch Targets

Human pointers have far less precision than mouse pointers. It's therefore important when designing your app's buttons and other touch targets that you optimize them for the imprecision of the human finger. Here are a few best practices.

In general, buttons should be large enough to remain visible and provide feedback when touched by a finger or thumb. This important visual cue lets the user know that their choice has been registered and that something is about to happen. Also, the button's appearance should remain "pressed" if the app doesn't immediately dismiss the current screen. This will help prevent subsequent presses of a button that the user thinks wasn't pressed the first time.


The ideal size for human-interactive buttons was included in research published in 2003 by the Touch Lab at MIT, which sought to understand the mechanics of tactile sense. It reported an average human index finger at 16 to 20 mm (about three-quarters of an inch) wide, and an average thumb at 25mm (about one inch). Of course to calculate button size, those length measurements must be converted to pixels using the target screen's pixels-per-inch (ppi) specification. Use this pixel calculator to determine the number. 

Interestingly, Apple's Human Interface Guidelines for iPhone currently recommend that touch targets be at least 44 pixels square; Nokia recommends an even smaller 28 pixels square and parent Microsoft advises 34 pixels x 26 pixels. While such dimensions might have suited a 640x480 screen, today's resolutions can make even Apple's suggestions look like a postage stamp on the other side of the room. So it's best to use absolute measurements and convert using the ppi of the target device. It's also good practice to place touch points away from the edge of the screen, where they can sometimes be hard to tap cleanly because of a protective case or cradle. The minimum size for a reliable touch target is 6mm square for stationary users; 8mm for users in motion.




Also important are variances in tap method. Sometimes people tap with the tip of the finger, other times with the pad of the thumb. What you might not have known is that touchscreens register touch input in the center of the contact area, a point known as the centroid. Depending on the platform, information such as touch size and pressure also are captured, but the centroid is the point of action.



From the illustration above, the thumb's "contact patch" appears to be touching both Nearby and Events buttons. But Nearby will be selected because its centroid falls within its boundaries. It's important to note that the so-called hot section should not be limited to a button's text. The clickable area should include button text and the area of its enclosing geometry, which in this case is a rectangle. To further reduce incorrect presses, known as interference, create an invisible 3mm gap between buttons by shrinking the clickable area at the top and bottom of adjacent buttons by 1.5mm. Conversely, if a screen object is too small to be a suitable touch target, increase the size of the clickable area surrounding it and make it transparent (and therefore invisible).

To minimize interference errors, touch targets should be separated by 8-10mm on center. If only a few buttons are needed, making them oversized can minimize errors and direct attention to the most common action. But be careful not to go overboard. Developers of the alarm clock app below clearly thought that most users would choose to snooze, and perhaps further believed that groggy fingers were better served by a larger landing area. Perhaps they're right, but experts say that touch targets should never exceed 15mm. Anything larger starts to look like a background element.


The UI design is ultimately up to you, and should be built according to the needs of its users. The Zebra Utilities app shown below offers six main functions, each on a dedicated button with plenty of separation between them. This app is easy to operate with finger or thumb. 



For an app that presents a scrolling list of selection objects, a stack of buttons or sets of functionality presented in tabbed screens, it's important to build it with minimization of interference in mind. Remember that design elements such as tab bars can be as slender as you like visually, and their touch targets can exceed those geometric borders. The figure below shows a pair of apps with an overlay of 8mm and 10mm concentric circles depicting the spacing for minimum and optimal interference reduction. The overlay can be achieved programmatically on the actual screen or by placing it over a screenshot. In the app at left, notice that the tabs overlap touch targets above and below.


Regardless of how carefully the UI is designed, it's normal to expect an errant selection now and then. It is therefore important to build your app so that it minimizes the severity of those wrong taps.One critical best practice is to avoid placing trivial functions near non-trivial ones. Non-trivial functions might include logging off, sending or deleting objects or other actions that are hard or impossible to undo. Such functions should be placed in a menu or at the very least require multiple taps to complete.

No app is perfect, just like no developer is perfect. By using some best practices for UI design, you can help minimize the errors that users will make when using your app. Here's a recap:

  • Buttons should be large enough to remain visible and provide feedback when touched by a finger or thumb
  • Appearance of a pressed button should remain "pressed" if the app doesn't immediately dismiss the screen
  • Use absolute measurements for button sizes and convert to ppi for the target device
  • The minimum size for a reliable touch target is 6mm square for stationary users; 8mm for users in motion
  • Touchscreens register touch in the centroid, the center of the contact area
  • Touch targets should be separated by 8-10mm on center
  • Clickable area should include button text and the area of its enclosing geometry
  • If a screen object is too small to be a suitable touch target, increase the size of the clickable surrounding area
  • Touch targets should not exceed 15mm under normal circumstances
  • Avoid placing trivial functions near non-trivial ones






The release of RhoMobile Suite 5.1 last month has generated a good deal of media buzz. In late June it was one of Network World's New Products of the Week, and outlets as diverse as AD Trends, Beta News, Mobile Advertising Watch and Software Mag have helped spread the word about the new APIs and device support in 5.1. The reporting also touted Live Update, RhoMobile's ability to see the results of code changes in real time. Some also covered one of its most-demanded features--the ability to print via USB. Android apps made with RMS 5.1 now have a non-wireless means to output to Zebra printers that support USB printing, a list that's growing all the time. If you're interested in USB printing, be sure to check the RhoMobile Printing Guide for details and restrictions.

Zebra ZD500R printer.jpg

Zebra's ZD500R printer, one of the latest to support USB printing from Android apps.

Taking a deeper dive into the trend of mobile-device usage in bricks-and-mortar retail stores was CIO Magazine, which included a quote from RhoMobile product manager Alison Clark as it described "9 ways mobile and social tech improves the retail shopping experience."

Also of interest, Zebra's ever-prolific senior director of enterprise software Mark Kerstein penned a pair of pieces recently worthy of your attention. In "Fast, Cheap and More Controllable," Kerstein methods for building enterprise apps more quickly, for less cost and with better performance and control over data assets. And in a piece published this month in SD Times, Kerstein points to Android's roots in consumer devices to explain "Why Android is Poised for Industrial Mobility," and provides some best practices as action items.

Among the most useful and requested new features in RhoMobile Suite 5.1 is Live Update, which automatically bundles, deploys and displays changes to most types of program code on the target devices without the need to recompile.

Live Update can be a real time-saver for fine-tuning apps, particularly if they're on different platforms. It works with HTML, JavaScript, CSS, Ruby, images and other resource files in the /app and /public folders only. It uses Wi-Fi to connect the development host to multiple target devices running any combination of Android, iOS (and Apple's iOS simulator) or Windows Mobile/CE. But setting it up can be a bit tricky, so we've documented some of the common pitfalls here.

NOTE: This post relates to Live Update on Mac OS X, which is currently the only released and supported version. As of this writing, Live Update on RMS 5.1 for Windows was still in beta. 

To create a new project for Live Update (or modify an existing one), its build.yml file must include "development" in its "extensions" line, and "debug" in the "build" line (as below). The extensions line accepts a comma-separated list, but the formatting can vary from one RMS version to another. For compatibility with all versions, use the syntax below for your extensions line (boxed in red). Also see the syntax for the build line (also boxed in red).


01_Adding extensions to build.yml.png

Configure Networking

After you build, deploy and launch your modified app, you'll need to discover your device(s). Target device(s) must be on the same Wi-Fi subnet as your development host. If they're not, change the IP address of the development host so that the first three figures of the IP address match those of the devices, and the fourth does not. This might require a call to your IT department. The screenshot below shows the Network Preferences panel of Mac OS X after clicking Wi-Fi and the Advanced… button and selecting the TCP/IP tab. In the case, the machine's subnet is "10.186.6" and it's using DHCP. Clicking on the drop-down indicated by the arrow will permit "Using DHCP with manual address," which allows a user-assigned IP subnet to match that of the device(s).  

02_Mac Networking Wi-Fi prefs.png

Discover Devices

  1. In RhoStudio Project Explorer, right-click on the "Live update setting" document for your app
  2. From the menu, select "Open With…Live update setting"
  3. In the top portion of the window that appears at right, double-click the subnet that contains your device(s)
  4. A list of devices that are running your Live Update-enabled app will appear in the lower portion
  5. Select the device(s) to be updated and click the "Enable live update" button above the top portion of the window
  6. R-click your project name and select "Refresh." A new file called "dev-config.yml" will appear in the project.
  7. Right-click dev-config.yml and select Open With Text editor. Then move on to the next section.



Edit "dev-config.yml" File

Each discovered device will have a section in the dev-config.yml like the one shown below. If you don't see this file, right-click your project and select Refresh. Modify the dev-config.yml file for Live Update:

  1. Add an indented line stating "enabled: true" for each device to be updated
  2. After all devices have been enabled, add a non-indented line stating "refresh: 1" to enable the Live Update feature for this app
  3. Save all changes and build, deploy and run your app on the device(s)


Once your build deploys and runs, you should be able to instantly see any changes you make to settings within your app's /app and /public folders, including modifications to HTML, JavaScript, CSS, Ruby and other files on they're saved. Files can be edited directly using the RhoStudio text editor or any other tool you choose.

For more information about additional Live Update features and options, please refer to the Live Update Guide <>. Live Update was introduced in RhoMobile Suite 5.1, and does not work in prior versions. To upgrade your system, download the latest version <> and follow the upgrade instructions <>.

We're happy to report the release of RhoMobile Suite 5.1, which delivers something for Zebra developers of all stripes. Topping the list is Live Update, which can be set to monitor changes in source code and instantly implement and display those changes on a device in real time. Live Update on Mac OS X development hosts is supported for development across Android, iOS and Windows Mobile/CE platforms and connects via Wi-Fi from the development host to the target device(s). For Windows development hosts, Live Update is in beta. 

Android developers will be happy to know that their apps will now be able to print via USB to supported Zebra printers. This change affects Android apps only, and requires an OTG cable or adapter. Android, iOS and WM/CE apps can still print over Wi-Fi and Bluetooth, as before.

Windows Phone 8 developers also have reason to cheer; RMS 5.1 now supports the Barcode API for WP8, letting those app capture barcode data using the device camera or the 1D or 2D scanning component found on many Zebra Technologies devices. This release also now implements a Timer API and extends support of Config for Android, iOS and WP8.

There's also new device support. RMS 5.1 now can target Zebra's Workabout Pro 4 running Windows CE 6.0, The TC70 running Android KitKat, and the MC18 running Windows Embedded. Also new is common camera API support for JavaScript and Ruby, and Device API support for Symbol devices, which delivers the ability to calibrate, idle, power-off, suspend, re-boot and wake. We've deprecated a few devices too. Please see the RMS 5.1 Release Notes for full lists of supported and deprecated devices in this release.

Read the 5.1 release notes (includes notes from prior service packs)

Download the Windows binaries

Download the Mac OS X binaries

The RhoMobile 5.x environment provides some great debugging tools, but it's not the only way to fix or fine-tune your WebView apps. For devices running KitKat or higher, Google Remote Debugging offers a slick way to use Chrome to perform live, on-device debugging of RhoMobile apps right from your Mac or Windows development machine.



The tool can debug native Android apps that use WebView, such as those built with RhoMobile, and browser-based apps too. It employs live screencasting from the remote unit to the development host, and through port forwarding and virtual host mapping, also lets the device access a development server, if needed. And it's super-easy to set up in just a few quick steps.

System Requirements

The requirements for Google Remote Debugging are fairly minimal. The Mac OS X or Windows development machine just needs to have Chrome 32 or later installed plus a USB cable and available USB port. The device must be running Android 4.4 (Kit Kat) or later and the app must have WebView configured for debugging.

1. Enable Device Debugging

The device itself has to have USB debugging enabled, a feature found within the Developer Options settings panel but which is hidden by default. If you haven't already done so, unhide Developer Options by going to Settings>>About Phone>> and scroll all the way to the bottom and tap the "Build Number" box seven times. Then go to Settings>>Developer Options and enable USB Debugging.

2. Discover Device (in Desktop Chrome)

Next is to enable device detection in Chrome and point it to your device. Open a browser window and enter "chrome://inspect" in the URL bar (or go to Chrome Menu>>More Tools>>Inspect Devices). You should see a screen similar the following:


Check the "Discover USB Devices checkbox. If your mobile device is attached to the system via USB, it should appear along with an alerton the device. Tap OK on the device to complete the connection.

3. Install USB Driver (Windows only)

Linux or Mac developers can skip to step 4. For Windows systems, an extra driver is required to make a USB-attached Android device visible. Visit Google's OEM USB Driver page for instructions and driver links.

4. Configure WebView

WebView debugging has to be enabled from within the app. Fortunately, RhoMobile developers can skip this step because the WebView components used by the RhoMobile Suite are configured for debugging automatically then deployed to devices with debug mode enabled.

5. Begin Debugging!

Once your app is deployed and running on the device, the chrome://inspect page should look something like the one shown below, with your device and a link to its debug-enabled WebViews. To begin debugging, click an inspect link.


Clicking the Inspect link will launch Chrome DevTools, showing your app's code and its real-time rendering and your device (and on your screen if using screencast, shown).


For more details, visit the Google Remote Debugging page.


A capable alternative to Google Remote Debugging is Weinre, an Apache-hosted project that offers many similar features, including remote debugging of a live app on the device, and the ability inspect callback objects and API syntax.

Filter Blog

By date:
By tag: