              
Simulating Device Use
You can use Qt Simulator to test applications that use the Qt System Info API to access general information from the mobile device. Mobile devices have been designed for use when mobile. Keep the characteristics of mobile devices in mind when you create applications for them. Use Qt Simulator to simulate the behavior of applications on different device models in different conditions:
Running Out of Battery PowerMobile devices are not constantly connected to a power outlet, but run on battery power. Optimize power consumption to keep the total consumption at an acceptable level and to prevent users from running out of battery power. In addition, make sure that applications run successfully in low-memory condition or display a clear and informative error message. You can write a script that decreases the battery level setting, to check how applications behave when the device runs out of power. You can load an example script that decreases the value for battery level, scripts/examples/runOutOfBattery.qs. For more information on loading scripts, see Scripting. You can also check how applications behave, when the mobile device is connected to a power outlet or it is charging. Change the Battery level and Power state settings in the Generic section. Using Silent and Offline ProfilesProfiles allow users to adjust and customize ringing tones, alert tones, and other mobile device tones for different events, environments, or caller groups. Users can change the active profile on their devices. The Offiline profile (flight mode) prevents mobile devices from accidentally switching on, sending, or receiving messages, or using WLAN, Bluetooth, GPS, or FM radio. In addition, it closes any Internet connection that may be in operation when users select the profile. Test applications with different profiles to make sure that:
In the Generic section, Profile field, select profiles to test the application with a particular profile. Changing Device LanguageImplement predefined texts in the application UI using logical names instead of hard-coding them to the application. This enables localization by changing the language packet (LOC file) that is used. After translation, UI texts in different languages may take up more space than the original text. To prepare for text expansion, avoid using long and difficult UI text. Do not truncate the predefined UI texts even if the components may do it automatically. This makes it difficult to understand the texts and creates a feeling of unfinished software. You can fine-tune UI text strings to different display sizes by producing separate text strings for the small and large displays (orientation, aspect ratio, physical size). This avoids the problem of having abbreviated text strings when there is plenty of display space available. When users change the language settings on the mobile device, the localized version should be started automatically. Click the Advanced Settings button to display the language settings in the Generic section:
Change the Language and Country code settings to test that the localized versions of your application start correctly and look and function as they should. Click Show next to Available languages, and then click Add to add new language codes. Use the ISO 639-1 language codes. Supporting Device FeaturesMobile devices support different sets of device features, depending on their configuration and the underlying hardware. When you develop applications for multiple devices, you can programmatically determine which platform, software version, languages, features, and accessories a particular device supports. This allows you to programmatically enable and disable application functions for a particular device. Change the Features in the Generic section to check how your application behaves when a particular device feature is supported or not supported. For example, devices can support several physical connection methods, such as Bluetooth, Infrared, and USB (universal serial bus) for downloading data. Devices can also have a Memory Card available for storing the data. Change the Operating System, Qt, and Firmware Versions to check how your application behaves on a specific version. Click Change to specify the version. Specify firmware versions as follows: major.minor.build. If a particular version does not include the build part, set it to 0. If a particular element is not available at all, the API returns the error Not Installed. Accessing ServicesThe basis for access security is the effective identification of the users and the equipment they are using. The device can be protected with a lock code, while the SIM card, memory card, and applications can have their own PIN codes and passwords. For enterprise applications, this can mean that only a specific user with a specific application, device, memory card, and SIM card can access the corporate data. Devices are identified by international mobile equipment identity (IMEI) and international mobile subscriber identity (IMSI) numbers. Change the IMEI and IMSI numbers in the Generic section to test access security for applications. Handling User InputIn order to support as many target devices as possible, applications must support different input control configurations:
For devices that support both hardware keypad and touch interactions, consider which is the best mode of interaction for the application. For touch-only devices, all interactions should naturally be touch-optimised. For devices that support only the hardware keypad, touch-only components can be flagged out of the application. This way it is possible to create applications that will function with different device configurations. Change the Input methods in the Generic section to test how the application handles different input methods. Identifying DevicesYou can specify the Manufacturer, Model, and Product name to allow applications to identify the device. You can write any values in the fields. For example, you could set Manufacturer to Nokia and Model to N97. Using ColorsLike computer monitors, mobile devices use an additive color process. Unlike print media, which begin with a white surface, the computer screen begins as a black surface to which colored light red, green, and blue (RGB) is added. Although early mobile devices supported very few colors, color support is now quite robust, with a large proportion of devices providing 12-bit (4,096 colors), 16-bit (65,536 colors), or 24-bit (16 million colors) color support. However, similar to the variety in screen size, many devices in use support varying color depths, with newer, low-cost models typically supporting 12- or 16-bit color depths. Applications can query the color scheme of the mobile device and adapt to it. For example, applications can switch to a night color scheme when brightness falls below a certain value. Change the Color depth and Brightness values in the Generic section to change the way the application perceives them. [Previous: Quick Tour] [Next: Simulating Networking] X
|
