As a business, we are currently looking into enable K2 to be accessed through a mobile device (i.e via the K2 Workspace app on an Android phone).
Prior to rolling this out, I have been doing some exploratory testing and have come across a potential issue.
A common theme across our apps is that there is a Picker Control, which is linked to K2's built-in Active Directory Smart Object. The User uses this control to pick a Line Manager, who will essentially get an approval Task in the next stage of the workflow.
It is intended that this Form may be used offline, I have configured the SmartForm to be accessed offline and I have configured the Picker control to cache the data.
When accessing the Form for the first time on a mobile device, it takes a very long time to load.
I have referred to K2's documentation and they recommend not caching data where there is a large number of rows. Has anyone come across this before?
One idea I've had (which I think is not great all), is to somehow detect if the Form is launched on a mobile device and then amend the form (via rules/logic) so that the user enters the Line Manager directly, rather through the use of a picker control.
However, this relies on the user inputting the correct Fully Qualified Name. The whole point of the picker control was so that the user searches for a name and then behind the scenes, the Fully Qualified Name is used to assign the Task in the Workflow.
I'm assuming this is a common scenario - ability to select from active directory on a mobile device, with offline mode in mind.
Are you able to modify the call populating the picker control data in a way to limit the number of rows returned and in need of caching? Such as, if you know based on the logged in user that they are likely to only pick a manager value from a specific group? If so, you can look to add inputs on the initial smartobject call for the picker based on the logged in system value, narrowing the selection and caching load.
Another suggestion would be to consider using a system smartobject such as the UMUser smartobjects over Active directory smartobjects for performance considerations. Picking a K2 system smartobject and method that pull directly from K2's built in identity cache versus a call out to Active Directory generally results in quicker performacne.