Why creating a new variable and using it when you can use the old variable?
Why do we need to :-
- Create a View x.
- Then set x = a
Then use a if command on x if you can directly use a.
@Override
public View getView(int position, View convertView, ViewGroup parent) {
// check if the current view is reused else inflate the view
View listItemView = convertView;
if(listItemView == null){
listItemView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
Instead , Why can't we do this?
@Override
public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null){
convertView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
java

add a comment |
Why do we need to :-
- Create a View x.
- Then set x = a
Then use a if command on x if you can directly use a.
@Override
public View getView(int position, View convertView, ViewGroup parent) {
// check if the current view is reused else inflate the view
View listItemView = convertView;
if(listItemView == null){
listItemView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
Instead , Why can't we do this?
@Override
public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null){
convertView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
java

Not recommented to change the original data.
– hesam
Dec 29 '18 at 13:09
add a comment |
Why do we need to :-
- Create a View x.
- Then set x = a
Then use a if command on x if you can directly use a.
@Override
public View getView(int position, View convertView, ViewGroup parent) {
// check if the current view is reused else inflate the view
View listItemView = convertView;
if(listItemView == null){
listItemView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
Instead , Why can't we do this?
@Override
public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null){
convertView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
java

Why do we need to :-
- Create a View x.
- Then set x = a
Then use a if command on x if you can directly use a.
@Override
public View getView(int position, View convertView, ViewGroup parent) {
// check if the current view is reused else inflate the view
View listItemView = convertView;
if(listItemView == null){
listItemView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
Instead , Why can't we do this?
@Override
public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null){
convertView = LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
}
java

java

edited Dec 29 '18 at 14:34


Fantômas
32.4k156388
32.4k156388
asked Dec 29 '18 at 13:05


Sarvesh ThiruppathiSarvesh Thiruppathi
676
676
Not recommented to change the original data.
– hesam
Dec 29 '18 at 13:09
add a comment |
Not recommented to change the original data.
– hesam
Dec 29 '18 at 13:09
Not recommented to change the original data.
– hesam
Dec 29 '18 at 13:09
Not recommented to change the original data.
– hesam
Dec 29 '18 at 13:09
add a comment |
3 Answers
3
active
oldest
votes
First and second examples are valid. Only if first case you are creating an local copy of your class variable. It is useless. Why are developers doing this way? Who knows :)
About inflating. Inflate operations some expensive, cause your adapter items are simular, it is possible to inflate view only once.
Thanks, Can you elaborate on "Inflate operations some expensive"
– Sarvesh Thiruppathi
Dec 29 '18 at 13:19
See here lucasr.org/2012/04/05/performance-tips-for-androids-listview, so detailed with images.
– Dmitro Ivanov
Dec 29 '18 at 13:24
add a comment |
The second option also works perfectly. I don't know why you think you can't do that.
Just make sure you return convertView
after doing other stuffs inside there.
Can you explain a little more , like why the second code is also valid.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:09
It is valid because it works. Can you explain a little more, like why the second code is not valid?
– Nabin Bhandari
Dec 29 '18 at 13:09
I didn't say that the second code is not valid. what I meant was the first code is a common practice I have seen many developers do. My actual question is why create a useless variable which you don't even need.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:11
1
You've asked "Why can't we do this?" and I said you can do that too. There are multiple ways of doing same thing. Both ways are perfectly valid. I have no answer why developers prefer first one. I prefer the second one though.
– Nabin Bhandari
Dec 29 '18 at 13:16
add a comment |
As the develeoper in some cases wanted to assign a value LayoutInflater.from(...).inflate(...)
, different from the argument convertView
, he chose not to overwrite the argument, but to introduce a new variable. It's good style not to modify method arguments.
So, in the case that convertView
is null, listItemView
gets a value from the LayoutInflater
call, to be used further down the method. And the fact that the method was called with a null
argument is still visible.
As a more concise alternative, this can be done using Java's ternary operator:
View listItemView = convertView != null ?
convertView :
LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
This way the variable can even be declared final
.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53969798%2fwhy-creating-a-new-variable-and-using-it-when-you-can-use-the-old-variable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
First and second examples are valid. Only if first case you are creating an local copy of your class variable. It is useless. Why are developers doing this way? Who knows :)
About inflating. Inflate operations some expensive, cause your adapter items are simular, it is possible to inflate view only once.
Thanks, Can you elaborate on "Inflate operations some expensive"
– Sarvesh Thiruppathi
Dec 29 '18 at 13:19
See here lucasr.org/2012/04/05/performance-tips-for-androids-listview, so detailed with images.
– Dmitro Ivanov
Dec 29 '18 at 13:24
add a comment |
First and second examples are valid. Only if first case you are creating an local copy of your class variable. It is useless. Why are developers doing this way? Who knows :)
About inflating. Inflate operations some expensive, cause your adapter items are simular, it is possible to inflate view only once.
Thanks, Can you elaborate on "Inflate operations some expensive"
– Sarvesh Thiruppathi
Dec 29 '18 at 13:19
See here lucasr.org/2012/04/05/performance-tips-for-androids-listview, so detailed with images.
– Dmitro Ivanov
Dec 29 '18 at 13:24
add a comment |
First and second examples are valid. Only if first case you are creating an local copy of your class variable. It is useless. Why are developers doing this way? Who knows :)
About inflating. Inflate operations some expensive, cause your adapter items are simular, it is possible to inflate view only once.
First and second examples are valid. Only if first case you are creating an local copy of your class variable. It is useless. Why are developers doing this way? Who knows :)
About inflating. Inflate operations some expensive, cause your adapter items are simular, it is possible to inflate view only once.
answered Dec 29 '18 at 13:16


Dmitro IvanovDmitro Ivanov
66348
66348
Thanks, Can you elaborate on "Inflate operations some expensive"
– Sarvesh Thiruppathi
Dec 29 '18 at 13:19
See here lucasr.org/2012/04/05/performance-tips-for-androids-listview, so detailed with images.
– Dmitro Ivanov
Dec 29 '18 at 13:24
add a comment |
Thanks, Can you elaborate on "Inflate operations some expensive"
– Sarvesh Thiruppathi
Dec 29 '18 at 13:19
See here lucasr.org/2012/04/05/performance-tips-for-androids-listview, so detailed with images.
– Dmitro Ivanov
Dec 29 '18 at 13:24
Thanks, Can you elaborate on "Inflate operations some expensive"
– Sarvesh Thiruppathi
Dec 29 '18 at 13:19
Thanks, Can you elaborate on "Inflate operations some expensive"
– Sarvesh Thiruppathi
Dec 29 '18 at 13:19
See here lucasr.org/2012/04/05/performance-tips-for-androids-listview, so detailed with images.
– Dmitro Ivanov
Dec 29 '18 at 13:24
See here lucasr.org/2012/04/05/performance-tips-for-androids-listview, so detailed with images.
– Dmitro Ivanov
Dec 29 '18 at 13:24
add a comment |
The second option also works perfectly. I don't know why you think you can't do that.
Just make sure you return convertView
after doing other stuffs inside there.
Can you explain a little more , like why the second code is also valid.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:09
It is valid because it works. Can you explain a little more, like why the second code is not valid?
– Nabin Bhandari
Dec 29 '18 at 13:09
I didn't say that the second code is not valid. what I meant was the first code is a common practice I have seen many developers do. My actual question is why create a useless variable which you don't even need.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:11
1
You've asked "Why can't we do this?" and I said you can do that too. There are multiple ways of doing same thing. Both ways are perfectly valid. I have no answer why developers prefer first one. I prefer the second one though.
– Nabin Bhandari
Dec 29 '18 at 13:16
add a comment |
The second option also works perfectly. I don't know why you think you can't do that.
Just make sure you return convertView
after doing other stuffs inside there.
Can you explain a little more , like why the second code is also valid.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:09
It is valid because it works. Can you explain a little more, like why the second code is not valid?
– Nabin Bhandari
Dec 29 '18 at 13:09
I didn't say that the second code is not valid. what I meant was the first code is a common practice I have seen many developers do. My actual question is why create a useless variable which you don't even need.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:11
1
You've asked "Why can't we do this?" and I said you can do that too. There are multiple ways of doing same thing. Both ways are perfectly valid. I have no answer why developers prefer first one. I prefer the second one though.
– Nabin Bhandari
Dec 29 '18 at 13:16
add a comment |
The second option also works perfectly. I don't know why you think you can't do that.
Just make sure you return convertView
after doing other stuffs inside there.
The second option also works perfectly. I don't know why you think you can't do that.
Just make sure you return convertView
after doing other stuffs inside there.
answered Dec 29 '18 at 13:08
Nabin BhandariNabin Bhandari
9,32031636
9,32031636
Can you explain a little more , like why the second code is also valid.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:09
It is valid because it works. Can you explain a little more, like why the second code is not valid?
– Nabin Bhandari
Dec 29 '18 at 13:09
I didn't say that the second code is not valid. what I meant was the first code is a common practice I have seen many developers do. My actual question is why create a useless variable which you don't even need.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:11
1
You've asked "Why can't we do this?" and I said you can do that too. There are multiple ways of doing same thing. Both ways are perfectly valid. I have no answer why developers prefer first one. I prefer the second one though.
– Nabin Bhandari
Dec 29 '18 at 13:16
add a comment |
Can you explain a little more , like why the second code is also valid.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:09
It is valid because it works. Can you explain a little more, like why the second code is not valid?
– Nabin Bhandari
Dec 29 '18 at 13:09
I didn't say that the second code is not valid. what I meant was the first code is a common practice I have seen many developers do. My actual question is why create a useless variable which you don't even need.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:11
1
You've asked "Why can't we do this?" and I said you can do that too. There are multiple ways of doing same thing. Both ways are perfectly valid. I have no answer why developers prefer first one. I prefer the second one though.
– Nabin Bhandari
Dec 29 '18 at 13:16
Can you explain a little more , like why the second code is also valid.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:09
Can you explain a little more , like why the second code is also valid.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:09
It is valid because it works. Can you explain a little more, like why the second code is not valid?
– Nabin Bhandari
Dec 29 '18 at 13:09
It is valid because it works. Can you explain a little more, like why the second code is not valid?
– Nabin Bhandari
Dec 29 '18 at 13:09
I didn't say that the second code is not valid. what I meant was the first code is a common practice I have seen many developers do. My actual question is why create a useless variable which you don't even need.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:11
I didn't say that the second code is not valid. what I meant was the first code is a common practice I have seen many developers do. My actual question is why create a useless variable which you don't even need.
– Sarvesh Thiruppathi
Dec 29 '18 at 13:11
1
1
You've asked "Why can't we do this?" and I said you can do that too. There are multiple ways of doing same thing. Both ways are perfectly valid. I have no answer why developers prefer first one. I prefer the second one though.
– Nabin Bhandari
Dec 29 '18 at 13:16
You've asked "Why can't we do this?" and I said you can do that too. There are multiple ways of doing same thing. Both ways are perfectly valid. I have no answer why developers prefer first one. I prefer the second one though.
– Nabin Bhandari
Dec 29 '18 at 13:16
add a comment |
As the develeoper in some cases wanted to assign a value LayoutInflater.from(...).inflate(...)
, different from the argument convertView
, he chose not to overwrite the argument, but to introduce a new variable. It's good style not to modify method arguments.
So, in the case that convertView
is null, listItemView
gets a value from the LayoutInflater
call, to be used further down the method. And the fact that the method was called with a null
argument is still visible.
As a more concise alternative, this can be done using Java's ternary operator:
View listItemView = convertView != null ?
convertView :
LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
This way the variable can even be declared final
.
add a comment |
As the develeoper in some cases wanted to assign a value LayoutInflater.from(...).inflate(...)
, different from the argument convertView
, he chose not to overwrite the argument, but to introduce a new variable. It's good style not to modify method arguments.
So, in the case that convertView
is null, listItemView
gets a value from the LayoutInflater
call, to be used further down the method. And the fact that the method was called with a null
argument is still visible.
As a more concise alternative, this can be done using Java's ternary operator:
View listItemView = convertView != null ?
convertView :
LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
This way the variable can even be declared final
.
add a comment |
As the develeoper in some cases wanted to assign a value LayoutInflater.from(...).inflate(...)
, different from the argument convertView
, he chose not to overwrite the argument, but to introduce a new variable. It's good style not to modify method arguments.
So, in the case that convertView
is null, listItemView
gets a value from the LayoutInflater
call, to be used further down the method. And the fact that the method was called with a null
argument is still visible.
As a more concise alternative, this can be done using Java's ternary operator:
View listItemView = convertView != null ?
convertView :
LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
This way the variable can even be declared final
.
As the develeoper in some cases wanted to assign a value LayoutInflater.from(...).inflate(...)
, different from the argument convertView
, he chose not to overwrite the argument, but to introduce a new variable. It's good style not to modify method arguments.
So, in the case that convertView
is null, listItemView
gets a value from the LayoutInflater
call, to be used further down the method. And the fact that the method was called with a null
argument is still visible.
As a more concise alternative, this can be done using Java's ternary operator:
View listItemView = convertView != null ?
convertView :
LayoutInflater.from(getContext()).inflate(R.layout.list_item, parent, false);
This way the variable can even be declared final
.
answered Dec 29 '18 at 14:39
Ralf KleberhoffRalf Kleberhoff
3,630156
3,630156
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53969798%2fwhy-creating-a-new-variable-and-using-it-when-you-can-use-the-old-variable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Not recommented to change the original data.
– hesam
Dec 29 '18 at 13:09