alvinashcraft
shared this story
from 
Falafel Software Blog.
This is post 11 of 15 in the series “31 Days of Mobile Testing with TestComplete”
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.
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.
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:
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:
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:
Call
Simulates an outgoing call.
ChangeLocale
Changes the locale of the device.
Connections
Returns the AndroidConnections object that provides access to the status of Wi-Fi and Bluetooth connections on the device.
CurrentLocaleName
Returns device’s current locale name.
FileSystemManager
Returns the FileSystemManager object that provides access to the device’s file system.
PackageManager
Returns the PackageManager object providing access to packages installed on the device.
PressBack
Simulates pressing the Back button.
PressHome
Simulates pressing the Home button.
Reboot
Simulates rebooting of the device.
RunningTaskInfo
Returns information about the currently running application.
ShellExecute
Runs a shell command on the device.
SMS
Sends an SMS to the specified number.
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.
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.
