Library project issue

[larten]

Hi,

I have 4 project.
common

model
service
view

view only see service, service only see model, all of these see common.
I put butterknife lib to common, set the annotations processing. In the view project i can use annotations, but eclipse say for @InjectView value: "The value for annotation attribute InjectView.value must be a constant expression"

@InjectView(R.id.toastviewcontainer)
ToastContainerView toastContainerView;

The .aptgenerated folder created and contains this:
"public class MainActivity$$ViewInjector {
public static void inject(Finder finder, hbogo.view.activity.MainActivity target, Object source) {
View view;
view = finder.findById(source, 0);
target.toastContainerView = (hbogo.view.toast.ToastContainerView) view;
}

public static void reset(hbogo.view.activity.MainActivity target) {
target.toastContainerView = null;
}
}"

How can I correctly use butterknife in library projects?

Sry my bad english ;)

[larten]

Ok, finally found this: #2

[JakeWharton]

There's simply no way to support this without compromising the safety of referring to the IDs as fields.

[CumpsD]

Any chance a way around this can be found? Using names instead of ids?

I am building a Library project with acitivities and fragments, using ButterKnife, to be included in multiple main .apk's, but I'm also faced with the non final id problem :/

[JakeWharton]

Using names is not compile- nor rename-safe, though.

[CumpsD]

Not being able to use Butterknife seems to be worse? ;)

[CumpsD]

Does this help, AndroidAnnotations has compile time checking:

https://github.com/excilys/androidannotations/wiki/Library-projects

RoboGuice took the "name" approach, using tags: https://code.google.com/p/roboguice/wiki/LibraryProjects

[JakeWharton]

It's not a technical problem (aside from the obvious lack of final values) but more of a style and preference. Supporting this has large implications on how the annotations are presented. They either have to be duplicated to two annotations each taking an ID or String, or they have to be updated to accept both an ID or String. The latter means that you cannot condense the annotation declaration to @Foo(R.id.bar) and @Foo("bar") because only a single value field is allowed. This also requires both fields have to have defaults which means the IDE no longer will require a value to be supplied pushing the burden of validation back onto this library.

[CumpsD]

I understand. Guess I'll have to learn one of those other 2 frameworks now :( Refactoring time ;)

[dbperez]

Are there any plans to add library support to Butterknife in the future?
We recently converted one of our projects using Butterknife into a library and unfortunately are having to refactor Butterknife out because of this.

[JakeWharton]

Highly unlikely. It compromises its greatest asset.

---

Jake Wharton
http://about.me/jakewharton

On Thu, Jan 30, 2014 at 2:19 PM, Bryan Perez notifications@github.hscsec.cnwrote:

Are there any plans to add library support to Butterknife in the future?
We recently converted one of our projects using Butterknife into a library
and unfortunately are having to refactor Butterknife out because of this.

Reply to this email directly or view it on GitHubhttps://github.com//issues/45#issuecomment-33740686
.

[jonneymendoza]

has this been resolved yet?

[JakeWharton]

No. And it probably never will be.

On Wed, Apr 15, 2015, 10:40 AM jonneymendoza notifications@github.com
wrote:

has this been resolved yet?

—
Reply to this email directly or view it on GitHub
#45 (comment)
.

[TimB0]

It can now be used in a library....view the readme