I'm new to dagger. I was following the documentation at https://dagger.dev/dev-guide/ and when it comes to Binding Instances section, here's the example provided:
#Component(modules = AppModule.class)
interface AppComponent {
App app();
#Component.Builder
interface Builder {
#BindsInstance Builder userName(#UserName String userName);
AppComponent build();
}
}
My question is where's this #UserName coming from?
The explanation leading to this code block is
Perhaps your app takes a single argument representing the user’s name that you’d like to inject as #UserName String. You can add a method annotated #BindsInstance to the component builder to allow that instance to be injected in the component.
I couldn't reason about it. Can anyone shed some light?
Thanks
#Username in this example is a Qualifier. If you were to use/inject a plain String it'd clutter things up quite a lot (since String is a somewhat common type), but in combination with a qualifier #Username String becomes a unique key.
#Named("foo") is a basic qualifier included that you can use, or you can just create your own—e.g. #Username
Related
I started learning Dart and was reading a critique of some of it's design choices here: https://medium.com/#krossovochkin/dart-language-bad-design-choices-6e35987dc693
The last point that is made is about the poor type system and the author cited this code snippet which prints null:
void main() {
String s = null;
if (s is String) {
print("string");
} else if (s is Null) {
print("null");
} else {
print ("none");
}
}
The is keyword was new to me but "The Dart Programming Language" by Gilad pointed out that is checks the interface implemented by an object's class and not the actual class of an object.
However this didn't help me much because I would think that the variable s is an instance of String and therefore implements String, but the evidence is to the contrary.
I get that the class is not required when defining objects/variables in Dart, and thus I started to wonder if putting the class in the definition just serves as sugar and has little functional purpose. But instead the class of an object/variable is completely determined by its value, and since the default value for all variables in Dart is null, then it would make sense that String is not implemented, but Null is. Is this the case? Am I way of base? Maybe someone could help me wrap my head around this.
The reason is that is checks the interface of the current object itself and not the reference to this object. So yes, s can point to a String object but also allowed to point to null which are a instance of Null: https://api.dart.dev/stable/2.7.2/dart-core/Null-class.html
Since Null does not implement the String interface, this will return false (null is String). This is also mentioned in the article.
The problem the article are trying to focus on are more the fact you are allowed to set the String variable to null value but Null does not implement String.
Well, in the future, this problem are going to be fixed with non-nullable types which are in development right now. When this is implemented you can actually define variables where you can be sure the value will never be null.
So I continued my Dart reading and I came to a better understanding, and that is that Dart is truly optionally typed and that means 2 things:
Type are syntactically optional.
Type has no impact on runtime semantics.
Therefore the actual type annotation of a variable in Dart only serves documentation purposes and it cannot be assumed that a type annotation is true. The actual type of a variable is wholly determined by the value stored at this variable, and in this case it is null.
In truth the variable that I defined in my example is not a String variable or an implementer of the String interface. It is just annotated that it may be/should be/most likely is a string.
I am new to Dart language. So I would like to know more about some conventions that programmers follow while developing in this language.
Should I always encapsulate my class members as I do, for example in Java? Whenever I create property of class, should I make it private and provide getters/setters? Or there are situations when I should leave them public? If so, what are examples of these situations?
In my opinion, type annotations such as String, int, etc. increase readability of code. They serve as a documentation for other developers who are reading/using my code. Programmer should not think value of what type is storing in this variable right now. So again, what are the situations, that require using var keyword when declaring a variable?
Dmitry.
Thank you.
Thanks for checking out Dart!
No need to encapsulate class fields. Dart creates implicit getters and setters for you. If you need to actually compute something for that field, you can then implement the getter or setter manually. Bonus: this doesn't break consumers of your API.
Example:
class Person {
int age;
}
Later, you want to calculate age:
class Person {
DateTime birthdate;
int get age => new DateTime.now().difference(birthdate).inDays ~/ 365;
}
In both cases, you can do this:
print(person.age);
Pretty cool! No change in API, and no defensive getters and setters (just add them when you need them).
You should use type annotations for the "surface area" of your code. For example, use type annotations for method and function signatures. For cases where the variable's type is very obvious, you should consider using var, because it's more terse and readable.
For example:
String doCoolStuff(int bar) {
var clearlyABool = true;
return 'Hello world';
}
Note that the return type and bar parameter are type annotated, but the clearlyABool uses var because we initialize with a bool.
Feel free to use type annotations everywhere, it's programmer choice. Anecdote: the dart2js source code uses type annotations pretty much everywhere.
I'm increasingly finding myself mixing runtime parameters and implicit construction injection and it smells bad to me.
Example - I have a base class describing a Filter, and various inherited types for specific filters (tag, category, date, author, etc etc)
var filter = StructureMap.ObjectFactory
.With("caption").EqualTo("Posts filtered by tag:")
.With("parameters").EqualTo(parameters)
.With("displayInSummary").EqualTo(true)
.GetInstance<TagListFilter>();
The reason I do this is because in the constructor I have an interface using which I wish StructureMap to inject a concrete class (IArticleConfigurator):
public TagListFilter(string caption, IDictionary<string,string> parameters, bool displayInSummary, IArticleConfigurator configurator)
:base(caption, parameters,displayInSummary, configurator)
But it just occured to me that I replaced a simple constructor, albeit with a concrete class instead of interface, with, essentially, the same thing but using DI to inject 1 concrete type. I'm doing this because currently our configs are in a xml file but will be moved to a CMS, so seemed like a good idea to use an interface.
It seems wrong and not in the spirit of DI.
Should I use a factory to generate my various filters? If so, can I still leverage DI to get a concrete instance of my IArticleConfigurator?
You shouldn't pass parameters explicitly from one dependency to another or, at least, you should minimize their number. One big disadvantage of resolving instances with parameters is that you specify parameter names as string literals - which make you code very fragile in changes of constructor signature.
One example I might think of (note that I have no clue regarding your domain and responsibilities of entities) is to inject provider or, as you already said, factory. For example, create something like ITagListFilterConfigurationProvider (you should change the name as you want to, I just trying to give motivation). You might create very abstract provider like IFilterConfigurationProvider with three methods as below, if you have same parameters for filters:
interface ITagListFilterConfigurationProvider
{
string Caption { get; }
IDictionary<string,string> GetParameters();
bool IsDisplayInSummary { get; }
}
Now you constructor will look like:
public TagListFilter(ITagListFilterConfigurationProvider configurationProvider, IArticleConfigurator configurator)
All you need is to implement it as you already did (because you are passing concrete parameters to constructor) and extract this behaviour to provider. What is left - is to register concrete provider with StructureMap and resolve filter without passing any concrete parameters
var filter = StructureMap.ObjectFactory.GetInstance<TagListFilter>();
I'm trying to bind a XML response from a WS to a set of POJO's classes using ksoap2-android.
A lot of examples on the internet treat very simple responses like this one.
In my case however, I have a lot of custom classes and they keep a reference of each other, sometimes even inside an arraylist.
Here's what i'm trying to do, i would like to bind this kind of response :
<Car number="35">
<Engine>
[...]
</Engine>
<Passenger id="1">
[...]
</Passenger>
<Passenger id="2">
[...]
</Passenger>
</Car>
To this kind of class :
public class Car {
private int number;
private Engine engine;
private ArrayList<Passenger> passengers;
}
With, if possible, only modifying POJOs files (the Simple XML annotations system is very elegant, too bad there's no equivalent to this in ksoap).
I looked into the KVMSerializable interface, but when I try to override the getPropertyInfo() method, I have no idea of what I should return in the PropertyInfo.type and how will ksoap handle ArrayLists.
I got a huge headache right now, please help me
Please go to the below URL and read it.
http://www.c-sharpcorner.com/UploadFile/88b6e5/how-to-call-web-service-in-android-using-soap/
Thanks
Ashok Parmar
Traction Software Co.
You should read the document from ksoap 2, they have many useful examples in there.
For getting an array of complex type, you can check here
And I have used this approach to parse a complex object.
If all of them not work, you have to map field by field from soap object to your pojo.
Updated:
Thanks a lot for the 3rd link, it's very useful and I'm now able to
map custom objects. However, in the wiki page you provided, the author
is parsing an array of custom classes, wrapped in a parent element. Is
there a way to do this with inline lists like in my example ?
I have never tried it before, but I think you can combine my answer and the wiki.
First, you can try an example from wiki to implement your passengers list (extends Vector). Then you can use my approach to create a complex object with arraylist inside. The important thing is you must register your object with the response from web service. Something like this:
public class PassengerVector extends Vector<Passenger> implements KvmSerializable {
}
envelope.addMapping(NAMESPACE, "Car", Car.class);
envelope.addMapping(NAMESPACE, "Passenger", PassengerVector.class);
But I'm not sure this way can work. For a very complex object like your example, I recommend you should get data field by field by its name, as like the wiki
Here's the situation: I have an abstract class with a constructor that takes a boolean (which controls some caching behavior):
abstract class BaseFoo { protected BaseFoo(boolean cache) {...} }
The implementations are all generated source code (many dozens of them). I want to create bindings for all of them automatically, i.e. without explicit hand-coding for each type being bound. I want the injection sites to be able to specify either caching or non-caching (true/false ctor param). For example I might have two injections like:
DependsOnSomeFoos(#Inject #NonCaching AFoo aFoo, #Inject #Caching BFoo bFoo) {...}
(Arguably that's a bad thing to do, since the decision to cache or not might better be in a module. But it seems useful given what I'm working with.)
The question then is: what's the best way to configure bindings to produce a set of generated types in a uniform way, that supports a binding annotation as well as constructor param on the concrete class?
Previously I just had a default constructor on the implementation classes, and simply put an #ImplementedBy on each of the generated interfaces. E.g.:
// This is all generated source...
#ImplementedBy(AFooImpl.class)
interface AFoo { ... }
class AFooImpl extends BaseFoo implements AFoo { AFooImpl() { super(true); } }
But, now I want to allow individual injection points to decide if true or false is passed to BaseFoo, instead of it always defaulting to true. I tried to set up an injection listener to (sneakily) change the true/false value post-construction, but I couldn't see how to "listen" for a range of types injected with a certain annotation.
The problem I keep coming back to is that bindings need to be for a specific type, but I don't want to enumerate all my types centrally.
I also considered:
Writing some kind of scanner to discover all the generated classes and add a pair of bindings for each of them, perhaps using Google Reflections.
Creating additional, trivial "non caching" types (e.g. AFoo.NoCache extends AFoo), which would allow me to go back to #ImplementedBy.
Hard wiring each specific type as either caching/non-caching when it's generated.
I'm not feeling great about any of those ideas. Is there a better way?
UPDATE: Thanks for the comment and answer. I think generating a small module alongside each type and writing out a list of the modules to pull in at runtime via getResources is the winner.
That said, after talking w/ a coworker, we might just dodge the question as I posed it and instead inject a strategy object with a method like boolean shouldCache(Class<? extends BaseFoo> c) into each generated class. The strategy can be implemented on top of the application config and would provide coarse and fine grained control. This gives up on the requirement to vary the behavior by injection site. On the plus side, we don't need the extra modules.
There are two additional approaches to look at (in addition to what you mentioned):
Inject Factory classes instead of your real class; that is, your hand-coded stuff would end up saying:
#Inject
DependsOnSomeFoos(AFoo.Factory aFooFactory, BFoo.Factory bFooFactory) {
AFoo aFoo = aFooFactory.caching();
BFoo bFoo = bFooFactory.nonCaching();
...
}
and your generated code would say:
// In AFoo.java
interface AFoo {
#ImplementedBy(AFooImpl.Factory.class)
interface Factory extends FooFactory<AFoo> {}
// ...
}
// In AFooImpl.java
class AFooImpl extends BaseFoo implements AFoo {
AFooImpl(boolean caching, StuffNeededByAFIConstructor otherStuff) {
super(caching);
// use otherStuff
}
// ...
class Factory implements AFoo.Factory {
#Inject Provider<StuffNeededByAFIConstructor> provider;
public AFoo caching() {
return new AFooImpl(true, provider.get());
}
// ...
}
}
Of course this depends on an interface FooFactory:
interface FooFactory<T> {
T caching();
T nonCaching();
}
Modify the process that does your code generation to generate also a Guice module that you then use in your application setup. I don't know how your code generation is currently structured, but if you have some way of knowing the full set of classes at code generation time you can either do this directly or append to some file that can then be loaded with ClassLoader.getResources as part of a Guice module that autodiscovers what classes to bind.