Sometimes the pointer returned after init is different than the one that gets created in alloc. . . A class cluster (NSURL, NSArray, etc) will regularly do this, for example:

initWithDuration:(NSUInteger)duration
{
    id<NSObject> returnValue = nil;
    [self release];   
    if (duration < 5) 
    { 
        returnValue = [ShortHoliday alloc] init]; 
    }
    else 
    {
        returnValue = [LongHoliday alloc] init]; 
    }
    return returnValue; 
}

Early version of Typhoon had a problem in this case, now fixed. However, NSManagedObjectModel still required special-case treatment, to prevent it from being over-released.

What is NSManagedObjectModel doing that is different? How can we convert the special-case treatment to one that will work for anything?

Hi folks,

I have some idea how to implement autowite with syntax:

@interface Knight

@property (nonatomic, strong, typhoon_injected) NSString *foo; //property attribute
@property (nonatomic, strong) NSString *foo TYPHOON_INJECTED; // like UI_APPEARANCE_SELECTOR
@property (nonatomic, strong) TYPHOON_INJECTED NSString *foo; // like IBOutlet

@end

Since we cannot add our own property attributes or clang attributes - all keywords above are just empty defines:

#define TYPHOON_INJECTED
//or
#define typhoon_injected

Because we cannot obtain these marks at runtime I thought that we can collect all these marks by our own 'parser', lets call it TyphoonPreprocessor.

It should be fast objective-c written utility (with caching in 'derived data' processed filepaths to avoid processing not changed files).

Result of TyphoonPreprocessor can be XML file in typhoon format. XML should has definitions with TYPHOON_INJECTED properties. For example:

<component class="Knight" key="knight_autowire">
    <property name="foo" />
</component>

Next step is coping result XML into application bundle - this step can be similar to Pods-resources.sh script.

Final step is loading TyphoonXmlComponentFactory with autowiring XML and re-register all definitions to user-created TyphoonComponentFactory.

Disadvantages

• Extra build phase in user's project (can be added automatically by spec.prepare_command)
• Longer build&install time (can be improved by caching - parsing only changed files, also we can decide to parsing only '.h' files - they are much smaller)
• Longer Typhoon initialization process - because xml parsing and re-registering definitions

Advantages

• Nice looking 'typhoon_injected' property attribute for auto-wiring
• Ability to add another preprocess macroses
• auto-wiring with same way as TyphoonXmlComponentFactory. Easy to debug by viewing result XML.
• typhoon_injected tags can be used in future to write Typhoon Xcode plugin for smart autocomplete

What do you think? Make sense?

I'm in the process of upgrading from Typhoon 1.8.6 to 2.0.7 and writing my Assemblies, but I'm greeted by this error whenever I launch.

I have about 20 view controllers in my application. These view controllers extend a base view controller we have that declares a bunch of dependencies.

Naturally, I am looking to share the code to set these dependencies as well. I tried making a private shared method which sets these but it results in the above exception at run time.

Is the preferred way to have a definition defined in the assembly for the base class itself?

Thanks

Ronak

following this question on stack overflow: http://stackoverflow.com/questions/29467353/auto-injection-with-typhoon-swift/29467669#29467669

currently there's no way to auto wire injections for swift, this generates a big overhead registering everything explicitly in the typhoonAssembly. would be great to have a name convention for injected properties/parameters etc and only having to register the class. (if that can be saved too somehow would be great). something like haveing a name prefix for properties that are injected

If I create a TyphoonBlockComponentFactory like so:

    TyphoonComponentFactory *typhoonComponentFactory = [[TyphoonBlockComponentFactory alloc] initWithAssemblies:@[[FooAssembly assembly], [BarAssembly assembly], [BazAssembly assembly]]];

... and BarAssembly contains a definition that refers to a definition in BazAssembly:

- (id)blah {
    return [TyphoonDefinition withClass:[Blah class] properties:^(TyphoonDefinition *definition) {
        [definition injectProperty:@selector(thingy) withDefinition:[[BazAssembly assembly] thingy]];
    }];
}

... Typhoon silently injects nil into my Blah object's thingy property. Changing the order of the assemblies in the component factory definition fixes it.

Ideally I want

