-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash occurs when using existing assembly as a protocol conformer for another assembly #298
Comments
What you would like to do should work if done correctly. Can you show how you are a) instantisting the assembly b)using it to resolve components. Better still would be a project that shows the problem. Can you also confirm that you have not duplicated any methods across two assemblies? |
Hi Jasper, thanks for your quick response. There are auto-injected properties with the same names in both the working and non-working version, but the methods are all distinct. The methods are declared both in the protocol and in the comforming class, of course. The original merged class had no designated initializer, it was entirely auto-injected. The class it subsumed did have an initializer which I moved into the merged class and called it through the protocol interface. My client is reluctant to share much of their architecture in a public setting, and it has many methods. I am currently removing the protocol entirely and merging the two classes to see if the problem is in our code. I'll keep you posted. |
Quick update - it doesn't appear to have anything to do with protocols. I merged the two classes together and the problem occurs. I'll update when we have more information. Thanks. |
Hi, Happy new year! Here's an update: I am merging two assemblies. One is a set of convenience classes that call factory methods in the second assembly. When combined into one assembly the app crashes in the definition builder during initialization. During initialization the convenience class is invoked. When the convenience class calls the factory class, the factory class will occasionally return a Typhoon Definition class object rather than the view controller it is supposed to return. Since there are many of these, the app will crash consistently but in different view controller convenience classes each run. Is there something inherently wrong in combining assemblies in this way? Is this an order of initialization problem? Thanks again, Ron |
We solved this by removing references to existing methods in the same assembly. Note to others: Don't do that. Your app will crash. |
@ronbarr Is it possible you can open a new bug issue with a simple code sample that creates the crash? At the very least we can raise an error saying "don't do this" thanks so much for your feedback. |
We have four assemblies. I'm trying to simplify our layout and combine the methods from one of the existing assemblies into another one using a protocol. I defined a new protocol describing the to-be-deleted assemblies methods and moved those methods to the existing class, which I'll call MergedAssembly. I made the existing class conform to the protocol, and made all of the other adjustments to properties etc..
Now, MergedAssembly is acting as an assembly, and as also serving up the old class's methods via the protocol interface. That's the theory - in reality it crashes during the [[TyphoonBlockComponentFactory alloc] initWithAssemblies: assemblies] call. When selected view controllers are created, they are returned as TyphoonDefinition objects rather than as the targeted view controllers.
As an exercise I created a new separate class and made it the protocol method provider. It worked fine.
The MergedAssembly is only added once to the initWithAssemblies call (although I tried adding it twice as an exercise - same problem]. The only difference between the working version and the non-working version is that in one case it's talking to two classes, in other only one.
Any ideas? I've spent 4 days trying to narrow this down.
The text was updated successfully, but these errors were encountered: