Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Actually, you have an error in your sample code. You have no injectable constructor - you cannot inject an instance method, only a constructor, and that method is never called. </p> <p>You should have:</p> <pre><code>public class XmlDataReader implements DataReader&lt;XmlPushable&gt; { protected final XmlPullParser mXmlPullParser; @Inject public XmlDataReader(XmlPullParser xmlPullParser) { mXmlPullParser = xmlPullParser; } } </code></pre> <p>This way it's a constructor, and will be properly injected. </p> <p>As to the overall approach, you're in the right direction. You <code>@Provide</code> <code>DataReader&lt;XmlPushable</code>, and effectively bind <code>XmlDataReader</code> to it in your provides method. So far so good. Dagger, when asked for <code>DataReader&lt;XmlPushable&gt;</code> will use that binding, and will effectively pass-through the dependency and provide <code>XmlDataReader</code> to satisfy this.</p> <p><code>XmlDataReader</code> has an <code>@Inject</code> annotated constructor, so Dagger's analysis will see it as an "injectable type" so you don't need an <code>@Provides</code> to provide it. As long as you either have an <code>XmlPullParser</code> that either has an <code>@Inject</code> annotated constructor or is provided in an <code>@Provides</code> method on a module, what you've coded here seems good, but is not quite complete.</p> <p>You don't have any entryPoints listed in your @Module, and you <strong><em>must</em></strong> have a class that will be the first thing you obtain from the ObjectGraph. So this code is reasonable as far as it goes, but incomplete. You need something that injects (through a field or constructor) <code>DataReader&lt;XmlPushable&gt;</code> For example, you might make a <code>FooActivity</code> which does this.</p> <p>Consider:</p> <pre><code>public class XmlDataReader implements DataReader&lt;XmlPushable&gt; { protected XmlPullParser mXmlPullParser; @Inject public XmlDataReader(XmlPullParser xmlPullParser) { mXmlPullParser = xmlPullParser; } } @Module(entryPoints = { FooActivity.class, BarActivity.class }) public class XmlServiceModule { @Provides DataReader&lt;XmlPushable&gt; provideDataReader(XmlDataReader dataReader) { return dataReader; } @Singleton @Provides XmlPullParserFactory parserFactory() { XmlPullParserFactory factory = XmlPullParserFactory.newInstance(); factory.setNamespaceAware(true); return factory; } @Provides XmlPullParser parser(XmlPullParserFactory factory) { XmlPullParser xpp = factory.newPullParser(); } } public class YourApp extends Application { private ObjectGraph graph; @Override public void onCreate() { super.onCreate(); graph = ObjectGraph.get(new ExampleModule(this)); } public ObjectGraph graph() { return objectGraph; } } public abstract class BaseActivity extends Activity { @Override protected void onCreate(Bundle state) { super.onCreate(state); ((YourApp) getApplication()).objectGraph().inject(this); } } class FooActivity extends BaseActivity { @Inject DataReader&lt;XmlPushable&gt; reader; @Override public void onCreate(Bundle bundle) { super.onCreate(bundle); // custom Foo setup } } class BarActivity extends BaseActivity { @Inject DataReader&lt;XmlPushable&gt; reader; @Override public void onCreate(Bundle bundle) { super.onCreate(bundle); // custom Bar setup } } </code></pre> <p>This is probably close to what you want. All things are reachable from an entry point, and all things you depend on are bound. The two Activities are your "entry points" (roots in the object graph). When they are initialized, they ultimately call the <code>ObjectGraph</code>'s <code>inject(Object)</code> method on themselves, which causes Dagger to inject any <code>@Inject</code> annotated fields. Those fields are the <code>DataReader&lt;XmlPushable&gt;</code> fields, which is satisfy by XmlDataReader, which is provided with an XmlPullParser, which is provided by using a XmlPullParser. It all flows down the dependency chain.</p> <p>Small note - <code>@Module(complete=true)</code> is the default. You don't need to specify complete, unless it's incomplete and you specify <code>false</code></p>
    singulars
    1. This table or related slice is empty.
    1. PODagger and dependecies on provided classes
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USChristian Gruber
    1. USChristian Gruber
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODagger and dependecies on provided classes
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COCrap - there's an actual error in the sample code, and I misread it. Leaving this here because it's a decent example of what he was trying to do.
      singulars
      1. PO
      1. USChristian Gruber
    2. COThanks for this extensive answer. I haven't seen the typo there...damn it! That error was really weird..it was perfect working on the object's field. About the entryPoint, the activity and the (complete=true): I actually have all of them in my original code (by the way, I wouldn't change "entryPoint", it is self-explanatory when talking about object graphs), and I left (complete=true) just to remind to myself that the feature is on :) I will remove the @Provide for DataReader<XmlPushable> then...not too much time spent here (starting from no DI to Dagger), that's good!
      singulars
      1. PO
      1. USAndrea Richiardi
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload