Let us suppose the following situation. There is a global module AppModule, a scoped module ScopedModule, a class Main and a class Foo in an application's main variant. Moreover, there is a debug variant with a module DebugAppModule, a module DebugScopedModule and a class Bar. Only the debug variant may know about Bar.
The main variant contains the following relevant code excerpts.
#Module AppModule { /*..*/ }
#Module(injects=Main.class, addsTo=AppModule.class)
ScopedModule { #Provides Foo provideFoo() { return new Foo(); } }
class Main { scopedGraph = graph.plus(new ScopedModule(this)); }
class Foo { /*..*/ }
// In the entry point of the application
ObjectGraph.create(new AppModule());
The debug variant contains the following relevant code excerpts.
#Module(addsTo=AppModule.class, overrides=true) DebugAppModule { /*..*/ }
#Module(injects=Main.class, addsTo=DebugAppModule.class, overrides=true)
DebugScopedModule { #Provides Foo provideFoo() { return new Bar(); } }
class Bar extends Foo { /*..*/ }
// In the entry point of the application
ObjectGraph.create(new AppModule(), new DebugAppModule());
My research and experimentation revealed that it is not possible to override #Provides-methods in scoped modules, i.e. when plusing a module. See for example How to Mock Dagger Activity Object Graphs. That is, in the debug variant whenever a Foo is injected it still would be a Foo and not a Bar. This makes sense because the class Main has a fixed dependency to ScopedModule (note the new).
It seems to me that there should be a way to inject scoped modules themselves – meta-injection so to say :). That is, AppModule could provide ScopedModule for Main. The problem is that ScopedModule's constructor needs an instance of Main and so AppModule would need to retain an instance of Main and that would not fly (e.g. in an Android-specific context where Main would be an Activity).
So what is the best alternative way to achieve the effect of overriding #Provides-methods when using scoped modules?
With the latest version of Dagger, overriding #Provided methods are not permitted.
I found a good solution here. Thanks to #vaughandroid
Basically,
When you are providing your module into your component, you can override your methods.
MyComponent component = DaggerMyComponent.builder()
.appModule(new AppModule() {
#Override public Foo provideFoo() {
return new Bar();
}
})
.build();
This has worked for me and I guess it'll work for you.
Related
I'm trying to bind a class C from a third-party's package.
It injects a class Foo instance via constructor -
class C {
public C(#Inject Foo foo) {
...
}
...
}
In my application, I've two instances of Foo bound -
bind(Foo.class)
.to(FooImpl1.class);
bind(Foo.class)
.annotatedWith(Names.named("SpecialFoo"))
.to(FooImpl2.class);
when C is bound, I want the Named Foo instance to be used. However I do not have access to the code in which C is defined, to be able to put any annotations.
Is there a suggested way of doing that, short of writing my own provider method for C?
You could look into using PrivateModule. In your example, it will be something like:
public class CModule extends PrivateModule {
protected void configure() {
bind(Foo.class).to(FooImpl2.class);
bind(C.class);
expose(C.class);
}
}
Since there is no official library from the flutter team, I'm trying to implement the dependency injection in flutter manually using the singleton pattern, after a long search this is what I came up with:
class Injector{
Injector._internal();
static final _singleton = new Injector._internal();
factory Injector() => _singleton;
SomeClass get someClass => new SomeClass();
}
Now, Injector is singleton that has one instance once instantiated and SomeClass is the dependency I want to inject in my code. The above code works, but the problem is where should I instantiate the Injector class and make it available every where in my code. Do you think Global Variable is good in this situation or is there a better way? Thanks.
To implement your own dependency injection I usually use a combination of
A 'Bindings' class which has getters to all injected services
A static getter/setter which holds a single instances of the Bindings class. This is important for overriding the bindings.
The getters which return classes should lazily construct them if they have dependencies. This allows you to override any parts of your graph by extending the Bindings class and setting it in the global bindings. For example, below I have three classes with the third depending on the first two.
class Foo {}
class Bar {}
class Fizz {
Fizz(this.foo, this.bar);
final Foo foo;
final Bar bar;
}
class Bindings {
/// Can be final since there are no dependencies
final Foo foo = new Foo();
final Bar bar = new Bar();
Fizz _fizz;
Fizz get fizz {
_fizz ??= new Fizz(foo, bar);
return _fizz;
}
}
Bindings get bindings => _bindings;
Bindings _bindings;
set bindings(Bindings value) {
_bindings = value;
}
Now suppose I want to override Foo for testing. I can extend the Bindings class and override the field/getter that returns Foo. and in my test setup, I set bindings with this new instance. Now when Fizz is created, the MockFoo instance is used instead of Foo
class MockFoo implements Foo {}
class BindingsOverride extends Bindings {
#override
final Foo foo = new MockFoo();
}
void main() {
bindings = new BindingsOverride();
}
Edit: In an earlier version I was using a static class. I don't think you need to refer to foo and bar through the bindings instance, you can just refer to the members directly.
This is my solution for this problem. First I created a dart file named injector.dart with this code:
// the singleton is private to this package
final _injector = new _Injector();
// expose depedencies
final foo = _injector.foo;
final bar = _injector.bar;
class _Injector{
// create a singleton
_Injector._internal();
static final _singleton = new _Injector._internal();
factory _Injector() {
return _singleton;
}
// the dependecies
Foo get foo => new Foo();
Bar get bar => new Bar();
}
This is how the code work, first we create a singleton class _Injector that creates needed dependencies and then exposes these dependencies with top-level variables. This way the dependencies are accessible anywhere the injector.dart package is accessible.
What do you think guys? is this good or is there a better implementation? Thanks
A small example of a module that injects a class Foo:
#Module(complete = false, injects = { Foo.class })
class MyModule { }
class Foo {
#Inject
Foo(Bar bar, Baz baz) { }
}
(assuming that Bar and Baz are provided by a different module)
I now want Foo to be a singleton.
I could add a #Provides method and annotate it with #Singleton ...
#Module(complete = false, injects = { Foo.class })
class MyModule {
#Provides #Singleton Foo provideFoo(Bar bar, Baz baz) {
return new Foo(bar, baz);
}
}
... but having to write that constructor invocation myself kind of defeats the purpose of using an injection framework. Is there a shorter way to accomplish this?
tl;dr
You can add #Singleton to class Foo {} and when Foo is instantiated via implicit binding, it will be bound as #Singleton. eg:
#Module(complete = false, injects = { Foo.class })
class MyModule { }
#Singleton
class Foo {
#Inject
Foo(Bar bar, Baz baz) { }
}
Scope
The caveat here is that if it is implicitly bound, but not referred to, in a root graph, extension graphs (.plus() generated graphs) may inadvertently instantiate it, so you need to either declare it as an entry-point (injects=) (which you did in your example), or it needs to be consumed by something reachable by an entry-point.
If you're not using .plus() for scoping/lifetime management, then this last point is not that important. But #Singleton means one-per-graph, and graphs' implicit bindings are only realized on-demand. An upcoming feature to allow custom scope annotations to be used will catch these errors.
We're currently looking at translating our JavaScript project to TypeScript. Our application relies heavily on custom developed jQuery UI widgets.
In our current code base, we're using a deep copy mechanism to inherit from widget definitions allowing us, for example, to declare a generic TableWidget as well as an OrdersTableWidget which defines more specific functions.
Therefore, I'd like to define my widget definitions as TypeScript classes and then bind an instance of these classes to jQuery.
For example
class MyWidget {
options: WidgetOptions;
_init(){
// general initialization
}
}
class MySecondWidget extends MyWidget {
_init(){
super._init();
// specific initialization
}
}
And then
$.widget("MyNameSpace.MyWidget", new MyWidget());
$.widget("MyNameSpace.MySeWidget", new MyWidget());
Furthermore, I'd like to denote my custom widgets as implementations of jQuery UI's Widget definition
class MyWidget implements Widget {
options: WidgetOptions;
_init(){
// general initialization
}
}
so I'm able to use the following syntax in TypeScript:
$(selector).MyWidget(options);
I know I have to work with the definition file (from DefinitelyTyped), however I have not yet found a reliable source explaining me how I should write custom jQuery UI Widgets in TypeScript. Has anyone got experience with this?
Any help greatly appreciated, as always!
I'm not sure you can write a class that implements the Widget interface, due to the lack of overloaded constructors. You could create a variable that is typed by the Widget interface.
A standard jQuery plugin would be represent in almost pure JavaScript and wouldn't use modules or classes as it ends up being wrapped up as part of jQuery, which itself isn't a module or class.
Here is an empty plugin called plugin that looks like any standard jQuery plugin, but you can see it takes advantage of the TypeScript type system and extends the JQuery interface to allow it to be called.
/// <reference path="jquery.d.ts" />
interface JQuery {
plugin(): JQuery;
plugin(settings: Object): JQuery;
}
(function ($) {
function DoSomething(someParamater: string) : void {
}
$.fn.plugin = function (settings) {
var config = {
settingA: "Example",
settingB: 5
};
if (settings) {
$.extend(config, settings);
}
return this.each(function () {
});
};
})(jQuery);
This would be called in the normal way.
$('#id').plugin();
So really, my answer is - you can't really do what you want because you are adding to the declared interfaces for jQuery rather than exposing them as modules. You could wrap the usage in a module, like an adaptor that abstracts the jQuery aspect away from the use in your TypeScript, or you can call your classes from inside the plugin, but the plugin or widget doesn't really fit into a module or class.
It might help to have a base class in typescript from which other widget classes may derive.
Its only purpose is to provide the base class semantic so you can access the base class'es members without having to resort to weak typing.
The trick is to remove all the members at runtime (in the constructor) -- otherwise you run into problems with the inheritance provided by the widget factory. For example, the option method would override the widget's original method which is not desired: we just want to be able to call it (in a statically typed way).
class WidgetBase {
public element:JQuery;
constructor() {
// remove all members, they are only needed at compile time.
var myPrototype = (<Function>WidgetBase).prototype;
$.each(myPrototype, (propertyName, value)=>{
delete myPrototype[propertyName];
});
}
/**
* Calles the base implementation of a method when called from a derived method.
* #private
*/
public _super(arg1?:any, arg2?:any, arg3?:any, arg4?:any) {
}
/**
* #private
*/
public _superApply(arguments) {
}
/**
* Gets or sets the value of the widget option associated with the specified optionName.
*/
public option(optionName:string, value?:any):any {
}
// ... further methods from http://api.jqueryui.com/jQuery.widget/
}
Then you can implement your own widget like this:
class SmartWidget extends WidgetBase {
constructor(){
super();
}
public _create() {
var mySmartOption = this.option('smart'); // compiles because of base class
this.beSmart(mySmartOption);
}
public _setOption(key:string, value:any) {
if (key === 'smart') {
this.beSmart(value);
}
this._super(key, value); // compiles because of base class
}
private beSmart(smartOne:any){
// ...
}
}
// register
jQuery.widget("myLib.smartWidget", new SmartWidget());
// assuming you are using https://github.com/borisyankov/DefinitelyTyped
declare interface JQuery{
smartWidget();
smartWidget(options:any);
smartWidget(methodName:string, param1?:any, param2?:any, param3?:any, param4?:any);
}
And finally, you can use your widget:
$(".selector").smartWidget({smart:"you"});
Many methods like complete in class Completer are marked "abstract", but in fact It can be directly invoked without being implemented. I'm really confused. Could anyone help me?
Yes, this can be a bit confusing. While abstract classes cannot be instantiated, it is possible to make them appear to be instantiable by defining a factory constructor. This is what Completer, Future and other abstract classes do:
abstract class Completer<T> {
factory Completer() => new _CompleterImpl<T>();
...
}
You can then invoke methods on the object created by the factory constructor. In the example above, factory Completer() returns a new _CompleterImpl object. Look at the (truncated) code of that class:
class _CompleterImpl<T> implements Completer<T> {
final _FutureImpl<T> _futureImpl;
_CompleterImpl() : _futureImpl = new _FutureImpl() {}
Future<T> get future {
return _futureImpl;
}
void complete(T value) {
_futureImpl._setValue(value);
}
...
}
and you see complete(); that is the method being invoked.