Other testing configurations

In real life, an Android Wear device seldom runs on its own. Instead, the wearable runs in concert with a phone. The phone does all the heavy lifting (networking to the Internet, for example) while the wearable does things that tiny wrist devices should do (display the time, show notifications, count your steps, and so on).

In the previous paragraph, I write “phone” when I should really write “handheld device.” You can connect a tablet device to an Android watch. But for a watch to be useful, you should connect it to something that’s with you all the time. And people are much more likely to carry phones than to haul around a tablet device.

For the full Android Wear experience, you probably want two devices — a wearable and a phone. The obvious question is, of the two devices, are one or both of them emulated? Are one or both of them real?

To help answer this question, the Android documentation provides a few scenarios:

• Ignore the phone and use an emulated Android Wear device.

  That’s the scenario that I recommend for this chapter’s example.

• Connect a real phone to your development computer and use an emulated Android Wear device.

  See my brief list of tips in this section.

• Use a real phone and a real Android Wear device.

  Again, see my brief list of tips.

Notice one combination that’s missing from this list. None of the scenarios involves an emulated phone. People have posted instructions for connecting two emulators — one for a phone and another for Android Wear. I’ve tried following the instructions, but I’ve never had time to reach the finish line. (I’ve been too busy writing Android Application Development All-in-One For Dummies, 2nd Edition.)

The Android developer training pages have detailed instructions on setting up phones for testing with Android Wear. So I don’t dwell on the details in this chapter. Instead, I point out some of the highlights. These highlights might help you see the forest for the trees while you march step-by-step through the instructions on the Android developer site’s pages.

The Android developer site’s pages on testing with real devices are http://developer.android.com/training/wearables/apps/creating.html and http://developer.android.com/training/wearables/apps/bt-debugging.html.

When you set up a phone for testing with Android Wear, you perform some or all of the following steps:

• Install the Android Wear app from the Google Play Store on your phone.
• Use the Developer options in the phone’s Settings screen to enable USB debugging on the phone.

• (With an Android Wear emulator) Type the following command in your development computer’s command prompt window or Terminal app:

  adb -d forward tcp:5601 tcp:5601

  This command forwards your emulator’s communications to the connected phone.

• (On a real wearable device) Use the Developer options in the device’s Settings screen to enable ADB debugging on the Wear device.
• In the Android Wear app on the phone, pair the phone with the emulator (or with the real wearable device).

For connecting a real wearable device, you have two options:

• Connect the device to your development computer using a USB cable.

  Alas! Some Android wearables don’t have USB ports.

• Create a Bluetooth connection between the phone and the wearable.

  For this option, you have to enable the Debugging over Bluetooth option on the wearable. You also have to set up Debugging over Bluetooth in the Android Wear app on the phone, and type the commands

  adb forward tcp:4444 localabstract:/adb-hub

  adb connect localhost:4444

  on your development computer.

A “Hello” example

Most of the classes and methods that you use to write phone apps work on Android Wear apps as well. For evidence of this fact (but not proof of this fact), follow these steps:

1. In Android Studio, start a new project.

2. In the Target Android Devices dialog box, select two form factors: the Phone and Tablet form factor, and the Wear form factor.

   The real story about form factors depends on your stage of development. To publish a wearable app, you must package your app as part of a phone or tablet app. Consumers have no way of pushing apps directly to their wearables, so they must install an app on their phones and have the phone push the app onto the paired wearable. Therefore, you develop your app for both form factors.

   Strangely enough, when you’re in the testing stage, the opposite is true. Yes, you choose two form factors when you create the new project. But for testing, when you push your app onto a device or an emulator, you push only the wearable part of the app.

   Why is there such a big difference between testing and publishing a wearable app? When you do testing, you don’t sign your app. That is, you don’t add an electronic certificate ensuring that your app comes from a valid source. For more information about signing apps, see Chapter 1 in Book VI.

3. In the usual Add an Activity dialog box, select Add No Activity.

   In this section’s example, you don’t need an activity for a phone or a tablet. But after selecting Add No Activity and clicking Next, you see a new Add an Activity to Wear dialog box.

4. In the Add an Activity to Wear dialog box, select Blank Wear Activity.

   The blank wear activity will appear on your wearable device.

5. Click Next and Finish as often as it takes to get back to the main Android Studio window.

   Your new project has two modules — one named mobile and another named app. (See Figure 2-1.)

   • The mobile module contains code for a phone or a tablet device.
   • The wear module contains code for the wearable.

   Both modules have manifests, Java files, res folders, and all that other stuff.

   In this example, you work exclusively inside the wear module.

6. Expand the wear/res/layout branch in the Project tool window.

   You probably see three layout files — activity_main.xml, rect_activity_main.xml, and round_activity_main.xml.

7. Double-click the layout file for your favorite Android Wear emulator.

   If your emulator has a rectangular watch face, double-click the rect_activity_main.xml branch. If your emulator has a round watch face, double-click the round_activity_main.xml branch.

8. Go to the Text view in the Designer tool.

9. In the layout file, add the following Button element:

   <Button android:layout_width="wrap_content"

     android:layout_height="wrap_content"

     android:text="Click me"

     android:onClick="onButtonClick"/>

   It’s nothing special! That’s the whole point.