- (void)injectProperty:(SEL)withSelector;
- (void)injectProperty:(SEL)selector with:(id)something;
- (void)injectProperty:(SEL)withSelector withStringRepresentation:(NSString *)string;
- (void)injectProperty:(SEL)withSelector withCollection: (...)

Where 'something' in method

- (void)injectProperty:(SEL)selector with:(id)something;

can be:

• definition
• object instance
• factory ( self reference in assembly subclass)

New methods:

withDefinition:(TyphoonDefinition *)factoryDefinition selector:(SEL)factorySelector;
withDefinition:(TyphoonDefinition *)factoryDefinition keyPath:(NSString *)keyPath;

should be removed and replaced by something like (method names are bad, let's think more)

- (TyphoonDefinition *) resultOfInvocationSelector:(SEL)selector;
- (TyphoonDefinition *) resultOfInvocationKeypath:(NSString *)string;

I.e.

[definition injectProperty:@selector(property) with:[[self factoryDefinition] resultOfInvocation:@selector(newInstance)];

A complex chain of circular dependencies with prototype scope, can mean that two different instances of a dependency are instantiated .. there should only be one.

Here's an example:

- (id)yourDetailsController
{
    return [TyphoonDefinition withClass:[MPYourDetailsController class] initialization:^(TyphoonInitializer* initializer)
    {
        initializer.selector = @selector(initWithServiceClient:yourDetailsView:validator:);
        [initializer injectWithDefinition:[self registrationClient]];
        [initializer injectWithDefinition:[self yourDetailsView]];
        [initializer injectWithDefinition:[self yourDetailsValidator]];
    }];
}

- (id)yourDetailsView;
{
    return [TyphoonDefinition withClass:[MPYourDetailsView class] properties:^(TyphoonDefinition* definition)
    {
        [definition injectProperty:@selector(delegate) withDefinition:[self yourDetailsController]];
    }];
}


- (id)yourDetailsValidator
{
    return [TyphoonDefinition withClass:[MPInputValidator class] initialization:^(TyphoonInitializer* initializer)
    {
        initializer.selector = @selector(initWithView:);
        [initializer injectWithDefinition:[self yourDetailsView]];
    }];
}

The UIView given to the controller is not the same UIView given to the validator:

Many services offer iOS SDKs that require the app to set the SDK up with a one-line class method call early in the application. e.g.: Parse's initialization looks like: [Parse setApplicationId:@"<your app id>" clientKey:@"<your client key>"];.

These often go into the -application:didFinishLaunchingWithOptions: method of your XXAppDelegate.

When using Typhoon, it sometimes makes sense to inject components that make use of these services. The problem is, it's possible that these components are instantiated before -application:didFinishLaunchingWithOptions: even has a chance to execute. For instance:

@interface MYAppDelegate ()
@property(nonatomic, strong) InjectedClass(MYComponentThatNeedsParseSetUpBeforeInitialization)component;  // !!! calls to Parse made before Parse is ready
@end

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

    [Parse setApplicationId:@"<your app id>" clientKey:@"<your client key>"];

    // Parse is ready here.

    return YES;
}

So officially, where should these calls go instead?

With the introduction of swift, and cocoapods lack of swift support, it would be nice (and likely needed once cocoapods does support swift - e.g dynamic frameworks) to support building typhoon as a dynamic framework. This is necessary for supported typhoon DI in swift libraries that themselves build dynamic frameworks and link into the main app project.

For example, say I have the following swift projects that build dynamic frameworks:

XXFoo-> XXFoo.framework XXBar -> XXBar.framework

These libraries are then linked into my main app project, XXMyApp. In order for XXMyApp to leverage Typhoon DI, cocoapods can be used to create a libPods.a static library with the Typhoon source and a bridging header (XXMyApp-Bridging-header.h) can be created and #import "Tyhoon.h". Now this is al well and good if all of my Typhoon assemblies exist in XXMyApp, however, if I truly want to leverage the power of DI in XXFoo and XXBar I should be able to define my TyphoonAssembly factories in each library and import them for use in XXMyApp. This way each library would be responsible for setting up its own dependencies.

This is currently not possible with the pods approach as you cannot link a static library (e.g. libPods.a) into a dynamic swift framework. You can however link to dynamic frameworks, so if Typhoon was able to build a dynamic framework (e.g. Typhoon.framework) then XXFoo, XXBar and XXMyApp could link against it; XXFoo and XXBar could define their own assemblies and XXMyApp would be able to instantiate them.

Because dynamic frameworks are not yet supported by cocoapods, the approach that several swift-only libraries are taking are git modules, so swift libraries want to dynamic link against Typhoon could:

1. Create a git submodule
2. Add Typhoon.xcodeproj to their workspace
3. Add Typhoon.framework as a target dependencies in the build phases
4. Add a "Copy Frameworks" build phase and copy Typhoon.framwork to their Frameworks path

Hi Folks, (AppCoders especially)

Not sure why, but it looks like the code-style is changing. . . anyone check in their personal settings to the project by accident?

I’m happy to change the style, but we should choose something and stick to it.

https://github.com/typhoon-framework/Typhoon/issues/98

Hi

Steps to reproduce:

1. Download the example.
2. Change the Build Configuartion scheme from 'Debug' to 'Release'
3. Build and Run

Here is a copy of the exception being raised on startup.

2014-12-01 11:29:38.369 PocketForecast[38575:636356] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Method 'initWithNibName:bundle:' has 2 parameters, but 1 was injected. Inject with 'nil' if necessary'

The wrong parameters seem to be being injected into the initialiser...

Could this be a SWIFT closure problem? Strange it only happens in RELEASE builds.

FYI I am also seeing the same problem with my own SWIFT application using Typhoon both 2.3.0 & 2.3.1

I've referenced document for modularized assemblies here (https://github.com/appsquickly/typhoon/wiki/Modularizing-Assemblies).

It works. But If I found it crashes in some case. I write a sample code at here: https://github.com/xrloong/Typhoon-Modularized-Assemblies

In this sample, I use two assemblies, AppAssembly and ModularAssembly. AppAssembly keeps a ModularAssembly.

1. In AppAssembly, it defines a TyphoonDefinition for ApplicationHelper. This definition injects a property of type UIApplication through ModularAssembly. It works.

- (ApplicationHelper*) applicationHelper
{
    return [TyphoonDefinition withClass:[ApplicationHelper class] configuration:^(TyphoonDefinition *definition) {
        [definition useInitializer:@selector(initWithApplication:) parameters:^(TyphoonMethod *initializer) {
            [initializer injectParameterWith:[self.modularAssembly application]];
        }];
    }];
}

2. In AppAssembly, it defines a TyphoonDefinition for AnotherHelper. This definition injects a property of type NSString through AppAssembly's method. It works.

- (AnotherHelper*) anotherHelper
{
    return [TyphoonDefinition withClass:[AnotherHelper class] configuration:^(TyphoonDefinition *definition) {
        [definition useInitializer:@selector(initWithName:) parameters:^(TyphoonMethod *initializer) {
            [initializer injectParameterWith:[self anotherHelperName]];
        }];
    }];
}

3. If TyphoonDefinition for AnotherHelper. it injects NSString through [self.modularAssembly anotherHelperName]. This definition injects a property of type NSString through ModularAssembly. It crashes.

- (AnotherHelper*) anotherHelper
{
    return [TyphoonDefinition withClass:[AnotherHelper class] configuration:^(TyphoonDefinition *definition) {
        [definition useInitializer:@selector(initWithName:) parameters:^(TyphoonMethod *initializer) {
            [initializer injectParameterWith:[self.modularAssembly anotherHelperName]];
        }];
    }];
}

Here is the crash log: 2020-02-03 12:41:15.065292+0800 Typhoon Modularized Assemblies[2153:1553507] Before performInject 2020-02-03 12:41:15.067238+0800 Typhoon Modularized Assemblies[2153:1553507] Before [AppAssembly inject:] 2020-02-03 12:41:15.068321+0800 Typhoon Modularized Assemblies[2153:1553507] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'No component matching id 'anotherHelperName'.' *** First throw call stack: (0x1956a496c 0x1953bd028 0x19559414c 0x1048a2b54 0x1048b64e0 0x1048b5e44 0x1048bb9dc 0x10488bca4 0x10488b820 0x1048bb780 0x1048a729c 0x10489fd08 0x10489fbb8 0x1048a03f4 0x1048a4870 0x1048a2b74 0x1048a2a44 0x1048b70e4 0x1048a058c 0x1048b6fa0 0x1048a81f0 0x1048a78e0 0x10489fe0c 0x1048a4244 0x1048a3190 0x1048961c0 0x10488a9e4 0x10488ab10 0x1997890f8 0x19978aef4 0x199790820 0x198f29198 0x19978c914 0x19978cc74 0x199792a60 0x10488af40 0x195498e18) libc++abi.dylib: terminating with uncaught exception of type NSException

Storyboard inject is not working in swift. Always I'm getting null.

I have created two Assembiles (Application and Presentation) and added into plist.

//
//  Application.swift
//

import UIKit
import Typhoon

class Application: TyphoonAssembly {

    func appDelegate() -> AnyObject {
        return TyphoonDefinition.withClass(AppDelegate.self, configuration: { definition in
            definition!.injectProperty(#selector(setter: AppDelegate.homeStoryboard), with: self.homeStoryboard())
            definition!.injectProperty(#selector(setter: AppDelegate.loginStoryboard), with: self.loginStoryboard())
        }) as AnyObject
    }



    
    @objc func homeStoryboard() -> AnyObject {
        return TyphoonDefinition.withClass(TyphoonStoryboard.self, configuration: { (definition) in
            definition?.useInitializer(#selector(TyphoonStoryboard.init(name:factory:bundle:)), parameters: { initializer in
                initializer!.injectParameter(with: "Home")
                initializer!.injectParameter(with: self)
                initializer!.injectParameter(with: Bundle.main)
            })
        }) as AnyObject

    }
    
    
    @objc func loginStoryboard() -> AnyObject {
        return TyphoonDefinition.withClass(TyphoonStoryboard.self, configuration: { (definition) in
            definition?.useInitializer(#selector(TyphoonStoryboard.init(name:factory:bundle:)), parameters: { initializer in
                initializer!.injectParameter(with: "Login")
                initializer!.injectParameter(with: self)
                initializer!.injectParameter(with: Bundle.main)
            })
        }) as AnyObject
        
    }

    @objc func aboutStoryboard() -> AnyObject {
        return TyphoonDefinition.withClass(TyphoonStoryboard.self, configuration: { (definition) in
            definition?.useInitializer(#selector(TyphoonStoryboard.init(name:factory:bundle:)), parameters: { initializer in
                initializer!.injectParameter(with: "About")
                initializer!.injectParameter(with: self)
                initializer!.injectParameter(with: Bundle.main)
            })
        }) as AnyObject
        
    }

    
}

