2

Situation
I have a BaseActivity from which I extend other activities. In the BaseActivity I have a findCastedViewById which basicaly casts the view and then returns it.
I do this because I, personaly, find it ugly casting the view all the time.

Question
I was wondering if there is any problem or cons that I could get from using this approach that anybody else using this method had.
Here is BaseActivity:

BaseActivity.java

public class BaseActivity extends Activity{

  //Other stuff

  private <E extends View> E findCastedViewById(int id){
          return (E) findViewById(id);
  }

  //Other stuff
}
Sid
  • 14,176
  • 7
  • 40
  • 48

4 Answers4

4

Consider using ButterKnife, it solves the problem of having to continuously cast your views and it saves you a lot of time

Once you go butterknife, there's no way back

Basically you annotate the View variables with

@FindView annotation and it will find the correct view for you when ButterKnife.bind(this) is called

Here's a small snippet of code where ButterKnife is used from the GitHub Page

class ExampleActivity extends Activity {
  @FindView(R.id.user) EditText username;
  @FindView(R.id.pass) EditText password;

  @OnClick(R.id.submit) void submit() {
    // TODO call server...
  }

  @Override public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.simple_activity);
    ButterKnife.bind(this);
    // TODO Use fields...
  }
}

You can read more about ButterKnife from here

Pasi Matalamäki
  • 1,843
  • 17
  • 14
  • I just had a quick look at ButterKnife and yes it is very useful and basically solves the problem very well so +1 for you but this is not the answer I was looking for, I was wondering the cons of the method I was using! – Sid May 05 '15 at 11:54
3

As lukaspp already noted, in SDK 26+ there is no need for vew casting.

They have implemented the same code as in the question, except it is now the default findViewById(). So yes OP, your code is good!

N. Matic
  • 46
  • 3
  • Welcome to [so]! This should have been a comment, not an answer. With a bit more rep, [you will be able to post comments](http://stackoverflow.com/privileges/comment). – lucascaro Oct 30 '18 at 20:29
1

As explained in this answer, if you compileSdk is at least API 26, you don't need to cast the view anymore.

lukaspp
  • 1,059
  • 10
  • 15
-3

It's not only ugly but also an expensive operation if you repeat it constantly.

If you are sure you will always need that specific derived class, you can freely use it. However, I sometimes find I only need methods from the base class View, e.g. setVisibility(), in such occasions casting would be a waste.

Simas
  • 43,548
  • 10
  • 88
  • 116
  • 2
    Can you please update the answer and explain why it would be an expensive operation? – Sid May 05 '15 at 12:05
  • @Assa this is common java knowledge and it was [answered](http://stackoverflow.com/questions/2170872/does-java-casting-introduce-overhead-why) before. – Simas May 05 '15 at 12:09
  • So if I got it right my method can be expensive because of the castings? – Sid May 05 '15 at 12:33
  • 1
    First, read a comment accessible by the link: this is old information, casts are faster now. Second, the problem is not in generic findView, but in using concrete types. The question is about the situation when vague types cannot be used, so the answer is wrong. – Miha_x64 Feb 15 '17 at 10:40