On 'next' or 'previous' virtual keyboard in iOS - ios

iOS5+ shows next/prev buttons above the keyboard:
Because they change the focused element on the page, they can cause issues with my single page app's layout. The 'tab' key on normal keyboards can cause similar issues, but I can slightly change its functionality to only cycle around the inputs I want with a custom keydown event.
Is there any way to do something similar for those buttons?

I'm not really sure what your problem is.
My guess is that when you change focus with "Previous" and "next" button, something goes wrong with your design. And I'm also guessing that you click these when you are in an input (although it's pretty obvious).
When you change from an input to another (With tab key, using "previous/next"-buttons or by mouse), a blur event is triggered.
Now, you don't say what library, if any, you are using. But the fix is similar all around I would say.
if you use jQuery, do something similar to this:
//Selects all input elements, and binds a anonymous function to them. This function
//is run when the blur event is triggered, meaning when we change focus to something else
$("input").on("blur", function () { //Or live, depending on jQuery version
//Your code here, that I assume you already have
});

Related

Unable use a TextField at the bottom of the screen in a LazyColumn

I have this code
setContent {
val items = mutableListOf<Int>().apply {
(1..100).forEach { add(it) }
}
LazyColumn {
items(items) { item ->
TextField("$item", {})
}
}
}
With android:windowSoftInputMode="adjustResize" in my AndroidManifest.xml.
If I click on a TextField at the top of the list, I can enter text fine.
If I click on a TextField near the bottom of the screen, the keyboard appears momentarily, then disappears quickly after, and prevents me from entering text.
How can I enter text when the TextField is at the bottom of the screen? Thanks!
Your keyboard disappears after having appeared for a brief, shiny moment. Here's the reason:
You tap the TextField, it calls it's built-in focus requestor, and requests the focus from the OS by calling appropriate (or inappropriate, who's to say) internal methods, as a result of which, the keyboard pops out (again, built-in mechanism.) and you can type all the more you want... AS LONG AS THE FIELD IS VISIBLE; or in Compose terms, long as the Composable holding the requestor, is in composition.
It should be clear, that once the Composable that owns the focus requestor goes off the screen, it is destroyed (well not every time, there are only certain specific cases when it is destroyed..., but yours is one of them), and when the Composable is destroyed, the focus requestor is destroyed. No focus requestor, no focus owner - the keyboard vanishes.
Now this is really important because you are using a LazyColumn, a lazy Composable, infamous for its merciless slaughtering of the Composables that are no longer visible to the user. HENCE, as long as it is the top (or other "visible") textfield that is in concern, it stays and works as expected. However, the bottom textfield, as the keyboard pops up, goes so much out of the visible bounds, that it gets slaughtered (recycled is the technical term, but what fun is that?), taking away the purpose of the keyboard.
Now, the lazy column, like any criminal, left a clue behind, and didn't notice it, which lead us to catch him red-handed. It is quite interesting, really, to see the column in action.
Now, workarounds include using a column, instead of a lazy column; creating your own lazy column using a custom lazy Composable, and manually handling the heap size for the Composable so the final field doesn't go out of composition.
That's it, you're cured.
Just leaving another answer, since OP didn't verify other purpose of him specifying adjustResize,if whether removing or changing it will be fine, but another solution aside from the mentioned comment about different API version is specifying adjustPan, which worked in my case, either
via AndroidManifest
android:windowSoftInputMode="adjustPan"
or programmatically
window.setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN)
Same code base but with adjustPan
This issue is fixed in the current alpha version 1.4.0-alpha05
https://issuetracker.google.com/issues/179203700

jQueryUI datepicker redisplays after selection

The datepicker is managed by knockout-jqueryui in a Durandal view presented as a modal dialog. The calendar pops up when the corresponding INPUT is focussed, and hides when it is blurred. Data-binding works fine.
But when the user selects a value, the calendar closes, the INPUT updates and the calendar re-displays. It works, but it's annoying my users because they are mouse obsessed and the calendar obscures the control below, making it hard to click on it. Yes, I know they could press tab. I have pointed this out.
How can I stop the re-display? Ideally, triggers for display would be focus and keydown. I have no problem with configuring it to manual control and switching with data-bind="change: showCalendar, ..." or similar, if that's how one does this.
So, what's the usual way to go about this? If it's manual control as I describe above, what are some keywords to expedite finding the relevant section(s) in the documentation? (How to set it to manual and how to hide/show it manually.)
(I found show() and hide())
The showOn option for jQuery UI Datepicker is passed through by knockout-jqueryui.
It defines only two values, 'focus' and 'button'.
There is no explicitly defined mechanism to disable auto-display, but I found that a value other than the defined values has the desired effect. I am passing 'click'.
Manual control methods are show and hide.

iOS 7 hover/click issue - no click triggered in some cases

