iOS UITableView didSelectRowAtIndex, trigger segue delay bug

[1458279]

Ok, so the exact line with the delay is the call to the segue?

I haven't done a segue programmatically, but it looks like it might not work:
http://stackoverflow.com/questions/9674685/creating-a-segue-programmatically

However, here's another post that seems to say different:
http://stackoverflow.com/questions/...y-and-pass-parameters-to-the-destination-view

Is there a reason you call the segue instead of just calling the view?

I really don't much about segues, but it might be a storyboard thing only.

You might want to look into settings of the segue, my understanding is that everything could be done in code.

Again, this assumes that you found the segue to be the point of delay. The easy test is to call the view direct without a segue.

Edit: From Apple: "However, a segue can also be triggered programmatically by your app, as long as the segue has an assigned identifier."

https://developer.apple.com/library...on/UsingViewControllersinYourApplication.html

Solution: call the view direct without a segue, then if that solves the problem, look at the settings of the segue.

 

[DennisBlah]

Hi Karl,

I have to do it programaticly as I'm using dynamic tableviews.
Indeed I just tested with a test button on top of my layout and use the UI for the transition and it works directly.
So I'm guessing it's or the way of triggering the segue is not quite right, or that there is something with uitableview in iOS8.3 ?

I will play around with a few codes for triggering transitions and update the topic
At first I did it like this, calling the next view using transition.

UIStoryboard *mainStoryboard = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
UIViewController *nextView = [mainStoryboard instantiateViewControllerWithIdentifier: @"mainView"];
nextView.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;
[self presentViewController: nextView animated:YES completion:nil];

Now I made segue's from all viewcontrollers to eachother with their own identifier, and call the segue by identifier

[self performSegueWithIdentifier: nextViewSegue sender: self];

Triggering the performSegue from a static button, the app goes through straight away, but by the didSelectRowAtIndexPath it's waiting for something thats not there! :-/

It's really giving me a headache as I'm having this issue for 2 weeks or so.
Ofcourse I went on with the project as it's should just be a bug somewhere

Found a simulair topic on stackoverflow, mentioning to use sender: nil for performSegueWithIdentifief, so that the tableview itself wont be included.

Ofcourse I did that straight away, but still having the same issue..

After playing around with settings of the segue, I found out that when I use the default segue 'Present Modally' and presentation as 'Full Screen' instead of 'Default' it looks like this is solved.

But after 2 times, the issue is back.

p.s. updating to 10.10.4 and updating xcode at the moment.

 

[DennisBlah]

Read this about where the CODE tag can be found.
https://forums.macrumors.com/threads/posting-code-please-use-the-code-tags.747660/

That link is a sticky at the top of this forum.

How to change title of my topic these days ?
I want to change the title that's more pointing to the exact issue, so maybe someone is known with the issue.
----
oops, found it, please remove this reply

 

[1458279]

Ok, so if you call the segue from a button, it works perfectly, if you call the SAME segue from the didSelectRowAtIndexPath, you get the delay?

Are you setting the segue the same way in the button call vs the didSelectRowAtIndexPath call?

Are there any global/project setting the control the segue?

One trick I do is to list out all the settings of an object. IIRC, NSLog("Object %@",Object); shows the whole object, if not, you can get a list from the documentation of all the object attributes and list them out.

The debugger can do this, but I find it easier to read when you do the NSLog.

 

[DennisBlah]

Ok, so if you call the segue from a button, it works perfectly, if you call the SAME segue from the didSelectRowAtIndexPath, you get the delay?

Are you setting the segue the same way in the button call vs the didSelectRowAtIndexPath call?

Are there any global/project setting the control the segue?

One trick I do is to list out all the settings of an object. IIRC, NSLog("Object %@",Object); shows the whole object, if not, you can get a list from the documentation of all the object attributes and list them out.

The debugger can do this, but I find it easier to read when you do the NSLog.

Hi Karl,

since iOS8 it seems to be a bug in the tableViewDidSelectRow function.
Calling segues from this function's thread queue will cause a delay.

By forcing the segue to be triggered in the main queue will sove the issue:

dispatch_async(dispatch_get_main_queue(), ^{
  [self performSegueWithIdentifier: @"mySegueIdentifier" sender: nil];
});

I'm glad this is solved. Then I can finally roll-out the app.

Thanks for your help and support !

 

[1458279]

Can you post a link to where you got this answer, it'll help others that run into the same problem.

Is this bug just for segue calls or other calls too? Maybe the link where you found the answer will give some insight.

 

[DennisBlah]

Can you post a link to where you got this answer, it'll help others that run into the same problem.

Is this bug just for segue calls or other calls too? Maybe the link where you found the answer will give some insight.

As far as it's discussed in this topic it was only about segue's, but in my case it started with transitions, so I think there is something in the code behind the transition from one view to another.

http://stackoverflow.com/questions/...ard-segue-is-slow-double-tapping-works-though

 

[1458279]

That's interesting, I just read about a week ago about how all UI must be on the main thread and that code puts it on the main thread.
Sounds like the OS or compiler is trying to put it on a new thread.

The debugger should be able to confirm this, do you see it running on a different thread?

In fact, I wonder if you can find out programmatically what's running on what thread, maybe something along the lines of load balancing.

 

[PhoneyDeveloper]

One commenter on that SO thread says this delay only happens if the row has selection turned off. @DennisBlah is that the case with your app?

I have to do it programaticly as I'm using dynamic tableviews.

BTW, this is probably not correct. You can have segues on your cells in a dynamic tableview. (But the commenters on SO said it didn't make a difference for this delay if the performSegue happens in the storyboard or in code.)

 

[DennisBlah]

One commenter on that SO thread says this delay only happens if the row has selection turned off. @DennisBlah is that the case with your app?



BTW, this is probably not correct. You can have segues on your cells in a dynamic tableview. (But the commenters on SO said it didn't make a difference for this delay if the performSegue happens in the storyboard or in code.)

Hi Phoney, great to hear from you again!

I did not turn off selection in the gui
But set selection style for the cells off. I thought if I turn it off I cant fet into didSelectRowAtIndex
(Never tried tho)


These 2 views are actually juat copied from my last viewcontroller (where i started with for the project ((yes id like to work from desired result to how to get there ))

Not all of my tables have this code in.

Btw how do I put segues in ui on dynamic cells which have different segues based on section and certain content of the cell?
You got my attention there

Again, the less code, the happier I get

 

[PhoneyDeveloper]

Imagine I have a table that displays fruits and vegetables. There are two kinds of cells, fruitCell and vegetableCell. The fruitCell, when tapped, pushes a fruitDetailViewController and the vegetableCell, when tapped, pushes a vegetableDetailViewController. In the storyboard are the two kinds of cells as prototype cells. Each one has the appropriate segue attached to it. In cellForRowAtIndexPath the code dequeues the appropriate cell type based on what is to be displayed in that row. When the user taps on that cell the segue for that row will push/show the appropriate detail view controller. The code will also implement prepareForSegue to check the segueIdentifier and setup the view controller with whatever data is required.

The view controller code doesn't have to implement didSelectRowAtIndexPath and doesn't have to manually call performSegue.