Are you think about injections like roboguice InjectView and other? about dagger

[JakeWharton]

No. View injection is not actually dependency injection it's just a convenience wrapper around calling findViewById and doing an implicit cast. A feature like this requires activities to extend from a common base class provided by the library which is a really bad thing to have to enforce. This is also further crippled by the fact that the constants in the R.java class are no longer final for library projects and thus cannot be used in annotations.

You could very easily write something to do this yourself since it doesn't actually require any libraries. Just create an annotation and in your common activity base class iterate over them and call findViewById. Another way which creates a cleaner looking onCreate method is just to have an implicit-casting version of findViewById like this:

/**
 * Finds a view that was identified by the id attribute from the XML that was processed in
 * {@link #onCreate(Bundle)} and performs an unchecked cast to the destination type.
 *
 * @param id View ID.
 * @param <T> Destination cast class type.
 * @return The view if found or {@code null} otherwise.
 */
@SuppressWarnings("unchecked")
public <T extends View> T findById(int id) {
  return (T) findViewById(id);
}

and then your onCreate becomes:

setContentView(R.layout.whatever);
TextView tv = findById(R.id.title);
SomeCustomView scv = findById(R.id.custom_view)

[mecid]

Thanks man!

[staxgr]

I wrote the something exactly the same as the first suggestion from Jake a few months ago. It's just a couple of lines, feel free to copy it https://github.com/staxgr/ViewInject/blob/master/src/se/tap2/viewinject

[JakeWharton]

@staxgr If you switch the annotation's properly to value it will be implicitly assigned and then you can do @InjectView(R.id.whatever).

[christopherperry]

@JakeWharton Wouldn't doing something like this violate one of the main reasons for using Dagger (avoiding the use of reflection in favor of compile time annotation processing)? I know casting the findViewById calls sucks, but your workaround is palatable in comparison.

[JakeWharton]

Dagger is for dependency injection satisfied by code-gen and compile-time graph verification. View "injection" has nothing to do with dependencies and is merely made to emulate actual injection. I think myself and most would recommend the findById approach.

The @InjectView part above was just to demystify what it does. Someone could very easily create a tiny, standalone library that does code-gen for all @InjectView annotations and then satisfies them by calling Views.inject(this) on an activity or fragment.

[christopherperry]

@JakeWharton I understand that, I'm just pointing out that what staxgr wrote is not the approach one would want to take when using Dagger because it doesn't do code-gen, it uses reflection.

[JakeWharton]

The @InjectView part above was just to demystify what it does. Someone could very easily create a tiny, standalone library that does code-gen for all @InjectView annotations and then satisfies them by calling Views.inject(this) on an activity or fragment.

I wrote this last night in a one-off experimentation with code generation for another project: http://github.com/JakeWharton/butterknife/

[cgruber]

On 5 Mar 2013, at 13:38, Jake Wharton wrote:

I wrote this last night in a one-off experimentation with code
generation for another project:
http://github.com/JakeWharton/butterknife/

Heh. Butter-knife. Awesome.

[christopherperry]

@JakeWharton Domo arigato Sensei.