I have a kind of "widget" - a data table with some rich functionality like sorting, row selection and else.
In some cases (widget placement/nesting in DOM) clicks on it's rows are not triggered in iOS 7 Safari.
Widget is using jQuery 1.6.4
I can't publish a whole widget code (and you really wan't this to happen ;)), but I can narrow down a reproduction scenario to the following case:
Simple html table with some rows, two cols in each
First column contains a "checkbox" - simple div which is normally hidden and becomes visible, then parent row getting hovered. Visibility is triggered with CSS only
Every row has a click event handler. No mater what it does. In my example it will trigger an alert()
Table's parent is a block element with a fixed height and overflow-y set to auto
Table is bigger than it's parent, so, some table content is hidden and can be seen with scrolling
Here is a jsFiddle: http://jsfiddle.net/822eG/4/
On any desktop browser items are successfully hovered, click is triggered. On iOS7 hover is working but click is NOT triggered.
NOTE: On iOS you must tap twice to trigger click. First click will trigger hover and you'll see a "checkbox", then second tap must trigger a click, but it doesn't...
Any of those conditions is REQUIRED to reproduce an issue. Remove a single one and it starts working...
If you remove a "checkbox" appearance - click will work (http://jsfiddle.net/822eG/5/).
If you remove a height fix - it will work (http://jsfiddle.net/822eG/6/).
If you remove a overflow scrolling - it will work (http://jsfiddle.net/822eG/8/).
Any workaround is needed but functionality should be kept untouched. So, I can't remove "checkbox", size fix, hovering, clicking or overflow scrolling. Also, changing HTML markup is hardly to happen.
NOTE I've got a solution - see my answer below. But I still need a better workaround to keep using CSS as mush as possible.
ADD: Filed a bug to Apple #16072132
Try this:
.wrapper {
-webkit-overflow-scrolling: touch;
}
To get iOS to ignore hover states, try this:
.wrapper
{cursor: pointer;}
You can use this on any element to get it to function as expected.
Suddenly, I've got a solution... Using JavaScript I can remove :hover selector but still keep functionality.
If I will trigger checkbox visibility not by CSS :hover but by class and set it via javascript, it will work.
http://jsfiddle.net/822eG/10/
My current working solution requires no any changes in a whole code base and works fine in our conditions
With MutationObserver, monitor node insertion into head
If new node is inserted, and this is a link, check document.styleSheets
For each sheet check it's rules
If rule selector (access by document.styleSheets[n].rules[i].selectorText) contains :hover check styles for this selector
If styles contains display different from none or visibility different from visible - this is a "show by hover" style
For each such style change it's selector - replace :hover by .hover and declare a body delegate for mouseenter and mouseleave events which will toggle .hover class on triggered element
Full source code here: https://gist.github.com/Olegas/9143277
..try using this:
$('.row').on('touchstart click', function(){
alert('clicked');
});

jQuery mobile button staying pressed

I have a jQuery mobile button hooked up to an ajax POST. If the POST fails, the jQuery mobile button stays pressed instead of ``popping up". Any ideas?
It can be done easily.
Here a jsFiddle example made for one of my previous answers: http://jsfiddle.net/3PhKZ/7/
If you take a look there's this line of code:
$.mobile.activePage.find('.ui-btn-active').removeClass('ui-btn-active ui-focus');
It will try to find pressed button on a current active page, if it succeed it will remove 2 classes responsible for a button pressed state. Unfortunately pure CSS solution is impossible here. You can test this example, just comment top line and see what will happen.
One last thing selector $.mobile.activePage can only be used during the pagebeforeshow, pageshow, pagebeforechange, pagechange, pagebeforehide and pagehide page event so takes this into account.
In case you cant use this selector just replace it with a page id, like this:
$('#pageID').find('.ui-btn-active').removeClass('ui-btn-active ui-focus');
So your final code would look like this:
$.ajax( "example.php" )
.success(function() { doStuff(); })
.error(function() {
$('#pageID').find('.ui-btn-active').removeClass('ui-btn-active ui-focus');
})
Add an error clause to your AJAX handling which pops the button back.
$.ajax( "example.php" )
.success(function() { doStuff(); })
.error(function() { /*code to unpress button here*/ })
For those folks out there using "input" and not "anchors" as buttons. When using for instance "submit" and "reset" buttons and pressing them they remain as active, which is sometimes undesired depending on the actions performed when the buttons is clicked.
I am not sure if it is the expected behaviour, I have read that is a jQuery mobile bug, but the behavior is still present at least in jQM 1.3.2
An yes the trick is to remove the active class as stated however those get tricky because the class is not added to the input tag, i*t is added to a parent DIV* that is created by all of the ugly stuff around the "input" to style the button, that is why removing the active class when selecting the input doesn´t work.
By analyzing the HTML produced by jquery mobile a workaround is to:
remove the active class on the input parent instead of the actual input element.
$('.mybutton_class_or_ID').parent().removeClass('ui-btn-active');
I prefer this approach instead of clearing all the active classes across the whole page in case you want to be more selective with the class removal.

Keyboard pushes the whole view up in WP7

I have 3 grids:- Header,Body and Footer with Body having textboxes.
I have included the Body inside a scrollviewer so that user can type as much data as he wants in the texboxes of Body.
But when the Keyboard pops up the whole view is pushed at top and I cannot see the Header.
The textboxes have wrapping on and also accepts return.
Can the scrollview move up the text when keyboard pops up?
Thanks and Regards,
Kanaya
Not entirely sure if this will help. How about some XAML?
You could capturing the Focus event of the text box that brings the Keyboard up. In that event you could set the scrollViewer.HorizontalOffset property to some caluclated value to get whatever you want in view.
Edit: HorizontalOffest is only a getter user ScrollToHorizontalOffset instead
You probably can make it scroll up like you want, but it will appear very strange to seasoned users of the WP7 operating system. Expected behavior for text input is exactly what you described, the notion Microsoft (I believe) is trying to hit here is that when you want to type something in, you want to clear everything else out of view, and only focus on the textbox at hand.

Resources