[TIMOB-16110] iOS 7 Issue with TableView and autoAdjustScrollViewInsets
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | n/a |
Status | Open |
Resolution | Unresolved |
Affected Version/s | Release 3.2.0 |
Fix Version/s | n/a |
Components | iOS |
Labels | autoadjustscrollviewinsets, extendedges, ios, iphone, navbar, navigationWindow, tableView |
Reporter | Matthew Kinbaum |
Assignee | Unknown |
Created | 2013-12-25T02:18:33.000+0000 |
Updated | 2018-02-28T20:04:25.000+0000 |
Description
I am running into the following problem when I create a NavigationWindow and a TableView. The TableView is hidden beneath the navbar. This is an issue that is present throughout my entire application. See first attached image for this issue.
Here is an example case where in my app.js file, I am doing a simple user authentication. Depending on the outcome of that, determines which screen my user is navigated to. For this example, the user is directed to the login screen. Here is a snippet of code from that.
app.js
var nav = Ti.UI.iOS.createNavigationWindow();
var viewInc = require('login');
var viewWin = new viewInc.LoginUser(nav);
nav.window = viewWin;
viewWin.autoAdjustScrollViewInsets = true;
nav.open();
You can see that I am adjusting the scroll view insets before the window gets opened as stated in the docs. Now in my login.js file, I have the window and table view objects. Here are the properties associated with those.
login.js – window
mainWin = Ti.UI.createWindow({
backgroundColor:'#ededed',
width:'auto',
height:'auto',
title:'Welcome',
leftNavButton: Ti.UI.createButton({
title: 'Register',
color:'#fff',
font:{
fontSize:17,
fontFamily:"Helvetica Neue"
}
}),
rightNavButton: Ti.UI.createButton({
title: 'Sign In',
color:'#fff',
font:{
fontSize:17,
fontFamily:"Helvetica Neue"
},
enabled:false
}),
navTintColor:'#fff',
barColor:'#1179a0',
extendEdges:[Ti.UI.EXTEND_EDGE_TOP],
includeOpaqueBars:false
});
login.js – tableView
table = Ti.UI.createTableView({
width:320,
separatorColor:'#ddd',
style:Ti.UI.iPhone.TableViewStyle.GROUPED,
backgroundColor:'transparent',
editable:false,
footerView:forgot
});
This is definitely a bug that needs to be resolved quickly. I don't want to just simply move my table down because I want to have that nice blurred effect beneath the navbar as you are scrolling.
{color:red}
Now what I've noticed is that if you don't add any custom objects to the table rows, the issue is no longer present. In my application, I've added the two TextFields to the table rows. If I remove them and just have two empty table rows, I get the following... See second attachment.
{color}
Attachments
File | Date | Size |
---|---|---|
IMG_2400.PNG | 2013-12-25T02:18:33.000+0000 | 87265 |
IMG_2401.PNG | 2013-12-25T02:18:33.000+0000 | 29598 |
We have not been able to run the provided test case as it is not complete. For example, LoginUser is not defined in login.js, forgot is undefined in login.js, etc. Please provide a simple but complete test case to demonstrate this problem.
Sorry about that. Here are the essentials of my login.js file:
If you uncomment the
you'll see that the table shoots up underneath the navbar.
After some more testing, the issue looks to be when I focus on the user field. Uncomment the section where I added the fields to the rows. Now comment out the mainWin focus function. You'll see that the rows are displayed correctly in the view. Now click on a field to bring up the keyboard. This causes the table to shoot upwards and does not return to normal.
Moving the ticket to engineering for further evaluation and prioritization as we have been able to reproduce the issue with the sample provided.
Is there any estimate on how long it will take to resolve this issue? This is the only thing that has me set back from releasing my application.
We have the property
autoAdjustScrollViewInsets
that handles the adjustment automatically. By default, it is set to false which is different to the native behavior. So the fix is to set[controller setAutomaticallyAdjustsScrollViewInsets:[self boolValue:autoAdjust def:YES]];
or use the workaround to just specify the above property and set it totrue
. I guess this was an outdated issue, since the following does work:Anyway, we should fix the default value