Skip to content
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

TyphoonStoryboard review #182

Closed
alexgarbarev opened this issue Feb 24, 2014 · 7 comments
Closed

TyphoonStoryboard review #182

alexgarbarev opened this issue Feb 24, 2014 · 7 comments

Comments

@alexgarbarev
Copy link
Contributor

Issue to review feature

@jasperblues
Copy link
Member

History:

The current approach is to obtain an instance from the StoryBoard, and then tell Typhoon to inject it. Not nice.

Other approaches:

  • Dependency injection for objects not emmitted from component factory?  #103 was suggested. . however it would assume that all instances of a given class or configured with the same dependencies. This is certainly not always the case.
  • Swizzle UIStoryBoard, this would provide more seamless integration. But also carries the risk of being incompatible with another framework that's doing the same thing.
  • Just use a TyphoonStoryboard sub-class.

Aleksey recommenced the last option, and I agree it appears to have the most merits.

@eriksundin
Copy link
Contributor

Good job Aleksey!
I think this solution is good. Being able to add a typhoonKey on the ViewController paired with the new

- (void)injectProperties:(id)instance withDefinition:(SEL)selector

comes around the previous limitation where you would only be able to safely inject properties on an object if there was only one definition for that class in the assembly.

@jasperblues
Copy link
Member

@eriksundin We should add that immediately at the TyphoonComponentFactory level, to get around the current limitation where "bring-your-own-instance" only supports by-type matching.

For the pending TyphoonStoryboard (sub-class), we'll take it a little further: Make it a by convention approach, where the TyphoonDefinition key (ie selector in block-style) matches the storyboard identifier. . then just obtain the instance from the TyphoonStoryboard .. will come pre-injected.

This should work in 99% of cases, but if not then fall back to the "bring-your-own-instance" style.

@alexgarbarev
Copy link
Contributor Author

@jasperblues using storyboad identifier as TyphoonDefinitionKey is ideal solution, but it can't be done :-( Tthe problem is in creation UINavigationController and UITabBarController - these controllers have 'relation' segues ('rootViewController' and 'viewController') but method
instantiateViewControllerWithIdentifier invokes only for parent (i.e. UINavigation and UITabBar Controllers itself) - not for related controller. So I cannot obtain storyboardIdentifier from already created ViewController.

I also thought of using restorationIdentifier (easer to specify in storyboard) as TyphoonDefinitionKey, but its avatailable since 6.0 :-(

@alexgarbarev
Copy link
Contributor Author

@jasperblues To see that I said in previous comment:
set breakpoint to
- (id)instantiateViewControllerWithIdentifier:(NSString *)identifier
and run test:
- (void) test_first_from_navigation

@jasperblues
Copy link
Member

@alexgarbarev

Here's some other ideas to explore:

  • You can create an IBOutlet on an Apple class using associative_references and cateogories. Perhaps we can drag over to a definition or something.
  • Use runtime attributes to set the TyphoonKey. . (again with an associative reference).

Update:

Neither of the above suggestions are plausible.

@jasperblues
Copy link
Member

@alexgarbarev Great job. . . we've ruled out other approaches.

Any more comments (from anyone) before we close?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants