ios - 使用 Typhoon Assembly(plist 方法)创建的 AppDelegate 创建了两次并且属性注入(inject)不起作用

Question

我正在尝试使用 PList 集成方法引导 Typhoon，但我的 ApplicationDelegate 被创建了两次。第一次创建时，显然是由 Typhoon 创建的。那时，它使用特殊的初始化程序 initWithAssembly: 和 Typhoon 将程序集提供给它。

第二次，重要的是，它是使用 init 创建的。它永远不会获得对程序集的引用。

为了以防万一，我还通过属性方法注入(inject)了assembly。不行。

代码如下:

程序集

- (UIApplication *)sharedApplication {
    return [TyphoonDefinition withClass:[UIApplication class] configuration:^(TyphoonDefinition *definition) {
        [definition useInitializer:@selector(sharedApplication)];
    }];
}

- (CTISApplicationDelegate *)appDelegate {
    return [TyphoonDefinition withClass:[CTISApplicationDelegate class]
                          configuration:^(TyphoonDefinition *definition) {
                              [definition useInitializer:@selector(initWithAssembly:) parameters:^(TyphoonMethod *initializer) {
                                  [initializer injectParameterWith:@(3)];
                              }];

                              definition.scope = TyphoonScopeSingleton;
                          }];
}

AppDelegate

@property (nonatomic, strong, readwrite) ApplicationAssembly *assembly;

@property (nonatomic, strong, readwrite) UIWindow *window;

- (instancetype)initWithAssembly:(ApplicationAssembly *)assembly;

...

// This gets called once, the first time, and assembly is NOT nil.
- (instancetype)initWithAssembly:(ApplicationAssembly *)assembly {
    self = [super init];

    if (self) {
        self.assembly = assembly;
    }

    return self;
}

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] applicationFrame]];

// This gets ca

填充一次(在第二次初始化之后)并且 self.assembly 为零。

AcceptDisclaimerAppInfoModule *disclaimer = [[self.assembly applicationInformationModuleAssembly] acceptDisclaimerModule];

[disclaimer launchModuleFromWindow:self.window];

[self.window makeKeyAndVisible];
return YES;

Answer 1

在网上查看并疯狂地思考这个问题后，我得出了一些结论。

问题的根源在于Typhoon和我的 main.m入口点未以任何形式同步。所以，main.m电话 UIApplicationMain()其中一个参数是一个字符串，它指定了 id<UIApplicationDelegate> 的种类你要。我从未见过与此模式有任何偏差，因此我不愿意对其进行更改。

因此，id<UIApplicationDelegate> 是给定的不会通过 Typhoon 构建以一种“内置”在框架中的方式。虽然您可以执行以下操作之一，但我不推荐任何操作:它们似乎都是错误的。

• 实例化你的根实例 TyphoonAssembly直接来自您的应用代表
• 创建单例 IContainer可以拥抱 TyphoonAssembly 的物体启动时创建的实例
• 以邪恶的方式将类别与相关对象一起使用

问题是......在某些时候，如果你没有做对，无论如何你都需要做这些邪恶的事情之一。

原因是... Typhoon显然是为在“对象图”的上下文中工作而设计的，所以整个 TyphoonAssembly并且任何连接的程序集都可以被认为是图形的网络。一旦你进入网络，你就没事了——你可以从那里拿走它。你只需要进入...

所以，我决定如下:

1. 为我调用的相关对象的每个“对象图”创建接口(interface) IContainer ，即使它们跨越多个程序集或小于一个程序集。这断开了 Typhoon 的想法来自 IContainer并且可以在没有 Typhoon 的情况下进行调试通过替换模拟 IContainer到位。
2. 独家 使用构造函数注入(inject)，除了一个非常值得注意的情况 - 我刚才提到的那个，应用程序委托(delegate)。在那里，使用属性注入(inject)只注入(inject)一个属性 - IContainer有问题。
3. 无论何时使用属性注入(inject)，您最好只注入(inject)一个属性，IContainer ，因为你已经打破了封装，你也可以让自己轻松一点。
4. 实现一些有趣的事情来向自己证明 Typhoon的默认范围按照您认为的方式工作。每当我检测到对同一对象图中的任何构造函数的多次调用时，我都会实现一些“警报”。
5. 使用id<nonatomic, weak>对于委托(delegate)类型，不是 id<nonatomic, assign>就像我过去一年所做的那样。关于途中的事Typhoon幕后工作必须使其不断放开代表。
6. 使用 PList 注入(inject)和程序集组合。一个例子:

在您的 Info.plist 中，添加一个名为 TyphoonInitialAssemblies 的键与 Array type 和 values 是程序集的类名。但是……

不要忘记做另一半，即确保您有一个像RootAssembly 这样的“根”程序集。然后是一些ModuleAssembly RootAssembly 存储的 s :

@protocol IAppLaunchContainer

- (UIWindow *)launchWindow;
- (UIViewController *)launchRootViewController;
- (UIImageView *)launchImageView;

@end

@protocol IDefaultUIComponentsContainer

- (UIView *)uiDefaultView;
- (UILabel *)uiDefaultLabelWithName:(NSString *)name;
- (UIButton *)uiDefaultButtonWithTitle:(NSString *)title;

@end

@interface RootAssembly : TyphoonAssembly<IAppLaunchContainer, IDefaultUIComponentsContainer>

@property (nonatomic, strong) SubAssemblyA *thisModuleAssembly;
@property (nonatomic, strong) SubAssemblyB *thatModuleAssembly;

@end

在这种情况下，您的 Info.plist 将具有:

1. TyphoonInitialAssemblies ( Array )
   • SubAssemblyA
   • SubAssemblyB