DroidParts - library for Android 8-in-1

With this article I open the cycle dedicated to the development of Android applications. But not typical of Google Play, written, obviously, the back of the left foot, and the applications are correct and elegant. DroidParts - the Swiss knife of Android libraries with 8 edges will help us with this business:

1. Dependency Injection : initialization of system and own dependencies;
2. Object-Relational Mapping for SQLite: CRUD operations out of the box;
3. Support Fragments , ActionBar Sherlock;
4. Simple (de) serialization of JSON ;
5. AsyncTasks, IntentService with processing exceptions;
6. RESTful HTTP client with JSON support;
7. L. og without a tag, configurable via AndroidManifest;
8. Utilities such as asynchronous http-loader with caching, View- and Intent-helpers.

Literally an hour ago * the first version of the library was published, but first ...

For a long time I was an adherent of the old school approach with code in the style:

 private Button btn; onCreate(Bundle b) { super.onCreate(b); btn = (Button)findViewById(R.id.btn); } 

Until then, did not participate in the project that used RoboGuice. And after:
')

 @InjectView private Button btn; 

voluntary return was not.

On the other hand, RoboGuice was unnerving in size and in any way unreleased version 2.0 with Fragments support. And also, for ORM, a third-party library was needed. And Gson to simplify working with JSON. Wrong it, pull dependencies into several application sizes.

In general, following the principle of " if you want something done right, do it yourself, " I proceeded with just for fun .

What came out of this is available in version 0.5 at github.com/yanchenko/droidparts and consists of:

• base - DI, ORM, Activities and other key components;
• extra - optional RESTful client and various utilities;
• support-actionbarsherlock - support for Fragments, ActionBar and tabs in conjunction with the default ActionBarSherlock ;
• sample is a “sample” application.

From consideration of the last we will begin.

To start doing git clone github.com/yanchenko/droidparts.git git clone github.com/yanchenko/droidparts.git and import Eclipse projects from base , extra , sample .
The first two of them are libraries (Android library project).
In the project.properties latter, which is a full-fledged application, pay attention to the line proguard.config=../proguard.cfg , which indicates the modified configuration of the obfuscator used when exporting to .apk.

Although DroidParts contains a custom org.droidparts.Application , it only makes sense to inherit from it if the injection is needed in the Application itself. There is no need for a simple application. But you need an injection of your own dependencies.
In the AndroidManifest.xml line:

 <meta-data android:name="droidparts_dependency_provider" android:value=".DependencyProvider" /> 

declares a class that inherits org.droidparts.inject.AbstractDependencyProvider and is a factory of the objects we need.

The scheme is simple: each DependencyProvider method returns an instance of one of the classes available for injection. Two types of methods are supported: called without parameters and with a single Context parameter. In the case when the injection is made in the Activity, the Context will be transmitted to it, which is important for dependencies related to the UI.

Code examples, incl. how singles are realized (singletons, ahaha, I adore terms in translation), you can look directly at org.droidparts.sample.DependencyProvider .
For the injection of system resources and services, additional methods, of course, are not needed.

The injection itself is made for the fields annotated by @Inject... when calling one of the methods Injector.get().inject(...) . Manual call can be skipped, inheriting from Activity , Service , etc. from org.droidparts .
The org.droidparts.sample.activity.EntryListActivity application is an example of this approach.
Pay attention to:

  @Override public void onPreInject() { setContentView(R.layout.activity_entry_list); } 

All calls to onCreate(...) will occur after the Injector has completed. In this case, this would result in an unidentified View s.

On this chaotic understatement, I conclude the introductory article. Examples of DI, ORM and JSON serialization sufficient to begin using the library are in the application. Detailed consideration and best practices is a topic for further articles.
In the near future I will tell you how to replace your own constructors for the Activity (hint: there is this pattern in the application).

I will answer questions here or there: stackoverflow.com/questions/tagged/droidparts .

Thank you, and please write less code! (:

* as of yesterday evening.