Running and Debugging Your App
Visual Studio works with the Cordova command-line interface (CLI) to allow you to build an application for deployment to a native device. You configure the build process to target a specific platform such as Windows, iOS, or Android, and Visual Studio and the CLI create the appropriate app package for the device. You can then run your app on a device tethered to your machine, an emulator, or a simulator. We will look these scenarios next.
Visual Studio uses MSBuild to call out to the CLI through a layer called vs-mda. These tools then deliver the appropriate Cordova package (along with your app) that the native device can execute. When developing on a Windows machine, this works great for building Windows Phone/Store apps and apps for Android. However, iOS requires Xcode components that only work on a Mac. Visual Studio include the vs-mda-remote agent to get past this problem. You can set a Mac as a build server, target it from Visual Studio, execute the build, and then debug on the same device, a tethered device, or an emulator running on a Mac. Of course, you can develop the same Cordova apps directly on a Mac.
Note
For more details on the Cordova build process inside Visual Studio, see “How the Cordova Build Process Works in Visual Studio” on msdn.microsoft.com.
Selecting Your Target Run Environment
There are a large number of options in Visual Studio for deploying your device for debugging and verification. These many options mimic the variety of devices, sizes, versions, and types available on the market. You will want to run and debug your application on each platform you intend to support, the version of the operating system (OS) you intend to support, and the device type (phone, tablet, PC).
Figure 25.6 illustrates the run options for Cordova applications in Visual Studio. The Debug menu should be familiar; this is where you select what type of compilation you want to execute. Debug is used for debugging because it allows you to step through your code. Release allows you to run your code in a full release mode. Distribution creates the packages required to distribute your application to an app store.
FIGURE 25.6 Use the debug options to select a compilation, target platform, and target device/simulator when running your application in debug mode.
Notice the second menu option in Figure 25.6. This is where you pick your target platform. The options are Android, iOS, and the many configurations of Windows. The Windows options are there to support both Phone 8 and Phone 8.1 (universal apps) as well as Windows 10 universal apps. The other Windows options are there to support apps written for the Windows Store on the Win8 desktop or table (such as the Surface).
The third option in Figure 25.6 shows the options available for deployment and debugging your application based on your selected platform. In this instance, the platform selected is iOS. Notice the many Ripple simulators available. Ripple, like Cordova itself, is an open source project from Apache. It creates native device simulators that run in a browser for the many platforms and device types out there (more on Ripple in a moment). The other options in this list include Local Device and the simulators available for iOS. If targeting iOS, Visual Studio supports targeting the many Ripple simulators (currently through iPhone 5). However, if you want to use a local device or one of the many simulators available, you need to configure a Mac as a build server to work with Visual Studio. (See the following Note.)
Build and Debug for MAC
To configure a Mac as a build server and to run your simulators on the same machine or a tethered device, you use the Visual Studio Options dialog (Tools, Options). Under the section Tools for Apache Cordova, you will find Remote Agent Configuration. Here you set the Host, Port, and Security PIN properties to enable a remote configuration on a Mac.
You must also install and configure the vs-mda-remote agent on the same Mac and set your Security PIN. For a walk-through of this scenario, see the MSDN article, “Install Tools to Build for iOS.” This walk-through illustrates setting up the vs-mda-remote build on a Mac and connecting it to Visual Studio for the debug experience.
Selecting a different environment (Windows or Android) from the second drop-down in Figure 25.6 changes your options for emulators and devices. There are currently no Ripple simulators for Windows. However, Microsoft ships with multiple emulator environments for phones. You can also tether a device to your PC or even use the local machine (for Windows 8 store). Your Android options also include a tethered device, Ripple simulators, and the two new Android emulators created by Microsoft that ship with Visual Studio (one for phone, one for tablet).
Debugging with Apache Ripple
We will start by running the basic sample application created earlier in this chapter using Apache Ripple. We use the drop-downs shown in Figure 25.6 to select Debug, iOS, and Ripple iPhone 5. You then press the Play button (green arrow) or F5. This will build the application, deploy it to the Ripple simulator, and open it within a browser window. It also binds the Visual Studio debugger to the running application.
Figure 25.7 shows the application running in the Ripple iPhone 5 simulator. Notice the menu bar at the top right. Clicking this “hamburger” button drops down the menu options (because this uses Bootstrap). Also notice that here we have calculated a pace and saved it to the list.
The Ripple simulators use Chrome as the default browser. Figure 25.7 shows just the application. However, Ripple provides a number of options for simulating a user working with the device. These options are available in the actual browser window, as shown in Figure 25.8. The following highlights some of these many options:
Devices—Allows you to select a different device. You should stay with the device selected if running in debug mode. However, you can also run inside of Ripple without debugging (Ctrl+F5) in Visual Studio. In that scenario, you can easily flip devices and see how your application may look and behave on those devices.
You can also change the orientation of the screen from this section. This will show how your application behaves in Portrait and Landscape mode. Recall that you can choose if you intend to support both modes from the config.xml file in your project.
Information—Provides detailed information about the environment of the simulator including versions and screen size information. It also provides details on the actual native browser used in the web view (user agent).
Accelerometer—Allows you to mimic what happens when a user activates the device’s accelerometer by tilting, rotating, and shaking the device. You may expect certain behavior in different scenarios (such as a driving game).
Batter Status—Supports simulating what happens when the device is running low on battery. You may have code you expect to run in this scenario.
Settings, Device and Network Settings—Allow you to set various options for the simulated device.
Geo Location—Supports changing the user location on the device. This is helpful if you are using geo location in your application for various scenarios.
Config—Illustrates how your application configuration is seen by the device.
Events—Allows you to fire events on the device and then see the results. Events include Back button, Pause, Resume, Online/Offline, and more.
Remember that you can set breakpoints in Visual Studio and have them fired from the simulators, devices, and emulators. Figure 25.9 shows a breakpoint inside index.js for the onAdd() method. Notice that the Ripple application is running in the browser (background of the image). The Locals window (bottom left) allows you to interrogate variables. The JavaScript Console (bottom right) provides a log of JavaScript activities in your application.
FIGURE 25.9 You can debug Cordova applications with Visual Studio as they run in the various simulators, emulators, and devices.
Ripple should be used for testing applications quickly without going to an actual device or emulator. However, the next level of testing should be an emulator because it tends to be more precise. Of course, you should test all applications using an actual device before deploying for user consumption. Let’s look at these options next.
Emulators
Visual Studio provides emulators running in Windows for Windows Phone 8/8.1 and Android (phone and tablet). There are emulators for iOS, too, but they run on a Mac. (See prior note on building for the Mac.) You need to run Visual Studio with elevated privileges to use these emulators. (Right-click the Visual Studio shortcut and choose Run as Administrator.) You also must have a desktop processor capable of running HyperV emulations. Finally, you should have sufficient memory (4GB+) and available disk space (2GB+).
Older processors do not always support the emulators. If you are getting errors when trying to run an emulator, it is likely that your processor does not support the technology required to run the emulator or your BIOS has not enable this feature. There is guidance online for checking your processor’s support for running emulation.
You select an emulator using the drop-downs, as shown in Figure 25.6. Visual Studio launches the selected emulator at debug time. It then packages your application and deploys it to the emulator. Figure 25.10 shows the sample application running in a Windows Phone 8.1 emulator, with the Additional Tools window open.
FIGURE 25.10 The Windows Phone 8.1 emulator works to closely mimic user interaction with an actual device.
You can work with the emulator as you would an actual device. This means the buttons and other applications all work as if it were an actual device. Notice that in Figure 25.10 the keyboard shows when the user navigates to a text box (as it would in an actual device). The thin vertical toolbar in the emulator (middle of Figure 25.10) allows you to simulate touch (hand icon), rotate the view (circle arrows), zoom (magnifying glass), and open the Additional Tools menu (double arrows icon).
The Additional Tools work in a similar fashion to the extra tools in Ripple (see prior section). You can use the Accelerometer tab, for instance, to simulate moving the device side to side or shaking it. The Location tab allows you to set geo location. The Screenshot tab supports taking a screenshot of your device (useful when debugging). The other tabs inside the Additional Tools window provide even more options for working with the emulated device.
Local Device
Visual Studio supports debugging against actual devices. You can do so using tethering (with a USB connection). You can also communicate with the device remotely (over a network). You select the device option from the same options you saw back in Figure 25.6. Figure 25.11 shows the application being debugged on an actual Windows Phone. Note that you can do the same for Windows tablets, Android devices, and iOS devices.
Visual Studio also supports running your application as a Windows Store app (see Chapter 23, “Developing Windows Store Applications”) that runs directly on your machine, a remote machine, or a simulation of your current machine. You again use the drop-downs shown in Figure 25.6 to configure this scenario. Figure 25.12 shows the app running as a store app in the Windows-x64 simulator. The toolbar on the right allows you to work with the device for capturing screenshots, simulating touch, and more. Also, notice that Bootstrap spreads out the menu when using a wider screen.
FIGURE 25.12 Visual Studio supports debugging your Cordova applications as Windows Store applications.
Tip
Remember, Cordova apps work like web pages running inside a native container using the device’s web view. Like debugging web pages, it can often be useful to access the browser tools (F12 in IE) for inspecting the DOM and related styles. This is hard to do on a device. Thankfully, Visual Studio includes the DOM Explorer window to help. You access this window from Debug, Windows, DOM Explorer. (It also works for websites.) Figure 25.13 shows an example. Notice here that the Bootstrap background-color and color styles for the <body> tag are being overridden by index.css.
Next Steps
So far we have looked at building, running, and debugging a basic Cordova application using standard web technologies. This works great and is an option for building your application. However, there are some issues with apps like this. They tend to feel to the user more like a webpage and less like a native application. For example, when you click a new page in the sample app, the screen reloads and thus flickers like navigating to a new web page. Also, the application is currently not storing any data locally (or on a server). There are no icons or splash screens. The application does not take advantage of native device features. Thankfully, we can solve a lot of these issues with Cordova. We will look at using Angular and Ionic along with Cordova plug-ins for help.