As a Roblox developer, I currently find ContextActionService’s touch support to be extremely lacking.
Don’t get me wrong. ContextActionService is arguably one of the most powerful tools in the stock API; however, there are a few use cases where I feel it falls short, most of which regarding Touch inputs.
The first use case involves touches in limited areas of the screen or touches on specific UI elements. Currently our best option is to either use the Activated property or listen to the Touch input types and use the Position of the input objects. While this works great for some things it doesn’t work well for cases where you aren’t looking for strictly taps; cases like streamlined custom joysticks or sliders.
The second use case would be to enable handling of developers’ custom control buttons through the ContextActionService stack (which is incredibly useful for unconventional state machines and universal character control scripts)
Of course, neither of these use cases I can think of off the top of my head are impossible to implement currently; however, a lot of functionality present in the ContextActionService would need to be reimplemented by the developer, and reimplementing things in Lua is slow and unfriendly (read: bad for mobile/touch devices). As a result, I propose a nice, neat set of touch improvements revolving around one thing:
Custom Buttons
Currently, the only support for button customization on mobile exists in the GetButton function. Needless to say, there could be a lot more to this functionality. To improve this, I propose two new functions and a tweak to four existing ones.
Instance ContextActionService.AddButton(string actionName, Instance GUIButton)
This would do what it says on the tin; it would add the TextButton or ImageButton passed to the list of buttons that would trigger the bound function, then return the button passed. Simple enough.
Instance ContextActionService.RemoveButton(string actionName, Instance GUIButton)
This is the inverse of the function from before. Rather than adding the button to the list of triggers, it would remove it from the list and parent it to nil, making it no longer trigger the bound function before returning it in case the developer wanted to keep the button for later.
Changes to Existing Functions
Naturally, to follow these changes, GUIButtons (which is what I will call TextButtons and ImageButtons where they are interchangeable, from now on) also need to be treated similarly to KeyCodes and UserInputTypes.
Which is why I propose four functions be changed:
- ContextActionService.BindAction
- ContextActionService.BindActionAtPriority
- ContextActionService.BindActivate
and - ContextActionService.UnbindActivate
BindAction/BindActionAtPriority
The change here is minor; in addition to the input enums currently accepted (KeyCode, UserInputType, PlayerAction) these functions would accept GUIButton instances as a valid InputType, allowing one to bind an existing GUIButton to a new handler where AddButton allows them to bind a new button to an existing handler.
BindActivate/UnbindActivate
These functions, like the ones above, would be edited to accept GUIButtons in addition to KeyCodes. Using a GUIButton in place of a KeyCode would effectively limit your UserInputTypes to Touch, MouseButton1, MouseButton2, MouseButton3, and the Gamepad types, as they are the only types that can activate the button. Developers’ mileage with the types other than Touch may vary.
If Roblox is able to address this issue, it would improve my development experience because I could do a variety of new things like create control UI layouts in studio for mobile easily without having to generate them by script. This is especially important as the mobile market for Roblox is gargantuan and many developers have to implement these things themselves when making advanced mobile controls.
As it stands, I’d argue that the hardest platform to support on Roblox is mobile at the moment (we don’t talk about VR) and these changes could certainly help mobile catch up in ease of input management.