I'm new to android development and I see there are 2 different ways to make a button perform a specific task.
The 1st way is to have a setOnClickListener() within your onCreate function.
The 2nd is to create a separate method in its Activity page and call it using the activity's XML using android:onClick="thisFunction"
I have always found it easier to call functions using android:onClick in the XML.
Would this way make the buttons perform slower?
When would you experts prefer one way over another?
In my opinion, it's always better to set the onClick in the code, since the xml way only works well with activities. When you try to do that with fragments, it will ask you to choose an activity to handle the onClick() from the xml. Imagine having a single activity app, with lots of fragments, and having all of it's onClick() methods spread across the MainActivity code. It's quite a mess.
Regarding performance setOnClickListener() vs onClick() inside xml, I think it's pretty much the same nowadays.
Related
Rather than using a single onClick() method for all the buttons in an Activity, and then using the switch statement to determine which button was clicked, I set different methods for different buttons in the
android:onClick
XML parameter. For example, for one button I set the onClick parameter to onClickCalculateButton
and for another button I set the onClick XML parameter to onClickNewFileButton.
Is this a good coding practice?
There is no real convention in this case. I've seen good programmers do it this way or the other, and I'm guessing most people agree.
For buttons that are not straight forward (not in activity/fragment) and cant be used with ButterKnife I don't set the click listener in XML rather then implementing it at a specific class (activity/fragment/whatever) with switch-case and then referring to the specific method.
switch(view.getId()){
case R.id.button_one:
clickOnButtonOne(view);
break; ...
For buttons that I know their lifecycle (in fragment/activity) I use ButterKnife and use it annotation (
#OnClick(R.id.button)
I would avoid using the android:onClick param in XML. As projects become larger it becomes more difficult to manage, especially when you are dealing with Fragments.
I follow the same convention you do for naming, but I create separate onClickListener classes for each button within the Activity or Fragment. Makes it easier for me to track which button does what as I can follow its source through Android Studio from onCreate.
However, you might be using the XML tags for the same reason I would which is creating less code. If that is the case, I would look into using ButterKnife (http://jakewharton.github.io/butterknife/). It uses annotations to generate the needed code later and is super clean.
Im looking through a project here and it has a way of using onClick that is different to what ive seen any other time.
Usually you set the listener for the button during onCreate or whatever.
Here in the activities xml it has android:onClick="navigateToUrl". Then this seems to kick off the method navigateToUrl in the classes code.
Im just wondering what is the difference between the two methods?
They work the same way. With the xml version, the framework adds an onClickListener during inflation that uses reflection on the Context its called from looking for a function with that name, and calls it. So its slightly less efficient, but not enough to really get worried about. The big advantage is a less cluttered onCreate, the big disadvantage is that to figure out what a view does when clicked you have to read xml rather than code. Which you use is a matter of personal preference. I'm currently in the explicit onClickListener group, because I prefer not to have behind the scenes magic.
For the latter, you need to keep a public method always. If you do not want to keep your method publicly visible, you would prefer to have a listener implemented.
I am using setContentView(R.layout.main) to switch the views in the same activity. I am calling some asynchronous task and populating the data on the main layout file after that I am changing the view by calling setContentView(R.layout.main) method.
I came to know that we should not use setContentView method multiple times for same activity. Though it is working fine for me.
Can anyone explain why we should not use setContentView method multiple times for the same activity to change the views?
Will it create any memory related exceptions? Could someone please clarify?
I think switching Views is not a good idea, because android platform already have strong framework to handle the transition in between the views and maintaining the state of each view associated with the Activity its always better to stick with the existing framework instead of thinking of some complex implementation that you have to go through to do all these things. If you do not need any of these things to taken care in your application and if only if you have only two or three screen in your entire application you can try switching the views. That even based on how your views are structured if you have complex logic and lot of data needed to create these views this wont be a good way of doing it.One more thing if you are adding more views say functionality to your application the load that need to be handled by the Activity will go high. In this case you will be declaring and initializing all views inside that particular Activity so maintaining all these views instances is heavy. If you want to know more about the Activty and Task kindly refer this link
Well every time you call setContentView() you'll have to find all the layouts again besides that I think you "can" do it. But as discussed here this is ill adviced as it clearly goes against the android guidelines. Also Commonsware have some very important points here one of the most important being that you will be prone to leak memory as you forget to clean up stuff from your views etc. which Android normally would handle for you.
In short you should follow Android guidelines and use Fragments or start a new Activity.
According to the developer docs setContentView(int layoutResID) is used to
Set the activity content from a layout resource. The resource will be inflated, adding all top-level views to the activity.
In best practice this method is used to Inflate your Activity layout on start up. This does not mean that it will cause issues in the future if you keep using this method. To quote a answer in this question
The setContentView on your Activity actually calls the setContentView on the Window used by the activity, which itself does a lot more than just inflating the layout.
I suggest that you find a alternative way to switch layouts like using a ViewPager with Fragments or some other Tabbing approach but in the end it all comes down to what you want to do.
This question might also give you what you're looking for.
With so many ways of implementing an OnClickListener within Android, I'm wondering whether there's a best practice or a more recommended way of doing it over the others (ie: I remember reading certain ways require more memory than others)?
At the moment I know of four ways to implement the OnClickListener, these are:
Make your Activity implement an OnClickListener interface.
Inner Class OnClickListener.
Inline Class OnClickListener.
Use android:onClick attribute in XML definition of a Button.
Out of the four options I'm leaning towards the XML implementation as it seems cleaner, can anyone else give their opinion?
I don't know regarding memory efficiency, but Here's my approach.
I don't like it, It requires multiple if-else (or switch) inside your onClick if you have multiple buttons
I use this if the 3rd option causes my method, for example onCreate() to be too big and messy
My favorite. it allows you to find out what each button does very easily, but I use it usually if its onClick isn't too long, to keep the code readable
I hardly use it, it keeps the code cleaner, but I'm not used to this one, since I don't use it in Java's SWING.
But in the bottom line, like #Lazy_Ninja said, it all comes down to taste. All 4 of them works.
I think what matters, when choosing, is keeping the code clean and readable.
Well it depends. At first I used to like the number 1(Make your Activity implement an OnClickListener interface) because the source look neat that way. But at the end I settled with 2.Inner Class OnClickListener, because I found it more easier to read and more easier to implement, especially if you use eclipse and know the shortcuts of auto completion.
At the end I think it depends on taste.
On my application I'm developing, the main.xml layout (the default layout of my app) has a few buttons that have been assigned onClickListeners (not the implementation way).
One of those buttons I want to have the ability to take you to another view. On the other view (preview.xml), there's another button that takes you back to the main.xml view.
I've used setContentView in the onClickListeners of those buttons and this works fine so far, but after you click the button that takes you back to main.xml, the buttons on main.xml have lost their onClick functionalities.
How can I get this to work right? I presume using setContentView isn't the right way to do this.
Your best bet, at Konstantin says above is to use Activities, as you will come across these a lot whilst developing for android. you can read about them here Activities. I assume you want to pass something onto the preview.xml page? If so, I'd recommend either putting it as an extra in the Intent used to start the activity (see the link) or creating a static reference in the activity (which you set before you launch it).
I'd say use two different activities and switch between them. Another option can be ViewSwitcher.