Using Juce with cocoa app

MacOSX and iOS
1

Hi,

I am testing if it is possible to use the non-gui classes of JUCE within a standard iphone app that uses cocoa for its user interface. I created a view based application and added initialiseJuce_GUI(); to the app delegates

  • (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
    method.

To properly shutdown juce when the app quits I added shutdownJuce_GUI(); to the app delegates

  • (void)applicationWillTerminate:(UIApplication *)application
    method.

When I quit the simulator I get the following assertion:

*** Leaked objects detected: 1 instance(s) of class HeapBlock
JUCE Assertion failure in /Users/patrick/Documents/development/libs/juce/Builds/iOS/…/…/src/native/mac/…/…/core/…/memory/juce_LeakedObjectDetector.h, line 95

Did I miss somenthing? Do I need to release something else to properly shutdown an application that uses Juce?

Patrick

2

Not sure how you’d manage to leak a HeapBlock… It’s perhaps part of a larger structure that you’re leaking?

3

Sure. I would also except a problem in my code normally. But for this test I am not making any calls to Juce except initialiseJuce_GUI() and shutdownJuce_GUI(). Just starting, then stopping the app triggers the assertion.

Patrick

4

Well, nothing in the library will allocate a HeapBlocks on the heap, or create a static one, so I’ve no idea how that could happen. Surely there must be more leaks than just the one, because the HeapBlock must be a member of something else?

5

Not creating an AudioDeviceManager, are you? Do you have any static members which juce may be creating for you?

Bruce

6

“Quit the simulator” or press the home button on the simulator?

Put a breakpoint on applicationWillTerminate:

(I ran into something like this last year, and I remember quitting the simulator being different than hitting the home button[quitting didn’t call app terminate])

7

Put a breakpoint on applicationWillTerminate:

yup, the breakpoint it is never hit, not with the home button and not with quitting the simulator. It seems task management is not deterministic.

My final test was to let Introjucer generate a default project, using static linking. After compiling, starting the app from Xcode and quitting the simulator the same assertion is triggered.

I am working on Lion, using Xcode 4.1.

Well, if the way I am initializing and shutting down Juce is correct and this assertion is not a sign of a fundamental problem I’m happy to simply press the “Stop debugging” button in Xcode instead of quitting the simulator to get around that assertion.

Patrick

8

TBH I wouldn’t worry too much about the “leak”, as it’s probably just a HeapBlock inside a static object somewhere. The leak detector can report false positives sometimes, when you have static objects that get deleted after the leak-detector’s own statics. I’ll have a look at it next time I’m doing some ios stuff anyway.