- Available project elements
- Available controls
- Application menus
- Popup menus
- Modal windows
- Managing the "Back" and "Home" buttons
- Back button
- Home button
- Notification about the application inactivity
- Operating mode of focus and selection
- Automatic scrollbars in the windows
- Using a native Java code in an Android application
- Managing directories
- Changing the screen orientation
- Managing threads
- Indirection operators
- Using native Android fonts
- Managing ADB logs
- Debugging deployed applications via the ADB logs
- Printing in PDF
- API level
Specific features of Android applications
The development of Android and WINDEV Mobile applications is different in the following fields:
Available project elements
The following project elements are available for Android development:
Remark: in a query with parameters, all the parameters are mandatory.
- Sets of procedures.
- Window templates.
The following elements are not available for Android development:
- External components.
Remark: Internal components are available for Android development. However, if the internal component includes an analysis, this analysis will be ignored during the execution.
- Reports and report templates.
The following controls are available for Android development:Remarks
- Some style properties ("Style" tab of control description windows), although available in edit mode, are not supported by Android applications.
- You can use a gradient for the background color of the control borders.
The databases available for Android applications are:
- HFSQL (Classic and Client/Server),
WINDEV Mobile includes a Native Connector for SLQLite for Android. The main Hxxx commands are available.
- Memos with HFSQL: The mode used for strings at runtime (UNICODE or ANSI) defined in the project configuration determines the character set used to store strings. By default, ANSI strings assigned to HFSQL memo items are encoded in UTF-8. ChangeCharset can be used to change the character encoding
- SQLite database: If your Android project shares its analysis with another (non-Android) project, HChangeConnection can be used to associate the data files of the application with an SQLite connection. For more details, see Android application: Using and sharing data.
- Memos with SQLite: Storing information in memo format is recommended for the data whose size is less than 1 MB. We advise you to directly save the data in external file format on the internal or external memory of the phone and to store the access path to this data in the database.
- You also have the ability to access an external database (Oracle, SQL Server, ...) via a Webservice. For more details, see Accessing a database via a Webservice.
In an Android application, the application options can be proposed:
- via the Action Bar control. This solution is recommended.
- in menu format (not recommended).
Notes about the menus:
- In edit, the menus of the Android windows are presented like simple drop-down menus.
- At runtime, these menus will be displayed differently according to the number of options:
- If the menu contains less than 6 options, it is displayed like large buttons at the bottom of the screen.
- If the menu contains more than 6 options, the first 5 options are displayed like large buttons and a sixth automatic button ("Plus") allows the user to see the rest of menu like a drop-down menu.
- The menus of Android applications support a single level of submenus. Beyond this limit, a fatal error occurs when running the application.
The context menus are supported by WINDEV Mobile for the Android applications.
- In edit mode, they are presented like Windows drop-down menus but they adopt the appearance of Android menus at runtime.
- They are also limited to a single submenu level.
- On the devices without "right click" (phones for example), the popup menus are displayed after a "long press" on the control to which they are associated.
The modal widows are not supported by the Android operating system. Open
is not allowed.
The windows can be opened:
To pass a return value:
- When it is closed, a child or sibling window can call a local procedure of the window that opened it in order to pass a return value to it. A return value can also be returned via a global variable.
- You can specify the return value via the ReturnedValue property of the child window and retrieve this value via the event "Closing a child window of the window" of the parent window.
Managing the "Back" and "Home" buttons
All the devices operating in Android include a special "Back" key (symbolized in most cases by a little arrow pointing to the left). In a WINDEV Mobile application, this key closes the current window and runs the window "closing" event. If it is the first application window, the closing code of the application will be run and the application will be closed.
An application must be developed in order to behave properly if any of its windows is closed via the "Back" key. In most cases, each window control must be initialized with a default value and the "Back" button must be considered as being a "Cancel" button.
Remark: You have the ability to change this behavior and to run a custom process (to ask confirmation to the user for example and to avoid closing the window especially if it is the first application window). To do so, the window must have a button with a "'Back' button" shortcut ("UI" tab in the control description window).
Pressing the "Home" button does not close the current application: the application is moved to the background. The window "Closing" event is not run.
Remark: Even if the window has a Button control with a "'Home' button" shortcut (defined in the "UI" tab), the code of this button will not be executed. Unlike the Back button, the default behavior cannot be changed.
A long press on the "Home" key allows you to display the list of applications run. Then, the user can select their application when they want to move it to the foreground.
Remark: The Android system does not allow to propose this option by programming.
Notification about the application inactivity
The Android operating system does not allow an application to remain in a process (without giving control back to the operating system) for more than a few seconds. If this case occurs, Android displays a dialog box allowing the user to close the application or to wait for the end of the process:
To avoid triggering this mechanism, the calculation steps must not be included in the main thread of the application. To do so, use procedures started in the secondary threads (for more details, see ThreadExecute
Remark: It is strongly recommended not to handle an application's UI elements from a secondary thread.
The Android designers recommend that a user action triggers a reaction from the application in less than 200 milliseconds to give a good impression of reactivity.
Operating mode of focus and selection
To manage both touch/stylus-controlled UI and keyboard/trackball-controlled UI, Android offers a system for managing focus and selection different from other operating systems:
- The focus can only be moved with a mouse, a trackball or a similar device.
- When the focus is moved, the entry and exit event of the controls are run.
- The clickable but non-editable controls (buttons, list boxes, etc.) behave like the controls in interruption. They do not take focus when they receive a click.
- The "Select a row" event in List Box and Looper controls is run only when the row is selected with a click.
- The "Select a row" event in List Box and Looper controls is not run when the row (with the focus) changes.
Caution: In a List Box or Looper control, the bar does not represent the selection but the focus only.
Automatic scrollbars in the windows
If the size of a window exceeds the size of the screen and if the option "Automatic scrollbars" is checked in the window description, a scrollbar is automatically added to the right of the window. Its presence must be taken into account when designing the window in order for this scrollbar not to overlay the controls.
Using a native Java code in an Android application
Native Java code can be used in an Android application.
The procedure is as follows:
- Create a global procedure in your project.
- In the header of the procedure, click the "WL" symbol to change the type of code from WLanguage to Java:
- The procedure in Java code is displayed:
- Type the Java code in the code editor of WINDEV Mobile.
- If the Java code entered requires specific permissions, they must be explicitly defined when generating the application. For more details, see Generating an Android application.
- Java is "case-sensitive": make sure that you respect the lowercase and uppercase characters in the function names
- The classes and methods of Android SDK often handle a reference on a "Context" object. In an Android project, during the input of native code, you have the ability to retrieve a "Context" object by obtaining a reference on the current activity or on the application context via the following methods that can be directly called in the procedure code in native code:
// Get the current activity
// Get the current "Context"
- To retrieve the View object corresponding to the main control component, you must use the getView method while passing the control name.
Example: The following code returns the instance of "Button" class used by the control:
The management of directories in Android presents the following specific features:
- By default, the current directory of an application corresponds to the "files" subdirectory that is automatically created at the root of the application setup directory.
- The relative paths handled by the application are relative to this directory.
- The full path of current directory is returned by fCurrentDir. By default, you have the ability to read and write in this directory.
- The current directory can be modified by fCurrentDir.
- The runtime directory (returned by fExeDir) corresponds to the application setup directory. By default, the applications are always installed in the /data/data/<package name>.<application name> directory.
- In Android, the file system is read-only on the device and on the emulator. An application can only write to its setup directory or one of its subdirectories, as well as to the external memory (SDCard).
- The "databases" directory is also automatically created at the root of application setup directory to store the SQLite databases handled by the application (unless a specific path was specified during the connection). The path of the "databases" directory is returned by fDataDir.
- To have a storage location common to several applications, use the external memory (SDCard for example). The path of a directory for storing files in the external storage space is returned by SysDirExternalStorage.
- When connecting a device to the PC using the "mass storage" or "disk drive" mode, the SD Card is automatically unmounted from the device and is no longer accessible from it. All running applications installed on the SD Card are killed. While the SD Card is unmounted, you will not be able to:
- start the applications installed on the SD Card.
- access the SDCard from the applications run on the phone.
For more details, see:
Changing the screen orientation
To detect if the screen orientation has changed, use the "Changing the orientation" event in the windows.
Remark: You can use GPS functions
to manage the phone's geolocation functionalities.
- In Android, for security reasons, the "Home" and "End of call" keys cannot be used as shortcuts.
- To use the "Material Design" theme, in the "General" tab of the Android configuration description, check "Apply Material design theme to native controls and to Info/Error/Dialog windows".
- Managing images according to the DPI: The images can be bit-mapped or blurred according to the DPI of the device. You can use the automatic DPI management. For more details, see Android/iOS: Providing an image per DPI.
- CSS styles in SVG images are not supported on Android.
is not available in Android.
The thread can stop itself by exiting from the WLanguage procedure called by ThreadExecute
ThreadExecute("th", threadNormal, ProcThread)
bThreadAlive is boolean = True
// ... Process
// Checks the end condition of the thread
IF <THREAD END CONDITION> THEN
bThreadAlive = False
are supported on the global variables only.
An indirection on a local variable of a process will trigger an "unknown element" error.
Using native Android fonts
The following fonts can be used:
- Droid Sans,
- Droid Sans Mono,
- Droid Serif,
- Roboto Condensed,
- Roboto Light,
- Roboto Thin.
If the device does not support the specified font at runtime, a substitution font will be used (Roboto).
Debugging deployed applications via the ADB logs
When an application is deployed, the possible application errors that occur on the user computers are made available to the application developer in the "ADB log" .
This allows you to retrieve the errors as well as Asserts and traces for all the devices that run the application. The following messages are written into the ADB log:
- Messages of Trace ("Info" level).
- Messages of dbgStandardOutput ("Debug" level).
- Messages of asserts (dbgAssert, dbgCheckxxx, dbgError) ("Assert" level).
- Messages of fatal and non-fatal errors ("Error" level).
The "ADB log" is accessible:
- in the Android Control Center ("Logcat" tab): on the "Tools" tab, in the "Mobile tools" group, click "CCAndroid").
- on each phone. Specific software are used to process and view the content of this file.
- via the "Monitor" tool available in the Android SDK. In this case, you have the ability to view (in the "Log cat" tab) the ADB logs of all applications found on the device connected to the PC (the "USB debug" mode must be enabled on the device. For more details, see Preparing the phone to run the test of an Android application).
The PDF prints support the standard Adobe fonts only (no Unicode format): Courrier, Helvetica, Times, Symbol and ZapFDingbats.
When an application is generated for Android, the resulting APK or AAB contains a target API level (or TargetSdkVersion) of the Android SDK.
This target API level is critical for the deployment and execution of the application. :
- Google can allow or reject an application on the Play Store depending on its API level,
- the Android system installed on the devices, determines the functionalities available to the application and the security rules that must be applied to it according to its API level.
It is therefore necessary to generate the application with a version of WINDEV Mobile that is adapted to the Android version on the target devices and to the application deployment mode.
Overview of the API level (TargetSdkVersion) specified in the Android application manifest according to the WINDEV Mobile version:
|WINDEV Mobile versions||API level (TargetSdkVersion) of generated applications|
| WINDEV Mobile 22 → WINDEV Mobile 23 "Update 2"||24 (Android 7)|
|WINDEV Mobile 23 "Update 3" → WINDEV Mobile 24 "Update 3"||26 (Android 8)|
|WINDEV Mobile 24 "Update 4" → WINDEV Mobile 25 "Update 3"||28 (Android 9)|
|WINDEV Mobile 25 "Update 4" → WINDEV Mobile 26 "Update 2"||29 (Android 10)|
|Starting with WINDEV Mobile 26 "Update 3 → WINDEV Mobile 27 "Update 3"||30 (Android 11)|
|Starting with WINDEV Mobile 27 "Update 4"||31 (Android 12)|
Click [Add] to post a comment