Using Mobile, Device and Desktop Objects

Using the Mobile Object

The Mobile object is the starting point to reach connected mobile devices in TestComplete. In the Object Browser, Mobile is analogous to the Sys node. Instead of listing all processes, Mobile represents all devices connected. I have an iPhone and an Android device connected to a computer running TestComplete. They both show up in the Object Browser:

List All Devices

You can roll through all the devices using the Mobile ChildCount property and Child() method. The code is generic and doesn’t care if we’re working with iOS or Android.

function spelunkMobileDevices(){
  var count = Mobile.ChildCount; 
  for(var i = 0; i < count; i++){
    var device = Mobile.Child(i); 
    Log.AppendFolder(device.Name);
    // log info about the device here
    Log.Message("OS: " + device.OSType); 
    Log.PopLogFolder();  
  }
}

The log lists the operating system for each device. The devices are either AndroidDevice or iOSDevice objects. Each with its own set of properties. For example, AndroidDevice contains a manufacturer name. But, Apple being Apple, the same property doesn’t exist for iOSDevice.

Current Devices

If the name of the device is known, you can pass it to the Mobile.Device() method. My Android device is named “SM-N910V”. I can check if the device is connected or log information about the device.

if (Mobile.Device("SM-N910V").Connected){
  Log.Message(Mobile.Device("SM-N910V").Name + 
    " is connected to TestComplete"); 
}

TestComplete also has the notion of a current device. Mobile.SetCurrent(<device name>) makes the device current so you can refer to Mobile.Device() from then on. For example:

var deviceName = "SM-N910V";
Mobile.SetCurrent(deviceName);
Log.Message(Mobile.Device().Name + " is the current device"); 

var nonExistentDevice = "non-datur"; 
Mobile.SetCurrent(nonExistentDevice);
Log.Message(Mobile.Device().Name + " is the current device");

If the device doesn’t exist when you call SetCurrent(), TestComplete logs an error. Here’s a log where SetCurrent() is passed an existing device name, then a non-existent device name.

If the device might not be valid, use the Mobile.TrySetCurrent() method. TrySetCurrent() returns true if successful, but doesn’t log an error if the device isn’t found:

var nonExistentDevice = "non-datur";     
if (Mobile.TrySetCurrent(nonExistentDevice)){
  var currentDevice = Mobile.Device();
  Log.Message("TrySetCurrent() successful for " + nonExistentDevice);
} else {
  Log.Message("TrySetCurrent() was not successful");   
}

The Device Object

Once you get the device object, the field really opens up. Try setting a breakpoint after getting the device.

The device object is either an AndroidDevice or an iOSDevice object. A watch on the device object shows a rich set of objects and methods. In particular,  the OSType property tells you if you’re working with Android or iOS. You can see that the AndroidDevice object (on the left) and the iOSDevice (on the right) have a lot in common.

Device properties and methods seem to fall into a few groups:

• Ubiquitous TestComplete properties and methods that show up no matter what you’re testing: ChildCount/Child(), Exists, Index, Findx/Waitx methods, Keys(), and so on.
• Mobile-specific user interface actions Touch, TouchAndHold, TouchPress, and TouchRelease.
• Device meta information like DeviceName, DeviceInfo and OSInfo. These properties are OS specific. For example, the DeviceInfo property is represented by AndroidDeviceInfo and iOSDeviceInfo objects.
• Mobile hardware interfaces like GPS, Sensors and SensorCount.
• OS-specific properties and methods for Android or iOS devices.

At the time of this writing, the only unique iOS property is ApplicationManager. ApplicationManager provides access to installed applications on iOS devices. ApplicationManager is roughly parallel to PackageManager on Android devices. The remaining members are specifically for Android devices:

The Desktop and Taking Screenshots

To get screen dimensions, change device orientation, or take screenshots, AndroidDesktop and iOSDesktop objects have everything you need. To get at the AndroidDesktop, you need to enable the TestComplete Agent from the Mobile screen. For the iOSDesktop, you’ll need to test against an instrumented app before the property has meaningful data. Both objects have Width and Height properties, SetOrientation and GetOrientation methods and a Picture method for saving the desktop image.

The example below saves the current device orientation, then rotates to each possible orientation: portrait, landscape left, landscape right and upside-down portrait. To get a screenshot, pass either the desktop or desktop.Picture() to the Log.Picture() method. Finally, the device is set back to it’s original orientation.

Mobile.SetCurrent("SM-N910V"); 

var desktop = Mobile.Device().Desktop; 
// save the initial orientation
var saveOrientation = desktop.GetOrientation(); 
  
var orientations = {
  Portrait: 0,
  LandscapeLeft: 1,
  PortraitUpsideDown: 2,
  LandscapeRight: 3
}

// try each orientation and take a screenshot  
for(var index in orientations){
  desktop.SetOrientation(orientations[index]); 
  Log.Picture(desktop.Picture(), "Desktop in " + index + " orientation");   
}
  
// restore original orientation
desktop.SetOrientation(saveOrientation);

Something unexpected happened when I ran this. The physical phone swiveled from one orientation to the next, just as you might expect. But the logged images are all shown right-side up.

Wrap up

In this blog we explored using mobile, device and desktop objects. We used the Mobile collection of children to get at all connected devices. Whether they are iOS or Android devices, we’re able to work with them in a generic way, up to the point where we reference an AndroidDevice or an iOSDevice. We also looked at the Desktop object to handle orientation, dimensions and screenshots.

Not having instrumented apps is cramping our style, so tomorrow we’ll start talking about open, i.e. instrumented apps. That will give us full control and provide all possible information about app internals.

See you tomorrow.

The post Using Mobile, Device and Desktop Objects appeared first on Falafel Software Blog.