Hi,
Thanks for waiting. The minor issue in the test app is that it has a slightly idiosyncratic accessor style by providing itself to the hosting class as a non-singleton class method that initializes other multithreaded or thread-conscious and persistence-needing objects inside of that class method by invoking their inits inside the class init method, and then returns.
This started working for me when I made it a little more boring by removing the class method, made the wrapper class a property of the hosting class, instantiated it with the standard init in that class, and then did all of the setup in a separate method on the already-instantiated object.
So I ultimately had no “+” method, used the default init, and had a method where I put all the setup that used to be in the class method, called:
– (void) setupWithWordsArray:(NSArray *)_words filename:(NSString *)_filename;
That got called by the wrapper object (as a class property of the hosting class) once it was instantiated.
Without more time to look into it, I don’t know if the fundamental issue is multithreading related, something with ARC optimization, or just that the observer delegate needs the observing object to have returned from its initialization. I did not continue to troubleshoot how the delegate of the wrapper functioned since I had to stop after the OpenEarsEventsObserver started working, so I don’t know if those are working or not. Let me know if this helps or if you need more details. It’s also a good idea to put all the OpenEars code into your root view controller rather than the app delegate since it is business code. You can still instantiate OpenEarsEventsObservers wherever you need them, so this won’t pin you down to a single view controller.
-Halle