I’ve developed some embedded views I’d like to use for both mobile / touch devices and desktop clients. I’d like any command sent from a touch to trigger a confirmation popup (I already have this working as an event with messages), while any command sent from a desktop client I’d like to forego the popup.
For the purposes of this discussion, lets say I’m using a Multi-State Button and a Numeric Entry. Can I use a scripted onActionPerformed event to identify the input type, or do I need to separate it into two events (onClick, onTouchEnd)?
The onActionPerformed Event would leave you in a state of having no information about the type of input which triggered the event
onActionPerformed runAction docstring:
This event is fired when the 'action' of the component occurs.
Arguments:
self: A reference to the component that is invoking this function.
event: An empty event object. <--that will not help you.
So you have two options available to you:
Split up the logic into the onClick and onTouchEnd Events.
Use the onActionPerformed Event and use the following code to branch your logic as necessary
if self.session.props.device.type in ['ios', 'android']:
# open your popup.
Note that this only tells you that the user is using the native app; if they are using Chrome on their mobile device this will return “browser” and act as if they were using a desktop. Due to this, there is no true way to determine whether a user is using a mouse or their finger/stylus.
Thank you - this is the answer I expected, but wasn’t sure if there were some other recommended solution for differentiating between touch / mobile and mouse / keyboard / desktop.
Unfortunately, not using the app. I’ll give it a go splitting the script between the input types and see how it works. In the case of the numeric entry, if the user hits enter to send the value, I will need to script for a keypress as well, yeah?
It sort of depends. the supplied value will be submitted via ‘Enter’ or focus lost, so you could encounter either. Suppose a user inputs some value and then presses ‘Tab’ - the value would still be supplied. n instances like that, you might be better off with some sort of a valeChanged script attached to the property.
I had not considered loss of focus as well - that’s a good point. It seems significantly simpler to just build separate components for mobile and desktop in this instance.
If you don’t mind - for the valueChange script, is there a function to identify the input source and throw the confirmation window, or how would / could you go about that?
If you’re not using the app, I don’t think you can differentiate the input source. I would need to set up a test View to try it, but I won’t have the time to do that until much later today. I would avoid separate components, but there ARE other avenues available.
If you expect your “mobile” users to be using a device of a certain size, you could set up a Breakpoint Container for the View in question. Configure your breakpoint container so that mobile devices would get the “small” version while Desktop users would get the “large” version, then design the large version first. Once it’s ready, copy the necessary components over to the small version and introduce the Actions necessary to prompt for confirmation from a mobile user.
I already had the view designed on a breakpoint, and the components on an embedded view. I made a copy of the embedded view and added the mobile actions needed. So small screens receive the embedded view with mobile actions, and the larger screens receive the standard embedded view.