REST service transfers light data, but service execution time could bring significant delay to the enterprise mobile application. I have already introduced you to the A-Team Mobile Persistence Accelerator (AMPA) in previous post - REST Service Access with A-Team Mobile Persistence Accelerator. Based on AMPA author - Steven Davelaar suggestions, I will post today updated application, where REST service call will be handled in background. This will allow mobile user to continue working with the MAF application, while REST call is being processed in background thread.
Here you can download updated sample application - MobileServiceBusApp_v7.zip. Remote read in background is configurable through AMPA persistence mapping, I have changed it to be false - let's see how it works for slow REST service execution:
Data Control method is executing (sequential in this example) remote findAll operation through AMPA, to fetch employees data. Data collection is loaded to the UI, after service execution is completed:
Server side ADF BC VO is set to wait 30 seconds (waiting for 30 seconds after VO was executed), before completing SOAP response. This allows to simulate slow REST service execution and check how MAF mobile application behaves with sequential service call:
Executing search operation over slow REST operation blocks entire MAF mobile application. User can't navigate to other screens and is locked into current screen, until response comes. This is how it looks like, when I changed search criteria - mobile application waits for the response:
Obviously this is inappropriate, because it blocks application and user can't continue his work. Let's test with AMPA configured to execute REST calls in background - remoteReadInBackground = true:
Data Control method responsible to execute REST action is refactored. I'm only starting remote findAll operation - not waiting it to complete. AMPA generated service class EmployeeService is changed to include additional constructor, where I'm passing instance of Data Control class and a flag to prevent auto query. Here is applyFilter method from Data Control class, it call REST service in background, through AMPA:
AMPA generated class is changed with overriden method refreshEntityList. This method is called automatically by AMPA, when background REST call is completed. Here I'm calling Data Control class method, responsible to refresh UI and display data fetched from the background service:
Data Control class method responsible for UI refresh - it updates Data Control collection and invokes synch with UI:
I will describe a test I have completed, with REST service execution in background. Perform search action with a parameter:
ADF BC on server side executes VO with SQL statement, there is a wait time of 30 seconds:
MAF mobile application is not blocked anymore, as it was with sequential REST service execution. User can navigate to other screen and do different actions:
Once ADF BC VO completes execution and SOAP service returns response, Service Bus is transforming SOAP response to REST. Mobile application receives data and UI refresh happens, to present latest changes. User can view the changes, once he is back to the screen:
In the same way, user could run another search:
While search is running, user could view details for present data:
After returning back to the search list, results for the new search query are displayed - data from REST service call executed in background:
User could load details screen and view the data:
Here you can download updated sample application - MobileServiceBusApp_v7.zip. Remote read in background is configurable through AMPA persistence mapping, I have changed it to be false - let's see how it works for slow REST service execution:
Data Control method is executing (sequential in this example) remote findAll operation through AMPA, to fetch employees data. Data collection is loaded to the UI, after service execution is completed:
Server side ADF BC VO is set to wait 30 seconds (waiting for 30 seconds after VO was executed), before completing SOAP response. This allows to simulate slow REST service execution and check how MAF mobile application behaves with sequential service call:
Executing search operation over slow REST operation blocks entire MAF mobile application. User can't navigate to other screens and is locked into current screen, until response comes. This is how it looks like, when I changed search criteria - mobile application waits for the response:
Obviously this is inappropriate, because it blocks application and user can't continue his work. Let's test with AMPA configured to execute REST calls in background - remoteReadInBackground = true:
Data Control method responsible to execute REST action is refactored. I'm only starting remote findAll operation - not waiting it to complete. AMPA generated service class EmployeeService is changed to include additional constructor, where I'm passing instance of Data Control class and a flag to prevent auto query. Here is applyFilter method from Data Control class, it call REST service in background, through AMPA:
AMPA generated class is changed with overriden method refreshEntityList. This method is called automatically by AMPA, when background REST call is completed. Here I'm calling Data Control class method, responsible to refresh UI and display data fetched from the background service:
Data Control class method responsible for UI refresh - it updates Data Control collection and invokes synch with UI:
I will describe a test I have completed, with REST service execution in background. Perform search action with a parameter:
ADF BC on server side executes VO with SQL statement, there is a wait time of 30 seconds:
MAF mobile application is not blocked anymore, as it was with sequential REST service execution. User can navigate to other screen and do different actions:
Once ADF BC VO completes execution and SOAP service returns response, Service Bus is transforming SOAP response to REST. Mobile application receives data and UI refresh happens, to present latest changes. User can view the changes, once he is back to the screen:
In the same way, user could run another search:
While search is running, user could view details for present data:
After returning back to the search list, results for the new search query are displayed - data from REST service call executed in background:
User could load details screen and view the data:
No comments:
Post a Comment