Running and testing an app

As well as being faster than virtual devices, actual devices also allow us to test our apps in real-world situations.

Connecting a real device to our development environment requires two steps:

A real device can be very useful for quickly testing changes in the functionality of an app, but to develop how our app looks and behaves on a variety of screen shapes and sizes will mean that we will create some virtual devices.

Android virtual devices (AVDs) allow developers to experiment freely with a variety of emulated hardware setups, but they are notoriously slow, can exhaust the resources of many computer systems, and lack many of the features present in actual devices. Despite these drawbacks, virtual devices are an essential part of an Android developers' toolkit, and by taking a few things into consideration, many of these hindrances can be minimized:

It is generally quicker to construct virtual devices to suit specific purposes rather than an all-purpose one to test all our apps on, and there is a growing number of third-party Android emulators available, such as Android-x86 and Genymotion, that are often faster and have more development features.

It is also worth noting that when testing for layouts only, Android Studio provides some powerful preview options that allow us to view our potential UIs on a wide number of form factors, SDK levels and themes, as can be seen in the next image:

For now, create a basic AVD to run and test the current project on. There is nothing really to test, but we are going to see how to monitor our app's behavior during runtime and how to use the debug monitor service to test output without having to use the device screen, which is not an attractive way to debug a project.

The following demonstration works equally well on either an emulated device or a real one, so select whichever is easiest for you. If you are creating an AVD, then it will not require a large or high density screen or a large memory:

The Device Monitor is useful in several ways:

Using a text view to test our factory pattern is a convenient but clumsy way to test our code for now, but once we start developing sophisticated layouts, it would soon become very inconvenient. A far more elegant solution is to use debug tools that can be viewed without affecting our UIs. The rest of this exercise demonstrates how to do this:

Running the app and testing our factory demo should produce an output in the logcat monitor similar to the one seen here:

05-24 13:25:52.484 17896-17896/? D/tag: Brioche
05-24 13:36:31.214 17896-17896/? D/tag: Baguette
05-24 13:42:45.180 17896-17896/? D/tag: Roll

Having seen how we can test our apps on both real and virtual devices and how we can use debug and monitoring tools to interrogate our apps during runtime, we can now move on to a more realistic situation involving more than a single factory and an output more sophisticated than a two-word string.