Direct app exec#38
Direct app exec#38CMTaylor wants to merge 8 commits intoTestingWithFrank:masterfrom CMTaylor:Direct_App_Exec
Conversation
Bug-fix: Fall back to orientation via status-bar when orientation via de...
Allowing UIAlertViews be queryable in iOS7.
…nerate Pull request.
There was a problem hiding this comment.
I'm not really happy with this approach. Feels pretty hacky to hard-code intimate knowledge about that specific command in the path routing code.
Is there a way we can instead have the DirectAppExecCommand run its command in its own thread? That seems like it'd achieve the same goals.
|
It sounds like DirectAppExecCommand is a total copy-and-paste of AppCommand. In that case why not just use AppCommand? |
|
As I say in the code comments for DirectAppExecCommand: There are certain situations in my app where executing a command on the main UI thread can cause a thread deadlock. In these situations I need to execute the command on “some other thread”, and the HTTP thread seemed easy and convenient. If you don’t think others need this kind of functionality, then you can skip this pull request. I’ve just been trying to get ALL my Frank modifications pushed into the main project on GitHub. Thanks, From: Pete Hodgson [mailto:notifications@github.com] It sounds like DirectAppExecCommand is a total copy-and-paste of AppCommand. In that case why not just use AppCommand? — |
|
What I was getting at is if it's the same implementation, why not just ditch Either way, I'm not really happy with the hard-coding in |
The DirectAppExec command was copied directly from AppCommand.m. The only difference in this command is that the RequestRouter.m executes it on the HTTP thread rather than on the main UI thread. This is required in my application because running some commands on the UI thread can cause deadlocks.