Backgrounder vs. Build and Run

Here’s a quick note on how Backgrounder, from the wonderful http://twitter.com/ashikase interacts with Xcode’s Build and Run functionality.

First, Backgrounder: The MobileSubstrate extension manages background persistance for apps both supporting iOS4’s native switching as well as apps that require additional assistance. One of the options in Backgrounder is to “enable at launch,” which means exactly what you’d think: apps get backgrounding enabled as soon as they’re launched, and one must explicitly disable the function if desired. That’s the setup I have: If it’s got Native functionality built in, let it background, and tell it so when it launches.

But now we need to discuss how that happens. Backgrounder is implemented in-app as a .dylib extension. That extension constitutes code loaded into the app at runtime, in this case code which handles persistence after minimize. In order for that code to activate, something needs to tell it it should, and Backgrounder handles that message by sending a SIGUSR1 signal to the running app process whenever backgrounding is to be enabled. Keep in mind that could be by an activator gesture or some such. In my case, the problem is that the SIGUSR1 signal gets sent to the app as soon as it loads, and GDB catches it. Maybe you caught on, and maybe you’re a dolt like me and it took you some hand holding, but you can get over this hump by simply clicking “continue” in the top right of the console window. This will dismiss the SIGUSR1 and the app will continue to execute as normal.

Your other option, if you’re getting annoyed by always clicking continue, is to add an override for your app to disable Backgrounder. That will prevent SIGUSR1 from ever being sent and hiccuping your debugging. Though it’s probably only worth the annoyance if you’re recompiling constantly. And in addition, you’ll have to re-override the project any time the name changes.

At any rate, hopefully that clears up any problems you might run into with this.