Open vitorhugomagalhaes opened 7 years ago
TyphoonAssemblyActivator was deprecated.
Yes. This one was removed, because Typhoon was changed a lot. Main reason of that change - improve performance.
If you want to understand technical details.
We list all assembly methods and.. SWIZZLE THEM ALL! Main reason for swizzle was: rename methods, and then intercept invocations and handle properly. That's possible because methods moved from original place, so we can implement "forwardInvocation" there.
Example:
You have your FactoryAssembly
instance, and you have fooService
instance method that returns TyphoonDefinition
.
TyphoonAssemblyActivator swizzles fooService
into __typhoon_swizzled_fooService
for example. Now, __typhoon_swizzled_fooService
returns TyphoonDefinition
and fooService
doesn't exists. Then you calling fooService
instance method which doesn't exists, and we handle that with forwardInvocation
- we creating real instance based on TyphoonDefinition
Method swizzling is slow, when you swizzling hundreds of methods on startup. It can be measured with seconds, when you have hundreds assemblies.
Instead of swizzling assembly methods on actual TyphoonAssembly subclass, we using "proxy" (It's internal object called TyphoonAssemblyAccessor
in Typhoon) object that handles your call with forwardInvocation:
and calls original Assembly method if needed to get TyphoonDefinition.
So in terms for performance, we don't need to spent any time on swizzling.
@alexgarbarev Let's prepare a migration guide as @vitorhugomagalhaes requested.
Hi,
Thanks for the insights.
Even so, what would be the fix for FactoryAssembly class ?
Regarding the plist load order, are you aware of such issue ?
Thanks,
Even so, what would be the fix for FactoryAssembly class ?
The correct way to get activated assembly (outside plist or appDelegate bootstrapping):
FactoryAssembly *activatedAssembly = [FactoryAssembly activated];
Regarding the plist load order, are you aware of such issue ?
This shouldn't be a problem
Does it make sense @vitorhugomagalhaes? Can we close this issue?
@vitorhugomagalhaes am facing currently facing the same issue of circularly dependant assemblies. Could you please tell me how the issue was solved?
Hi,
I've tried to use the new 4.0.2 release but there were some API changes that I cannot understand. Some of them cause the app to crash.
Here goes a list of issues:
TyphoonAssemblyActivator was deprecated.
Some of our assemblies are not listed in the plist file and thus, we have the following code to manually activate them.
After checking the docs it was not clear how to refactor this. Could you please provide some more insights here ?
Plist activation + Modularizing Assemblies
The order used when declaring the assemblies in the plist file was not relevant until now. However, with this new version it has changed somehow.
If serviceAssembly is declared after SupportStoryboardViewFactoryAssembly the following code will crash:
Moving ServiceAssembly before SupportStoryboardViewFactoryAssembly solves the issue. Still, due to circular dependencies I cannot follow this approach.
Any ideas how to handle this ?
Thanks in advance,