In an ideal world, every mobile app developer would be able to build an app and test its behavior on a simulator that would perfectly mimic the way the software should behave on a mobile device. To a large extent, products such as Telerik’s AppBuilder have perfected the mobile device simulator, giving the developer a reasonable idea of how an app will behave on a variety of screen sizes, orientations, and how it will look in terms of color and design. In AppBuilder, you have several options if you want to get an idea of what your app will look like on a device. However, each of these techniques has pros and cons and become useful during different phases of your project. Below I’ll describe each of these techniques and show how they are used in AppBuilder.
Down the rabbit hole
If you are working in the in-browser Platform at platform.telerik.com, you can click ‘run’ to view your app on an iPhone, Android device, Windows phone, or various tablets:
Within the simulator, you have a variety of device types for each mobile OS to choose between:
…and the developer can get a reasonable idea of the app’s appearance and behavior by switching between device types on this list:
Similarly, if the developer is working via the command-line in the AppBuilder CLI environment, simulators can be easily accessed by typing:
$ appbuilder simulate
Similar to the in-browser experience, several different device types are available for testing, although you won’t have access to the fancy device-specific chrome that the in-browser toolset offers:
The visual difference between simulators within the Telerik Platform’s in-browser environment and via the terminal using the CLI underlines what is going on behind the scenes. Inspecting the source shows that, in the browser, the device chrome is simply a bit of css styling around an iframe. Since the simulators are built using the Chromium Embedded Framework, Chrome developer tools are natively available to you, so you can use those tools to debug network calls, check for errors in the console, inspect CSS classes, and inspect and manage storage options such as indexedDB, application cache, and local storage. You can also test most of the core plugins available by default in AppBuilder such as splash screens and geolocation – just remember that the plugin implementation is mocked, and the simulator doesn’t actually detect your location.
Using these tools enables quick, efficient debugging. Leveraging the simulator within a browser in the early stages of your development process is a good option. At some point in your development cycle, however, you’re going to want a more accurate representation of how your app will actually behave in the hands of a user. To get a better idea of your app’s relationship to a given platform’s hardware capabilities, you’re going to want to use a native emulator.
“Alas! either the locks were too large, or the key was too small”
A note about terminology:
The terms ‘Emulator’ and ‘Simulator’ are sometimes used interchangeably. It doesn’t help that Apple considers its native emulator a ‘simulator’ whereas Android tools are called emulators. For the sake of clarity, I will call the type of browser-based debugging tool that you run in-browser on Telerik’s Platform or via the CLI a ‘simulator’ and the tool that depends on Xcode or Android debugging tools an ’emulator’.
As Alice discovered, having the right key is essential to unlocking the right door. To get a better view of how your app will really look on an iPhone, Android or Windows Phone of your choice, you will want to view it using one of the emulators associated with a platform’s native software. In the case of Apple, you need Xcode, and for Android emulation, you need the Android SDK. For Windows, you can use the native Windows Phone emulator available in the Windows Phone SDK.
Type in the terminal:
$ appbuilder emulate ios
$ appbuilder emulate android
$ appbuilder emulate wp8
AppBuilder will build your app in the cloud and deliver it to your local native emulator. You might notice some differences between the browser-based simulation and this native emulation even in a simple screen:
With native emulation, you move a step forward in your quest to experience your app as your end-user will experience it. The biggest ‘win’ here is that using a native emulator allows you to debug plugins that you might have installed from Telerik’s Verified Plugins Marketplace. Thus you can test things like ad placement and native spinners on your desktop, without yet needing to deploy to device.
The native emulators allow more sophisticated debugging of the user experience by making available much of the device’s ecosystem. More information is available regarding iOS, Android and Windows device emulators on the Telerik Developer Network.
“‘I wish I hadn’t cried so much!’ said Alice, as she swam about, trying to find her way out.”
Although most use cases might be testable and debuggable using either the simulators or emulators, sooner or later you are going to need to get your app onto a device. Say, for example, when you need to distribute your app to external testers to make sure everything works properly. Don’t cry! It’s not that hard to do.
The easiest way to get your app to a device is via the AppBuilder Companion App, which you can download here. The Companion App is a wrapper on your device within which your app will be displayed. You build for the Companion App using the in-browser environment or the CLI and use the resultant QR code to install the app within the Companion App. Subsequent builds are refreshed on the device by holding three fingers on the screen. Using this procedure, device testing is significantly accelerated. It also offers a great way to pass builds to other people to test, such as a client or manager, without worrying about provisioning.
Alas, an important limitation of this process is that we still are not able to test custom plugins in the AppBuilder Companion App. We also aren’t able to test our splash screens, configurations, icons, and other important details that make your app a full-fledged product. To truly test your app, you’re going to want to build it for a device and deploy it to your phone(s) to ensure that it works properly.
“It was all very well to say ‘Drink me,’ but the wise little Alice was not going to do THAT in a hurry.”
Sooner or later, you’re going to have to bite the bullet and build your app for a device. It’s really the only way to fully ensure that everything works as designed, and to really do this properly, you should build for several devices. Building can be done via any AppBuilder client; a file will be produced for installation on your local device (an .ipa file for iOS and and .apk for Android). If you enable Live Sync in AppBuilder, you won’t have to continually reinstall a manually-installed app – it will refresh itself.
Another method to deploy an app to a connected iOS or Android device is to use the ‘deploy’ command in the CLI while plugging in your certificate and/or provision IDs:
$ appbuilder deploy android [--device <Device ID>] [--certificate <Certificate ID>] [--debug] [--release]
$ appbuilder deploy ios [--device <Device ID>] --certificate <Certificate ID> --provision <Provision ID> [--debug] [--release]
Some developers have accumulated their own small device lab or subscribe to groups on social media where they can ask friends to load an app to test. Others make use of the Open Device Labs that are starting to appear in several cities worldwide. It’s easier to install an Android .apk file via a “side-load” process on your Android device than on an iOS phone or tablet, due to the provisioning necessary for iOS apps. To manually install a locally-built .apk file onto your Android device, I use the ADB library included with the Android SDK toolkit.
$adb install /path-to-file
To manually install an iOS app to your iPhone or iPad, you can use AppBuilder’s in-browser tools or the CLI. Provisioning is made easier by using the in-browser tools. Once they are correct, click “run>build” to create a build of your app that can be installed on device using the generated QR code. Similarly, the CLI enables you to specify the provisioning profile and iOS certificate with which to build. A QR code is generated, or you can request an .ipa file to be generated instead, to be manually loaded to your phone via Xcode. In Xcode, click Window>Devices and choose your iOS device from the left panel. Click the ‘+’ sign under ‘installed apps’ to manually add your app to your phone.
Once you have your app on your device, there are several ways to debug it. On Android, ADB tools are very useful:
This command allows you to watch a running log of phone activity. On iOS, you can use Safari’s Developer tools to inspect a properly-provisioned application from your phone via Safari.
For more information on how to debug on Android, iOS, and Windows phones, please see this tutorial.
“‘Keep your temper,’ said the Caterpillar.”
Figuring out all the different ways you can test your app in simulator, emulator, and on device, and understanding when and why to do so in your development process, can seem a little hallucinogenic. A rule of thumb I would suggest is that when you are building out the UI and network calls at the beginning of a project, rely on the simulator and emulator. About halfway through your development phase, switch to testing on device. AppBuilder makes it easy if you can use the Companion App or build with Live Sync. Test on as many devices as you can, and try to rally friends to help you. As always, good luck with your development and let us know about new apps you release to production!
Alice In Wonderland illustrations by John Tenniel. All illustrations and the full e-book are available online.