Procedures¶
Local side effects and validations for actions, functions and entity updates.
Overview¶
Working offline adds complications to the validate and save process. Entity updates and actions are sent to the server when the internet is available and not when clicking save. This process could take hours if the user is not near a mobile connection.
When the data reaches the server, it will get validated and this could cause an error. To fix this problem the validations must also be implemented in the client to stop the user saving invalid data.
When the server processes a change, it could also alter related data that the user did not alter on the device. These changes would not show within the client until after the application has synced. An example would be requesting the server change the status of a record by an action. The user will never see this status change until the server has completed the action and the results sent to the client. If the user is to see these status change straight away any side effects of actions must be implemented on the client.
Procedures have been added to the offline clients to reduce these issues. Procedures can be written to alter functions, actions and entity update logic on the device. The client metadata syntax already has support for executions when used within commands. The syntax for procedures has been designed to be as similar as possible.
procedure MyProcedure Number {
parameter Param1Name Number;
parameter Param2Name Text;
variable Var1 Structure(WorkOrder);
variable Var2;
execute {
set Var2 = [Param1Name * 5.0];
return Var2;
}
}
Performance¶
Procedures that are run in the client device are interpreted. Extra care must be taken to ensure they do not become slow. Performance can be monitored in the Windows app. A performance log is shown at the top right of the application which lists how long each procedure takes to run. When considering performance you should be aware that some older Android devices can run 10x slower than the Windows desktop. If a procedure is taking 500ms in Windows this could mean a 5 second wait for a slow Android device.
When trying to improve the performance of procedures consider the following options:
- Only do work if needed. Don't run a for loop if it results in nothing changing
- Only read records out of the database that need updating. Make sure any for loops you use have a where statement to restrict the number of records read out of the database.
- Only save database records if they have changed
For example. Instead of:
for TodoItems into ToDoItem {
if [ShouldCompleteTodoItems = true] {
set ToDoItem.Complete = true;
saveLocal ToDoItem;
}
}
The following would have much better performance:
if [ShouldCompleteTodoItems = true] {
for TodoItems where [Complete != true] into ToDoItem {
set ToDoItem.Complete = true;
saveLocal ToDoItem;
}
}