-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Butter knife for view injection. #550
Comments
@getsanjeev interesting! Since the UI is going to be materialised (or at least a good part of it) let me know if I can work on this after this issue is discussed with @lognaturel and @grzesiek2010 |
@UrjaPawar Let it be reviewed first. : |
I think this discussion needs to be coupled with #544. The first question is whether we want to introduce any of these kinds of tools. Then the next one is at what level (full dependency injection vs. view injection... recognizing that they can work together). A valid answer might be "yes but later". Then there's a specific tool question. I think that for view injection at least AndroidAnnotations needs to be considered as well. |
I've seen AndroidAnnotations but haven't used it. My impression (admittedly based on no experience and limited investigation both now and in the past) is that it can help you eliminate boilerplate, but that you really have to buy in. In my opinion:
Before: public class MyActivity extends Activity {
protected TextView textView;
@Override
public void onCreate(Bundle bundle) {
super.onCreate(bundle);
this.textView = (TextView) findViewById(R.id.textView);
}
} After: public class MyActivity extends Activity {
@BindView(R.id.textView) TextView textView;
@Override
public void onCreate(Bundle bundle) {
super.onCreate(bundle);
Butterknife.bind(this);
}
} When you have a lot of views, this eliminates a lot of code. I don't know what the implications are for Collect, at least for form entry, where views in the form wouldn't be available at compile time. For the non-dynamic Activities I think it would work well. I'd say Dagger is too big a change right now, especially with lots of people new to the codebase, but could make sense down the road if people feel it's needed. Android Annotations is a different approach to writing apps that would also be a big change. Maybe people that have used it can argue for it, but if it were only me I'd be hesitant to adopt it. I'm not familiar with any large projects that use it. Butterknife is much more lightweight. Most of my projects use it now, and I think if people wanted to introduce it as they made changes to different pieces of code I think it would be fine. |
@srsudar Perfect answer. In case we go for Butterknife, we need to decide how exactly we go about the change. |
@getsanjeev @srsudar @lognaturel |
To the best of my understanding, Dagger 2 (unlike Dagger 1) does most of its work at compile time generating regular Java code. I don't believe that most of what they do is at runtime. It was my understanding that Butterknife takes a similar approach, as described here. I don't think a performance hit from Butterknife is something to be afraid of. I am +0 for Butterknife. |
@lognaturel How should we go about this? |
Let's postpone this decision to avoid making too many invasive changes at once. If students want to include something like adding Butterknife to their GSoC project proposal and explain why it would help with the project, that would be great too. |
Any update on this one? I have used Butterknife in many of my projects and I feel I can be of help here. |
@VisheshVadhera Thanks for your interest in this discussion! @shobhitagarwal1612 is working on a refresh to the user experience as part of his Google Summer of Code project. You can check out his project proposal and timeline. He's making some pretty far-reaching changes in that context and I think that while that project is ongoing, it makes sense to limit other changes to the UI code unless he thinks they're the right thing to do in parallel. Beyond that, I think there's more to discuss before we can be in a position to say yes or no to Butterknife or other related options. @srsudar gave a good overview of different options that have been discussed as possible alternatives here. Another thing I realized might be worth also consideration is the Android Data Binding libs. Again, not something I personally have experience with but I think it's worth considering in what ways it may be more or less advantageous than Butterknife in this context. Relatedly, we never made much progress on #506 and talking about patterns and code structure at a high level but I think it's very much related to this discussion. If anyone is interested in reviving it, the forum's development topic would now be a better place for it since it's a more open-ended discussion. |
That proposal looks like an awesome update to the UI @shobhitagarwal1612! |
I think the Android Data Binding would be better. Why do we need the Butterknife? I think in most cases we would use that only to get rid of findViewById and looks like thanks to the Android Data Binding we can do that using even less code than using the Butterknife. Here is a good comparison for those who don't know those tools https://www.youtube.com/watch?v=JsSkhR2rFzI But looks like Kotlin is the best here. Look here at this example: grzesiek2010@ab9ca5d |
@lognaturel We are using both dagger and butter knife so this issue can be closed too. |
We already use Butterknife so we can close this issue. |
Most of the projects are using Butter Knife for view injection. It would be really good if we incorporate it. It allows us to perform injection on arbitrary objects, views and OnClickListeners i.e makes life easier.
Reference : http://jakewharton.github.io/butterknife/
The text was updated successfully, but these errors were encountered: