Using IGGridView from 2014.2.146
I have not tried this on an actual device yet, only the simulator as pictured.
Very simple datasource and delegate.
I don't know if I have a setting incorrect or something, but I've noticed that the delay (de-selecting the existing row, removing it's cell color, then selecting the clicked row, and highlighting it's cell color) is soooo long when clicking from one row to the next, it borders on making you wonder if you actually clicked it or not. I have not changed any default settings I know of that would cause this, and I'm on a spanking new Mac Pro 15" with a 1 TB SSD, so I hardly think it's my computer. Is there any way to speed this behavior up, so that clicking a row immediately selects it and highights the cell.
I've tried setting the DataSourceHelper.editingTransitionDuration = 0 and that has no noticable affect, so I don't know why this would be so slow.
I've tried time profiling it and that didn't seem to reveal anything useful either.
Users are going to find this behavior really offputting if this can't be changed.
Thanks.
Hi David,
So, selection is only .3 seconds. It's not configurable, but it sounds like something is definitely wrong. If you grab our samples browser from the app store, you can see what its actually supposed to be like. (Side note, the samples browser also gets installed with the product).
Also, the editingTranstionDuration, is for editing only. The IGGridView does have a transitionDuration property, but that for reordering, adding and deleting cells ,rows and columns.
It's hard to say exactly whats happening though without any code.
I've attached a simple sample for now that shows it working properly. Can you verify that its working for you?
Thanks,
-SteveZ
Your code sample is noticably faster than mine.
Perhaps it's something I overrode.
Maybe this... ???
- (void)gridView:(IGGridView *)gridView didSelectCellAtPath:(IGCellPath *)path
{
IGGridViewCell *theCell = [gridView cellAtPath:path];
if (path.columnIndex == 0)
theCell.backgroundColor = [UIColor greenColor];
}
Could I submit my play project for you to take a look at ?
There's only a gridview, and about 3 classes in 6 files.
If so, would I just attach it here, or send it another way.
Yea if you have a project that reproduces it, that'd be really helpful
You can attach it here, just select the options tab at the top to attach a file to the reply
Thanks
Ok, here it is.
Thanks for the sample,
Looks like its related to allowEditing on the DSH. I'm guessing it has to do with the fact that with editing we hook a double tap gesture to the cell, which means the selection tap has to wait and see if it fails. We're using the UIGesture's requireGestureRecognizerToFail selector, which probably has an inherent delay. It actually wouldn't have anything to do with the animation.
I'll take a look into it in the morning and see if there is anything we can do, it certainly should avoid that gesture if the column has editing disabled though.
Btw, i noticed that you're re-declaring the delegate and datasource methods in the internal interface of your class. You know you don't need to do that right?
Cool, thanks for the superfast response.
I'll take a look at it after a meeting.
Dave
Hey Dave,
So, i simplified your code a bit and add some extra logic for you.
It looks like you'll want to transpose your data. And with just a little tweak to the DataSourceHelper, you can do that, without having to change your data.
So i created a custom DSH for you, and i grouped it by a property on the data object called row, so that it will repeat automatically.
Then i hooked into the delegate, so that when you tap on a data cell, it will show an alert. In that method, you can see how you can resolve the actual value clicked through the DSH.
Hope this helps,
We're making an app that's similar to the picture below.
The fields and data are fake, but representative of what we're doing.
We're working on an iOS version of an app that's going to mimic a .NET app for the PC desktop.
For the iOS version, to reduce input errors, and validation requirements, we are going to use a lot of combo box style lookups (pickers for iOS), and of course date pickers for dates, etc.
The usage scenario is that a user would tap on a cell in the 2nd column of the gridview, and then the code would determine whether the tapped cell is allowed to be edited, and if so, based on the datatype, a popover would display containing a date picker, combo box, or whatever as needed to enter the data quickly and accurately. For numerical value fields, I'd display a numeric keyboard (I think iOS already provides that option, but I need to figure it out).
So if I were to use popovers for all the 2nd column cells that were editable (as not all of them would be), could I then disable all columns for editing and use my popovers to enter the data, thereby getting around the double-tap gesture?
I know how to make and display popovers, but any grid view code you want to provide in this regard would of course be helpful.
Dave.
Welcome to the iOS world! I actually came from a .Net background myself. In fact i've written a few blog posts about transitioning form C# to Obj-c. Perhaps it could help you get up to speed a bit quicker:
http://es.infragistics.com/community/blogs/stevez/archive/2013/05/09/c-to-objective-c-the-ultimate-guide.aspx
There are also a bunch of post about general tips on working on the platform:
http://es.infragistics.com/community/blogs/stevez/default.aspx
In terms of providing your own editing, you can basically do whatever you'd like with the IGGridView. Its extremely flexible. The IGGridViewDataSourceHelper, is actually just an object that implements the IGGridViewDataSource protocol. This is why editing is enabled through the DSH, and not the IGGridView. Using the DSH has a lot of advantages, and one of them is that you can create custom IGGridViewColumnDefintion objects or you can even specify your own custom cell. So if you want a specific column to always have an editor displayed, you can do exactly that.
If you have an idea of how you want it to work, i can probably whip you up a sample to get you started.
Ahhh, the double-tap gesture... yep, that's it.
You can verify that in the project I gave ya.
I actually have the first column disabled for edits (because those are the field names).
It's the second column that's enabled for editing.
It would be great if there was a way to remove the double-tap gesture... or perhaps to disable the column for editing, but then edit anyway through another means, like providing my own editor or something. If you have any ideas along these lines, let me know.
Regarding "Btw, i noticed that you're re-declaring the delegate and datasource methods in the internal interface of your class. You know you don't need to do that right?"
Heh, you'd be shocked at how much I don't know.
Just writing a line of code can take hours sometimes.
I've been a .NET programmer for the last decade and was recently forced into iOS programming through no fault of my own.
While I have been interested in learning it, it's a massive wall to climb. XCode, iOS, LLDB, Objective-C, Cocoa Touch, third party libraries...
Hopefully I'll scale it in the next few years.
That's the nature of the work though. I'd still rather do this than just about anything else.