Hello,

I'm trying to use reliant in my today widget and my watch kit extension, but (even when I call ocsInject) my dependencies aren't injected... Do I also need to call ocsBootstrapAndBindObjectContextWithConfiguratorFromClass somewhere on the widget/watch code itself (since they don't really use the AppDelegate)? If so, where, if not, can you help me to find out the issue..?

Thx!

Take the following situation:

A view controller bootstraps an object context. When an application would the initiate two instances of that view controller, living in memory at the same time (eg a detail view controller in a pager), those controllers will have a context with the same name. The current system (context registry et al) cannot deal with this situation. If other controllers now use the context as parent, reliant will always just retain the last created context. This is unintended behaviour. The whole named context system needs to be reviewed. It probably isn't the best idea.

Hi guys!

I discovered an issue (well, at least I think it's an issue, maybe I'm doing something wrong), when you use a manager within another manager. I'll show you a small example:

I have a 'UserManager' which uses a 'PreferencesManager' in his init method. As the documentation says, the injection should be done automatically, but my PreferencesManager keeps being 'nil'. When I do '[self ocsInject]', it's working correctly - but I thought I didn't have to do that?

So, wrong, not working - self.preferencesManger is still nil:

- (instancetype)init {
    self = [super init];
    if (self) {
        _primaryMsisdn = [self.preferencesManager objectForKey:PreferenceKeyPrimaryMsisdn];
    }

    return self;
}

Good, self.preferencesManager is injected properly:

- (instancetype)init {
    self = [super init];
    if (self) {
        [self ocsInject];

        _primaryMsisdn = [self.preferencesManager objectForKey:PreferenceKeyPrimaryMsisdn];
    }

    return self;
}

It's a good workaround for now, but I thought I didn't need to do the '[self ocsInject]' within already injected managers...?

Regards!

Not sure if this has been done before, but I tested out using @steipete's Aspects to set up automatic property injection without imposing boilerplate [self ocsInject]s all over the place (and it works rather nicely). It also furthers our goal of being non-intrusive - regardless of view life cycle particulars.

E.g.: set up a hook in the -viewDidLoad method of any UIViewController which calls -ocsInject before control is handed back to the original -viewDidLoad implementation.

NSError *error;
[UIViewController aspect_hookSelector:@selector(viewDidLoad)
                          withOptions:AspectPositionBefore
                           usingBlock:^(id <AspectInfo> aspectInfo) {
                               UIViewController *instance = (UIViewController *) aspectInfo.instance;
                               [instance ocsInject];
                           }
                                error:&error];

I think we could (optionally) make this part of the the root bootstrapping process. I'm working on an example to demonstrate this.

Open to suggestions, improvements and/or critique.

See OCSConfiguratorFromClass.h:27

In order to limit typos, could we change this to -parentContextClass instead? The implementation could still derive a string using NSStringFromClass.

Hi Guys! I see that your pod spec doesn't include watchOS 2 as supported platform... This way I have problems implementing it in my watch app... Can you take a look?

Thanks!

Very simple HelloWorld sample app and tutorial.

important: Don't forget that the 'main' README.md does not reference this sample app yet. It still references the now removed Example folder and project therein.

When you define a storyboard to be loaded in the project settings it can occur that injection will take place before the reliant context is loaded.

Solution: A Solution is to manually load the storyboard after you load the context in the applicationDidFinishLaunchingWithOptions: method

this should be added to the documentation

When you perform an injection on a class that implements an protocol with an optional property, reliant forces me to implement it. If I don't, the application crashes, complaining about key-value compliance. Implementing the property fixes the issue, but this is obviously just a work-around.

In our examples and documentation we suggest bootstrapping context in the form of:

[someObject ocsBootstrapAndBindObjectContextWithConfiguratorFromClass:[SomeContextConfiguration class]];
[someObject ocsInject];

While this code avoids a lot of boilerplate, it makes the class responsible for bootstrapping less testable. We need some indirection to make the code independent of the NSObject categories.

⚠️ Work-in-progress, do not merge ⚠️

Exploring a way to register context substitutions so they can be swapped out for testing or other purposes.

Current implementation

I added a map to the context cache which will be accessible through relyOnSubstitute(T)(T). This global function simply creates an entry in the map, which relyOn() will then use to determine if it needs to create a substitute context or a normal one, when requested.

Remarks

I have only gotten this to work half-way. The substitute type is registered and found correctly, but when its createContext() function is invoked, the original, non-substituted version is called because createContext() is static with no way to override it, because static also means final in Swift.

Because of how I set up the relyOnSubstitute's arguments (both of the same type T:ReliantContext), the second argument needs to resolve to the same type as the first. That is, the second argument needs to be covariant with the first. This is currently achieved by subclassing the original context, with currently no way to modify createContext()'s implementation due to the reason stated above.

Subclassing doesn't feel right, so I'm currently exploring ways to change relyOnSubstitutes signature to something like:

public func relyOnSubstitute<T:ReliantContext, S:ReliantContext>(type:T.Type)(_ otherType:S.Type)

This causes serious type resolution problems of course, so I'm still trying to figure something out.

When configuration class B extends from configuration class A, only create methods from class B are being picked up. The work around for now is letting class B override all methods in class A. This is a lot of boilerplate, which reliant could easily avoid.