When developing applications, the BrightXpress mobility suite provides a cohesive and integrated approach to development, but one should be aware that the BrightForms application is still a database oriented application, and thus the style of coding will affect its performance.
Some strategies to employ to improve performance are as follows:
The first thing to do is to minimise the number queries to run when the form opens. You can find out the number of SQL SELECT statements being executed by your form by simply turning the tracing to 'INFO'. The log file will show you all the SQL statements being executed from the moment the user attempts to open the form.
Ensure that queries which are used to return large sets of data contain only necessary fields; having large string or binary data values for each record in a record set will slow down performance considerably. If large binary or text data values are to be retrieved for records, consider using a parameterised query called only when the record is displayed.
Avoid querying large sets of data when not necessary - if all records are not needed on a single screen, perhaps divide listview records across separate forms, such as categories for the user to choose. This will reduce the loaded records sets, and thus speed up the application.
Avoid loading multiple list views (hidden or otherwise or on multiple tabs) on a form. All of the data controls (hence the list views) will try querying the database to get the data they need before or during the form open, hence resulting in a performance drop. The Disable Data Load On Form Open/When Hidden/When Disabled options may be used to control when listviews are loaded.
Display only the columns needed in list views. Displaying additional number of columns that are not needed will slow the loading of the list view data.
Avoid multiple table joins if possible. Table joins extremely slow the execution of the SELECT statements, especially on mobile devices. Try displaying the secondary data in separate forms only when the user needs to see the data (through a button, for instance).
Avoid listview colour coding and/or utilising the listview datagrid if you have items in the list view in 100s. The colour coding of each row in a list view with this many entries will slow the form's loading drastically, as will the application of datagrid elements.
If you have already retrieved the data in a parent form, and you need to use it in child forms, pass this information to the child forms using form variables etc. This avoids the re-running of queries.
Remember combo boxes and data bound forms will also be running their own queries when the form is opened. Again, if you just need to show the current selection, display it using a label. Then, if the user needs to change the selection, then provide another screen to display the possible entries (through a small search button for instance).
Develop your application directly on the device, or test it on the device as often as possible. Sometimes it is easier to develop applications using the desktop version of BrightForms, but once the application is put onto the device, it could be too late in the development cycle to find the performance issues. Always test your application with the real data, not small limited test data.
If you are displaying a subset data in specific form (i.e. you are running SELECT statements with WHERE clauses), make sure you have indexes on these columns. You can create indexes using Database.ExecuteUpdate() method when the application is started.
Avoid searches on String columns. If possible use numeric (Integer) columns where you have to search for a subset in a table. Even if you have indexes on String columns, the search on String columns will still be considerably slower than a search on Integer columns. Likewise, using the 'like' operator will also slow down parameterised queries.
Be mindful of when peripherals are used on devices, particularly Windows Mobile, as calling methods to open and close peripherals such as scanners will hold up processing on the device.