Can you try using a different virtual keyboard to see if that resolves the issue? I have no way of reproducing the problem you've described on any of my devices, and without a way to reproduce it, it's difficult to know what is occurring.
Also, while this problem might appear somewhat simple in nature, it's actually quite complex because there is code that tries to detect when the user does something like tap in the number field, then scroll the entry in the list out of view. In this circumstance, I have to forcefully end focus and hide the keyboard. When I did not do this, the problem is that views in the list are recycled automatically by the Android framework (i.e. virtualization) when they scroll out of view, but if the edit component is still focused when this occurs, the app enters a weird state and all sorts of things can go wrong in the logic and display. So I catch when the view is recycled and tried to hide the keyboard at that point. However, this doesn't work reliably across Android versions and manufacturers, because sometimes the order of events is completely bizarre and a view will get allocated, recycled then allocated. So I have to track the time at which the view was last focused, and try to determine if the Android framework is exhibiting that odd behavior with recycling then allocating the same object, and not hide the keyboard in that case. What is occurring on your device, based on the description, is the Android framework is recycling the view the second you tap on it, then allocating it some time after, but something about the order and/or timing is causing my code not to forcefully focus the edit control after it's reallocated. So MobileSheets will just hide the keyboard, then not shown it again because the code never triggered properly. So I don't have a good answer for this unless I can reproduce the issue and carefully track the sequence of events in the debugger to understand what in the world is going on. It's also possible my code is very quickly requesting that the keyboard is hidden then shown, but your specific device is not honoring the request to show the keyboard, and only processes the hide.
Thanks,
Mike
Also, while this problem might appear somewhat simple in nature, it's actually quite complex because there is code that tries to detect when the user does something like tap in the number field, then scroll the entry in the list out of view. In this circumstance, I have to forcefully end focus and hide the keyboard. When I did not do this, the problem is that views in the list are recycled automatically by the Android framework (i.e. virtualization) when they scroll out of view, but if the edit component is still focused when this occurs, the app enters a weird state and all sorts of things can go wrong in the logic and display. So I catch when the view is recycled and tried to hide the keyboard at that point. However, this doesn't work reliably across Android versions and manufacturers, because sometimes the order of events is completely bizarre and a view will get allocated, recycled then allocated. So I have to track the time at which the view was last focused, and try to determine if the Android framework is exhibiting that odd behavior with recycling then allocating the same object, and not hide the keyboard in that case. What is occurring on your device, based on the description, is the Android framework is recycling the view the second you tap on it, then allocating it some time after, but something about the order and/or timing is causing my code not to forcefully focus the edit control after it's reallocated. So MobileSheets will just hide the keyboard, then not shown it again because the code never triggered properly. So I don't have a good answer for this unless I can reproduce the issue and carefully track the sequence of events in the debugger to understand what in the world is going on. It's also possible my code is very quickly requesting that the keyboard is hidden then shown, but your specific device is not honoring the request to show the keyboard, and only processes the hide.
Thanks,
Mike