• 0

[Java / Android] OnClick event, get the sender ID / tag


Question

First of all, my Java is fairly rusty (just started using again after a 6 year hiatus). I am working on this for Android 2.1

Goal:

I have multiple buttons, they all perform the same task, but with different data pulled from an array. For example, button1, button2, button3. I want to use the same onClick for all of them so they share the same code base. if button1 is clicked, text1 is updated, etc

The problem:

I can't figure out how to determine which of the buttons triggered the onClick event. I have seen references to getTag, and getId, but when I check what those contain while debugging, its always empty.

Is there a way to either get the button name in onClick, or maybe a way to pass it another parameter so I can just tell it to pass the ID when I set up the onClick listener?

Thanks!

8 answers to this question

Recommended Posts

  • 0
  On 28/04/2010 at 03:13, dontocsata said:

I believe that View passed to the onClick is the View which generated the click.

I've poked through the view that was passed, but couldn't find the button name in it, unless it's buried in some odd place?

  On 28/04/2010 at 12:28, El Marto said:

iv only ever written one game for android and it was a while agoo. dont you declare the id for each button in the xml file? may be wrong here

Yes you do, and that is what I am trying to find when onClick is triggered. Like dontocsata mentioned, I would think it would be somewhere in the view that was passed in, but if it is, I can't find it

  • 0

No, the View passed in is the Button, I believe. Try this.

so you have... (it changed the case of the objects/methods, but you get the idea)

Button button = //get via R.id, or whatever
Button button2 = //get via R.id, or whatever

OnClickListener myListener = new OnClickListener(){
	public void onClick(View v){
		if(v==button){
			//do something
		}else if(v==button2){
			//do something different
		}
	}
}

button.setOnClickListener(myListener);
button2.setOnClickListener(myListener);

  • 0

I always use this technique:

firstly give your buttons an id. Then do something like this:

Button btn1 = (Button) findViewById(R.id.button1);
Button btn2 = (Button) findViewById(R.id.button2);

btn1.setOnClickListener(myListener);
btn2.setOnClickListener(myListener);

//myListener:
public void onClick(View v) {

     switch (v.getId()) {
            case R.id.button1:
                     btn1.setText("1 clicked!");
                     break;


            case R.id.button2:
                     btn1.setText("2 clicked!");
                     break;
      }
}

  • 0

That worked! I ended up using the switch that al1uk posted as the basis of it. I now see I was completely misunderstanding what the view object was when it was getting passed through and what the getid was doing.

Thanks again everyone! Extremely helpful :D

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • I use both Chrome and Brave simultaneously. Chrome for general browsing, while I keep Brave windows open on other monitors for X, Bluesky, YouTube, and a live news channel like CNN etc..
    • Firefox, for privacy, wide range of plugins without having to suffer the latest Google manifest restrictions and when used on Android for the mobile browser plugins like an ad-blocker, sadly that option isn't available to me now I've swapped to iOS as outside of the EU Firefox mobile is just a reskin of Safari
    • Ok will give that a shot soon as wake up in morning.     Hopefully does restore it working right  
    • Try doing a reset/repair on the Windows store: To reset the Microsoft Store on Windows 11, press the Windows key + I to open Settings, go to Apps & features, find Microsoft Store, click on it, select Advanced options, and then click the Reset button. This will clear the cache and restore the app to its default state, which can help resolve issues.
    • Microsoft's new Exchange Message Trace: What admins need to know before September by Paul Hill Microsoft has just announced the general availability of the new Message Trace in the Exchange admin center (EAC) in Exchange Online for its worldwide (WW) customers. The Redmond giant said that it’ll begin rolling it out in mid-June and complete the rollout in July. Message Trace in the Exchange Admin Center for Exchange Online is a tool that lets admins trace which path emails took as they traveled through the Microsoft 365 organization. It lets admins see if emails were received, rejected, or deferred. It is helpful for troubleshooting mail flow issues and validating policy changes. To get started with the new Message Trace, admins can access it by going to the Exchange admin center > Mail flow > Message Trace. While the Windows-maker has received positive feedback during the Public Preview, you can still provide your thoughts through Exchange admin center > Give Feedback. In addition, Microsoft will continue to maintain the old Message Trace user experience in Exchange admin center and cmdlets for several months to ease the transition, however, they will be deprecated for WW customers starting from September 1. The Reporting Webservice support for Message Trace data will also begin deprecating on this date. A side note to mention here is that this timeline only applies to the WW environment and doesn’t affect GCC, GCC-High, DOD, or other sovereign clouds. More information about the switch over for those will be provided in the second half of the year. Who it affects, and how These changes need to be noted by Exchange Online administrators and IT professionals as those are the people who will be directly affected. Specifically, it will affect anyone managing mail flow and troubleshooting email delivery in Exchange Online. Those who are affected will have to get switched over to the new Message Trace before Microsoft starts deprecating features in several months time. Admins will want to act promptly to avoid any unforeseen issues that could arise. Another detail that admins should be aware of is that scripts that rely on the older “Get-MessageTrace” or “Get-MessageTraceDetail” cmdlets will break on September 1. To address this, admins will need to update their scripts to use the new “Get-MessageTraceV2” and the “Get-MessageTraceDetailV2” cmdlets. Finally, any admins out there using the Reporting Webservice for Message Trace data will also need to make a change. They will need to shift to the new Message Trace PowerShell cmdlets. Why it’s happening Microsoft has been working on a new Message Trace experience, incorporating feedback from the Public Preview phase, to improve its design and performance. The switch gives Microsoft the opportunity to standardize and modernize admin interfaces and the underlying technologies. What to watch for While September 1 may seem like a long way away, fixing any issues, such as scripts due to deprecations, could take some time. Any admins managing the affected items need to ensure they deal with affected components in a timely manner. In terms of documentation, Microsoft has so far only released the Public Preview document which highlights the changes between the old and new versions. Microsoft says that it will publish cmdlet documentation for the new Message Trace cmdlets by the time of the general availability, so admins should look out for that.
  • Recent Achievements

    • Week One Done
      Leonard grant earned a badge
      Week One Done
    • One Month Later
      portacnb1 earned a badge
      One Month Later
    • Week One Done
      portacnb1 earned a badge
      Week One Done
    • First Post
      m10d earned a badge
      First Post
    • Conversation Starter
      DarkShrunken earned a badge
      Conversation Starter
  • Popular Contributors

    1. 1
      +primortal
      264
    2. 2
      snowy owl
      158
    3. 3
      +FloatingFatMan
      145
    4. 4
      ATLien_0
      140
    5. 5
      Xenon
      131
  • Tell a friend

    Love Neowin? Tell a friend!