//
//  Presentation.swift
//

import UIKit
import Typhoon

class Presentation: TyphoonAssembly {

     private var application: Application!
    
    func sideMenuViewController() -> SideMenuViewController? {
        return TyphoonDefinition.withClass(SideMenuViewController.self, configuration: { (definition) in
            definition?.injectProperty(#selector(setter: SideMenuViewController.homeStoryboard), with: self.application.homeStoryboard)
             definition?.injectProperty(#selector(setter: SideMenuViewController.aboutStoryboard), with: self.application?.aboutStoryboard)
          
        }) as? SideMenuViewController
    }
    
    func homeViewController() -> HomeViewController? {
        return TyphoonDefinition.withClass(HomeViewController.self, configuration: { (definition) in
            
        }) as? HomeViewController
    }
    
    func aboutViewController() -> AboutViewController? {
        return TyphoonDefinition.withClass(AboutViewController.self, configuration: { (definition) in
            
        }) as? AboutViewController
    }
    
    
}

//
//  AppDelegate.swift
//

import UIKit
import SlideMenuControllerSwift

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?
   @objc var  homeStoryboard  : AnyObject?
    @objc var loginStoryboard : AnyObject?

    fileprivate func createMenuView() {
   
        let homeViewController =  homeStoryboard?.instantiateViewController(withIdentifier: "HomeViewController") as! HomeViewController
        let sideMenuViewController = homeStoryboard?.instantiateViewController(withIdentifier: "SideMenuViewController") as! SideMenuViewController
        
        let nvc: UINavigationController = UINavigationController(rootViewController: homeViewController)
        UINavigationBar.appearance().tintColor = UIColor.white
        UINavigationBar.appearance().barTintColor = UIColor.darkGray
        
        sideMenuViewController.homeViewController = nvc
        
        
        let slideMenuController = ExSlideMenuController(mainViewController:nvc, leftMenuViewController: sideMenuViewController)
        SlideMenuOptions.contentViewScale = 1
        slideMenuController.delegate = homeViewController as? SlideMenuControllerDelegate
        self.window?.backgroundColor = UIColor(red: 236.0, green: 238.0, blue: 241.0, alpha: 1.0)
        self.window?.rootViewController = slideMenuController
        self.window?.makeKeyAndVisible()
        
    }
    
    func logout() {
        let loginViewController = loginStoryboard?.instantiateViewController(withIdentifier: "Login") as? LoginViewController
    
        if self.window?.rootViewController?.presentedViewController != nil {
            self.window?.rootViewController?.dismiss(animated: false)
        }
        
        if let loginViewController = loginViewController {
            self.window?.rootViewController?.present(loginViewController, animated: false, completion: nil)
        }
    }

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Override point for customization after application launch.
        self.createMenuView()
        return true
    }

