[TIMOB-666] iOS: SectionIndexTitle in TableView overlaps the SearchBar

GitHub Issuen/a
ResolutionWon't Fix
Resolution Date2014-01-10T20:27:52.000+0000
Affected Version/sRelease 1.5.0, Release 2.1.4, Release 3.0.0, Release 3.0.2
Fix Version/s2014 Sprint 01, 2014 Sprint 01 API
ReporterChristian Sigl
AssigneeVishal Duggal


The vertical list used to quickly jump to tableview-entries is overlapping the searchbar and headers. there should be a possibility to set the font-size of the index letters/numbers or dynamically calculated


Screen Shot 2012-07-25 at 1.58.12 PM.png2012-07-25T13:59:11.000+0000176517
Screen Shot 2012-07-25 at 1.58.22 PM.png2012-07-25T13:59:11.000+0000150579


  1. Stephen Tramer 2011-04-15

    Possibly invalid; see http://stackoverflow.com/questions/2616860/uitableview-section-index-overlaps-search-bar"> http://stackoverflow.com/questions/2616860/uitableview-section-inde... for a possible solution. But this is how Contacts looks, so it should be considered acceptable (and may even violate HIG to NOT have it look this way...)

  2. Vikramjeet Singh 2011-07-28 Bug Scrub: Valid. Test Case may be created by modifying 'table_view_headers_filter.js' in KitchenSink
  3. Blain Hamon 2012-07-25 Comparing contacts with Kitchen Sink
  4. Blain Hamon 2012-07-25 As of 2.1 or previous, the table search does the correct behavior, akin to Apple's own contacts app. That is, to provide a right margin in the search field. Marking ticket as fixed.
  5. Federico Casali 2013-01-17 Reopening. TiSDK 3.0.2.v20130117100201 (NOT reproducible using 3.1.X latest master) When the window is displaying a title bar (like when is placed inside a Navigation Group or just by setting 'modal' property to 'true') the search bar is displayed correctly. However, if no title bar is displayed, the search bar is displayed below the index letters when first opening the window. As soon as the Table View is touched/scrolled, the search bar it's being resized and displayed correctly. Sample case isolated from Kitchen Sink:
       var win = Ti.UI.createWindow({
       	title:'Test win',
       	// modal:true   // setting to true and displaying the Tile Bar, the Search Bar is correctly displayed
       	// create table view data object
       	var data = [
       		{title:'Alan (click to change index)', hasChild:true, header:'A'},
       		{title:'Alice', hasDetail:true},
       		{title:'Brad', header:'B'},
       		{title:'Callie', header:'C'},
       		{title:'Don', header:'D'},
       		{title:'Erin', header:'E'},
       		{title:'Frank', header:'F'},
       		{title:'George', header:'G'},
       		{title:'Herbert', header:'H'},
       		{title:'Ignatius', header:'I'},
       		{title:'Dr. J', header:'J'},
       		{title:'Kristy', header:'K'},
       		{title:'Krusty the Clown'},
       		{title:'Larry', header:'L'},
       		{title:'Mary', header:'M'},
       		{title:'Ned', header:'N'},
       		{title:'Nervous Eddie'},
       		{title:'The Big O', header:'O'},
       		{title:'Pluto', header:'P'},
       	var search = Titanium.UI.createSearchBar();
       	// create table view
       	var tableview = Titanium.UI.createTableView({
       	// create table view event listener
       	tableview.addEventListener('click', function(e)
       		if (e.index === 0){
       			tableview.index = index2;
       		// event data
       		var index = e.index;
       		var section = e.section;
       		var row = e.row;
       		var rowdata = e.rowData;
       		Titanium.UI.createAlertDialog({title:'Table View',message:'row ' + row + ' index ' + index + ' section ' + section  + ' row data ' + rowdata}).show();
       	// set filters
       	var index = [
       		{title:'P',index:(data.length -1)}
       	tableview.index = index;
       	var index2 = [
       	{title:'PP',index:(data.length -1)}
       	// add table view to the window
  6. Craig Jones 2013-09-20 Just to add, SDK 3.1.3.GA targeting iOS7 gives the same issue (pretty much using the same code above). If you view 'Contacts' on iOS7 the index is set beneath the search bar. In Ti, it's overlapped. Contacts: !http://www.hardbyte.com/uploaded/images/ios7_contacts_index_searchbar_contacts_list.jpg! Ti App: !http://www.hardbyte.com/uploaded/images/ios7_index_overlaps_searchbar.jpg!
  7. Martijn Kooij 2013-09-29 Is there any update on this issue? It looks quite hideous now, enough for me to hold back my iOS7 update... A temporary workaround would be fine as well for now.
  8. Martijn Kooij 2013-10-03 Is this perhaps related as well? (If not I will open a new ticket). The delete button (either by swiping, or after pressing the delete button when the tableview.editing = true) is rendered behind the tableview index. See images !http://oi40.tinypic.com/dws9dd.jpg! !http://oi44.tinypic.com/2hnriah.jpg!
  9. Martijn Kooij 2013-10-07
  10. Ingo Muschenetz 2013-10-10 The proper fix for this issue is to use the SearchText API in ListView. We may update TableView to support this API in the future, but I do not have a current ETA for that change.
  11. Martijn Kooij 2013-10-10 I have only done brief research before and I remember not being able to convert my tableviews to listviews. But I will look into it again now... You say "the proper fix", can you perhaps help out with a non proper fix? I already tried resizing the TiUISearchbar in frameSizeChanged, but that somehow reverts back at some point (and it does not fix the delete buttons being behond the index TC-3106). Are there any hints at to where I could search, is it a layer z-ordering thing, or more a margin/positioning thing? According to Federico Casali this did not occur on modal windows, what's the difference there? EDIT: The bug is also visible in modal/navBarHidden unfortunately...
  12. Martijn Kooij 2013-10-10 Looking into listView, but listview does not even support search nor index yet... Am I overreacting, or are these just 2 ugly bugs (TIMOB-666, TC-3106) that need fixing? Is there anyone that finds this UI acceptable? Please help, I don't mind doing the work in the SDK myself as a temp fix, I just can't even find what could possibly cause the issue .
  13. Craig Jones 2013-10-10 Can we search and swipe to delete on ListView yet? I think that's why I'm still using TableView...
  14. Ingo Muschenetz 2013-10-15 [~hardbyte] Those features have been added in 3.2.0
  15. Martijn Kooij 2013-10-16 3.3.0 and medium. So that is somewhere around, never? Thanks for caring...
  16. Ingo Muschenetz 2013-10-16 [~martijnkooij] As I mentioned to Craig, those missing features have been added to ListView in 3.2.0, and should already be available in the CI builds. We are encouraging all users to migrate to ListView instead, and if there is a reason you still can't based on 3.2.0, we would like to know that ASAP so we can correct it.
  17. Martijn Kooij 2013-10-16 Since there's no documentation yet it's kind of hard to figure out what is supposed to replace what based on browsing the objective c code... I am not really looking forward to rewriting a lot of my app (especially not 1 month after the date I wanted to update...), but if I have to please advise. What I need and cannot find (pseudo code of what I currently use on my tableViews): 1. tableView.search = Ti.UI.createSearchBar(); 2. tableView.filterAttribute = 'nameOfAttributeOnTableViewRow'; 3. tableView.deleteButtonTitle = 'Delete'; 4. tableView.searchHidden = searchInitiallyHidden; 5. tableView.style = Ti.UI.iPhone.TableViewStyle.GROUPED; 6. tableView.scrollsToTop = searchInitiallyHidden; 7. tableView.index = [{title: '{search}'},{title: 'MyIndex 1'},{title: 'MyIndex 2'}]; //I got the magnifier icon working by modifying sectionForSectionIndexTitle in TiUITableView.m, would like to keep that in listView as well. 8. tableView.allowsSelectionDuringEditing = true; 9. tableVIew.moving = true; I think those are the 9 main parts which I require other that data/images/labels which I have already figured out. If you could name the new properties/methods for me I am willing to give it a try. Please also note TC-3106 which I still think is related and which is not "just" a visual bug but affecting a basic functionality. ps. The current master build includes a bugged version of wrench.js, took me 30 minutes again to figure out the cause and fix it... That's why I prefer not to use nightlies... And now you're asking me to make a release with a nightly...
  18. Matthew Delmarter 2013-10-21 I would like to see this fixed properly in 3.1.X. There is no point talking about ListView all the time, as using searchbars and indexes are extremely basic requirements for most apps, and ListView does not support them in any current 3.X that we can use *today* to build and submit apps to the App Store. TableView does - and so it would be nice to see this bug fixed in 3.1.X - especially as this is the last version of the SDK that also still supports iOS 5.X. SDK 3.2.0 requires iOS 6+ which is no small thing for my user base.
  19. Matthew Delmarter 2013-10-21 Further to this - if I am to switch to using ListView, is there a rough eta on when 3.2.0 is going to be ready? If it is within the next couple of weeks then I can probably start moving across to ListView and using the 3.2.0 CI builds, otherwise I will have to stick with 3.1.3 and TableView...
  20. Ingo Muschenetz 2013-10-21 [~mdelmarter] The current ETA for 3.2.0 is in early December. We are unlikely to have another 3.1.X GA release, though we may push fixes onto the 3.1.X CI branch where you could pick up a build from there. I will work on giving a better answer in the short term for 3.1.X + TableView.
  21. Matthew Delmarter 2013-10-21 That would really be appreciated Ingo.
  22. Martijn Kooij 2013-10-25 Any news on this? Either news or explanations on how to completely convert my tableviews to listviews.
  23. Martijn Kooij 2013-11-01 Still not able to release my app for iOS7...
  24. Martijn Kooij 2013-11-18 Another ~3 weeks have passed and still no "better answer in the short term for 3.1.X + TableView", nor an answer to my questions on how to port my code to the 3.2.0 listview. Help?
  25. Martijn Kooij 2013-12-03 Any news? There is barely any visible git activity in tableview nor listview. And we also have not heard any answer on how to work around this using listview.
  26. Darren Haligas 2013-12-04 I agree we need a workaround on this. It looks sloppy in the apps and should not be ignored.
  27. Craig Jones 2014-01-09
  28. Darren Haligas 2014-01-09 The issue here is the SearchBar is added to the header of the tableView which is why the overlapping is happening. If you look at the contacts app in the iPhone you will notice the search bar is fixed at the top and not connected to the tableview thus the index bar doesn't overlap. One workaround is to do the following: - Use a ListView - Place the SearchBar above the ListView - Use the SearchBar onChange event new value to set the ListView.searchText field.
  29. Craig Jones 2014-01-09
  30. Vishal Duggal 2014-01-10 This has been a known issue on the titanium platform for a while. As [~dhaligas] correctly noted above, the problem is that the searchbar is part of the tableView in Titanium, whereas the contacts app (which the functionality is most compared to) has the searchbar outside the table view. Hence titanium will always have the problem of the section index titles overlapping the search bar. There is no easy way to fix this in the Ti.UI.TableView implementation on iOS. With these limitations in mind ListView introduced the searchText API (used in conjunction with searchableText property on the ListItem), which is a more generic API. There are several advantages to this API over the search API in TableView 1. It disengages the searchable property from the title property of the data set 2. It disengages the input to the search function from the searchBar 3. It gives the developer more control as to when the search is actually performed (The search API on tableView will redo the search on every character change which could be expensive and slow on extremely large data sets) 4. It keeps the style of the table view intact (Ti.UI.TableView will always revert to plain table view for search results) 5. With keepSectionsInSearch property set to true on iOS, ListView will automatically filter the indices based on the search parameter and also show relevant section information Not everything is rosy. There are a couple of drawbacks 1. There is no semi transparent overlay on the tableView when the search first begins like the Search API in tableView (This of course can be faked with some clever programming in titanium) 2. There is no way to indicate that the search had no results (Neither an API endpoint for the developer, nor a "No Results" UI equivalent for the consumer). We are aware of this and are working on a solution. If you prefer the old search functionality, the "search" property on Ti.UI.TableView has been exposed as the "searchView" property on Ti.UI.ListView so you should be able to migrate code to a ListView (though it suffers from the same limitations as the TableView API). The "searchHidden" property from Ti.UI.TableView has been consciously dropped. Going to mark this ticket as Wont Fix.
  31. Lee Morris 2017-03-22 Closing ticket as "Won't Fix".

JSON Source