10. In the MainActivity Java file for the wear part of the app, add the following code:

    public void onButtonClick(View view) {

      mTextView.setText("You clicked!");

    }

    I’m assuming that Android Studio has already placed a text view in the layout and added the following lines somewhere in the MainActivity file:

    TextView mTextView;

    mTextView = (TextView) stub.findViewById(R.id.text);

    If my assumption is incorrect, add the appropriate stuff to your project.

11. With the Android Wear emulator running, choose Run  ⇒  Run 'wear' in Android Studio’s main menu.

    When you do, this example’s main activity (with a text field and a button) appears on the wearable emulator’s screen. If you click the button, the text inside the text view changes. It’s the same as an ordinary phone app. (See Figure 2-2.)

Dissecting the skeletal watch face project

Many interesting things lurk inside a typical watch face project’s code. This section describes a few of them. As you read this section, you can follow along by examining the code that Android Studio created in the previous set of steps.

Enhancing the skeletal watch face project

Android Studio creates the skeletal app that’s described in the previous section. You get the skeletal app for free simply by clicking buttons when you create a new project. Of course, freebies have disadvantages. For one thing, they seldom do exactly what you want your app to do. For another, looking at canned code isn’t as satisfying as writing your own code.

I can’t wave a magic wand and have you write your own code. But I can give you instructions for adding some of my code to the skeletal watch face app. My code displays the date (in addition to the current time) in Android Studio’s skeletal watch face app.

1. Add the code in the upcoming Listing 2-2 to the end of the onDraw method.

   When you add this code, Android Studio complains about your new mDatePaint variable. You haven’t declared that variable yet. Declaring mDatePaint is your job in the next few steps.

2. Look for the start of an inner class named Engine.

   Every Android wallpaper class needs an engine. In this chapter’s example, the inner Engine class is a subclass of the CanvasWatchFaceService.Engine class. In fact, this inner class makes up most of the app’s Java code.

3. Add the following declaration near the start of the Engine class:

   Paint mDatePaint;

   Next, you have to set the mDatePaint field’s properties. You do this by copying the properties that are used for displaying the time of day and then shrinking the size of the text. Here goes:

4. Add the following statement inside the onCreate method:

   mDatePaint = new Paint(mTextPaint);

5. Add the following statement inside the onApplyWindowInsets method:

   mDatePaint.setTextSize(textSize / 2);

   The characters in the date display are half the size of the characters in the time-of-day display. Notice that the size of the text is a property of your paint. Unlike your standard house paint, Android canvas paint determines the size of the characters in your text.

Listing 2-2: Displaying the Date

String dateString = mTime.format("%m/%d/%Y");

Resources resources = MyWatchFace.this.getResources();

float textSize =

    resources.getDimension(R.dimen.digital_text_size);

int width = bounds.width();

double centerX = width / 2;

int startX =

    (int) (centerX - mDatePaint.measureText(dateString) / 2);

canvas.drawText(dateString, startX,

            mYOffset + textSize + 10, mDatePaint);

That it! You’re done! When you run the app, you see a display like the one in Figure 2-4.

The code in Listing 2-2 does almost all the work. First, a format call creates a String using the current time. Instead of having hours, minutes, and seconds, this string has the month (%m), the day of the month (%d), and the year (%y).

The string "%m/%d/%Y" is called a pattern string, and the letters in the string (m, d, and Y) are called pattern characters. To find out what other pattern characters you can use, visit http://developer.android.com/reference/java/text/SimpleDateFormat.html.

In the skeletal app, the variable mTime belongs to the android.text.format.Time class. As I write this chapter, the Time class has been deprecated. In Java-land, the word deprecated means “made obsolete.” So, starting with Android API Level 22, Android developers aren’t supposed to use the Time class. (Instead, we’re supposed to use the java.util.GregorianCalendar class.) The trouble is, early in 2015, the skeletal code that Android Studio writes still uses the old Time class. I see a line through the call to the Time class’s constructor in Android Studio’s editor. (A line through a name means that the name has been deprecated.) By the time you follow this chapter’s instructions, the skeletal app might use the newer GregorianCalendar class. If so, the following code will create a date string:

SimpleDateFormat dateFormat =

          new SimpleDateFormat("MM/dd/yyyy");

dateFormat.setCalendar(calendar);

String dateString =

        dateFormat.format(calendar.getTime());

In Listing 2-2, after creating dateString, I do some math to figure out where to draw the dateString string on the screen. I want to center the date string horizontally, so I make centerX be half the width of the screen. Then I call the paint’s measureText method to find out how many pixels wide the dateString is. Finally, I put the left edge of the date string (the startX value) at centerX minus half the width of the date string. (See Figure 2-5.)

The drawText method’s third parameter is the distance (in pixels) from the top of the screen to the top of the date string. I confess. In Listing 2-2, I guess at this measurement. I start with the top of the big time of day string (mYOffset), I add the height of the time of day string (textSize), and then I add 10 pixels for good measure. (Again, refer to Figure 2-5.) You can do better than simply guessing the way I do. But there’s not much news in the more accurate code. The calculations for the date string’s height are similar to the ones I do for the horizontal position.