    func applicationWillResignActive(_ application: UIApplication) {
        // Sent when the application is about to move from active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state.
        // Use this method to pause ongoing tasks, disable timers, and invalidate graphics rendering callbacks. Games should use this method to pause the game.
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        // Use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later.
        // If your application supports background execution, this method is called instead of applicationWillTerminate: when the user quits.
    }

    func applicationWillEnterForeground(_ application: UIApplication) {
        // Called as part of the transition from the background to the active state; here you can undo many of the changes made on entering the background.
    }

    func applicationDidBecomeActive(_ application: UIApplication) {
        // Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
    }

    func applicationWillTerminate(_ application: UIApplication) {
        // Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
    }


}

How inject storyboard in swift. Why homestory board object is getting null in AppDelegate?

I'm having an issue with the sample app see comment

And while trying to investigate further and see if I could fixed I noticed that the TyphoonAssemblyBuilderTests that are responsible for checking the piece of code that throws the exception are not being run.

When installed through Carthage Task failed with exit code 65: /usr/bin/xcrun xcodebuild -project /Users/alekzernov/Downloads/enegyhouserev2.0/Carthage/Checkouts/Typhoon/Typhoon.xcodeproj -scheme Typhoon -configuration Release -derivedDataPath /Users/alekzernov/Library/Caches/org.carthage.CarthageKit/DerivedData/9.4_9F1027a/Typhoon/4.0.5 -sdk iphonesimulator -destination platform=iOS\ Simulator,id=1D1D025C-9F81-4183-B247-1F69285384B6 -destination-timeout 3 ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES build (launched in /Users/alekzernov/Downloads/enegyhouserev2.0/Carthage/Checkouts/Typhoon) help me please

Hi,

I'm trying to use Typhoon in the iMessage Extension of IOS with partial luck. Only manual integration works, plist integration doesn't. This issue is pretty similar to https://github.com/appsquickly/Typhoon/issues/352 and it looks like you fixed it but for some reason my class properties don't get injected automatically even though I followed the instructions on your docs. Here's a link to the sample project I created: https://github.com/lirantzairi/TestIMessages It's a simple project containing two targets:

• Host app. If you run it you see that automatic injection works.
• Extension app. If you run it you see that automatic injection doesn't work - the property "myClass" doesn't get injected and remains nil. Can you please help me understand where the issue is?

Thanks, Liran.

Steps to repro:

In header:

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

In impl:

- (ProfilePreviewHelper *)profilePreviewHelper
{
    return [TyphoonDefinition withClass:[ProfilePreviewHelper class] configuration:^(TyphoonDefinition *definition) {
        [definition injectProperty:@selector(assembly)];
        [definition injectProperty:@selector(profileService)];
        [definition injectProperty:@selector(rootController) with:[self.assembly rootController]];
        [definition injectProperty:@selector(candidatesService)];
        definition.scope = TyphoonScopeWeakSingleton;
    }];
}