This is really putting the knife in my project.
As far as I understand it, the IGGridViewDelegate methods gridView:willSelectCellAtPath: and gridView:didSelectCellAtPath: don't need any special code from the programmer to get them working. Simply add them to your project's .m file and fill in the logic. When the project is run, the grid will call them if they are implemented.
Well, as my video demonstrates, this is not the case for me.
The grid does not call either of these methods for the bottom row cells.
You can see my demo on my google drive here...
https://drive.google.com/open?id=1hb6t-mm5rxkaLEmZmYbSihhPAjVO3SPg
Unfortunately I can't conveniently package up this functionality into a project because the project is very large and many files are involved in getting this on screen.
Hi,
Hi Stephen,
(1) No, there are no invisible views, however, I am using your tab view that slides on and off screen and can be repositioned on any side of the screen. You can see the light blue tab of the collapsed slide tab view in the video.
(2) the grid height varies on what data is being displayed. In cases where the grid extends beyond the bottom of the screen, the row that's present at the bottom when tapped will no respond to taps, but if you scroll it upwards away from the bottom of the screen, it does become tappable.
(3) The "city" cell is the bottommost row in the grid. When I pull up on the grid to expose the white area below the "city" cell, that is just the view I'm placing the gridview on.
Regarding the nil'ness of the cell, all the cells are produced through the same cellAt: method, and whether there is data or not, merely depends on what was read from my data structure into the cell.textLabel.text
In all cases, I am producing a cell and placing it in the gridview.
Would the view that the grid is placed on be considered "invisible" per your first question?
I'm assuming not, because you probably mean views that sit in FRONT of the grid view, not behind it.
Thanks
Dave.
Hi Torrey,
No, I don't have anything in gridView:willSelectCellAtPath: that could potentially return nil and prevent the cell from being selected.
I am going to play with your project and see if I can get it closer to what I'm doing because technically my app works a little differently. I don't have the gridview taking up the whole screen as a content view, rather the grid comes and goes as a portion of the screen to show data based on what icons a user taps on.
Also, I don't use a grid datasource helper. I have my own data and the grid gets built using the cellAt: method.
Hopefully by building up your example, I can discover what's causing the problem.
I'll keep you posted on my progress, and reupload a modified version if I run into the issue but can't diagnose it.
I ended up putting together a sample that tests the methods mentioned in your original post and didn't have any issue. Take a look and edit it to see if you can reproduce the issue from your main project.
SlideTabGrid_ObjC.zip
Do you by chance have any logic in your gridView:willSelectCellAtPath: that could potentially return nil and therefore prevent the cell from being selected?
I've been using the SlideTabView for about 9+ months now and it hasn't caused any issues I'm aware of until this unique scenario. I made a video showing the SlidTabView control in my app, and rotated it in Reveal so you can see how things line up and what's what. You can also see that order that controls are overlapping. The IGGridView is overlapped by the tab on the IGSlideTabView. I did try sliding the tab over to the left (not in the video), so it's not directly over the gridview, but that didn't make the cell tappable either.
As best I can tell, a row's cells won't become tappable until the bottom of the row is around 15 pixels above the bottom edge of the screen. Any closer and the cell doesn't respond to taps.
I put the video in the folder I linked to in my initial post above, and titled it "Slide Tab Control"
I also added a pic of the code that I'm using. The code to build / show / hide is all there.
Take a look and see if it looks correct, or if you notice anything odd.
Hi Dave,
Steve is off today and I wanted to jump in and learn how you've used the IGSlideTabView to determine if there's an issue. We had a case in the past where a user wasn't adding views to the slide tab's contentAreaView which in turn caused interaction issues. The IGSlideTabView is meant to be used like a container and views should be added to the contentAreaView. This is to help manage padding and view placement.
Does your implementation follow this pattern? If you need a quick sample demonstrating usage, I'd be happy to make one for you.
Stephen,
I haven't quite gone far enough to prove it yet, but I'm REALLY suspicious of the slide tab control.
I added an extra bogus row at the end of my IGGridView so that I could scroll up further.
I colored it black, so that's the black strip you see below the yellow box.
Notice in this screen composite I put together, in the first position I show, the yellow box is NOT tappable.
However, if I scroll up just a tiny bit more, as shown in the bottom portion of my composite, the yellow box does become tappable, and presents the popover.
Reveal shows nothing else in front of the IGGridView in the Z-order, other than the slide tab view.