Develop Reference

What's the correct way of sharing functionality between activities?

Suppose I'm building an Android app, and I have two separate activities. Both do similar things, but maybe the layout is diferent. Let's say I have a button in each activity, and both buttons do the same thing, but I don't want to be redundant about it.
Could I just define a public method in one of the activities and then call that method from the other one too?
Even further, could I create some java class PublicMethods and just put in it all the methods that I want to share between activities?
I haven't seen this anywhere else, I think, so I suppose there is a good reason not to do this, but I can't figure out what it is.
Is this bad practice? If so, why? And if this is the case, what would be a good way to solve this problem?

Since you're not very specific about what you are trying to achieve I'm guessing mayb you could just create an object and then call it from the activities and pass parameters determined on what you are trying to make it do, and even just send what you want through the activies by using intent putExtra and just used the Extra in your activity.

Replace intents for notification within app

Intents are taking too long to be process in my app. Is there a better way I can tell different elements of my app that something has happened? For example I use:
Intent i = new Intent("com.ftx.player_died");
I listen for that intent on two different places in my app. I would not like to make the same call twice.
Inventory.playerDied(true);
NotificationBar.playerDied(true);
Doesn't scale nicely.
Is there something I can use that is faster than intents but that I don't make same call twice or three times?

Using LocalBroadcastManager orEventBus is not only faster the normal BroadcastManager, but also is private to your app (that means other application cant listen to your Intent action)

It depends on a lot of factors. It is needed to see of your project to give a piece of advice.
But in some cases it is possible to use usual interface that declared and shared in the static Application class.

Why use Intents in Android? [duplicate]

This question already has answers here:
What is an Intent in Android?
(14 answers)
Closed 9 years ago.
I still don't understand what is so special about Intents. Why not just use a new thread or just call the function? I think I got the whole idea about intents wrong. A simple code showing why Intents are better or when are needed would be great!

Intents are get widely used in android to switch from one activity to other . it is good practice to use intents . Using intents we can pass/send values from one activity to another. So it can be used as value passing mechanism. Also its syntax is very simple.so why to think about threads ?

Intents are asynchronous messages which allow application components to request functionality from other Android components. Intents allow you to interact with components from the own and other applications. For example an activity can start an external activity for taking a picture.
Intents are objects of the android.content.Intent type. Your code can send them to the Android system defining the components you are targeting. For example via the startActivity() method you can define that the intent should be used to start an activity.
An intent can contain data via a Bundle. This data can be used by the receiving component.
To start an activity use the method startActivity(intent). This method is defined on the Context object which Activity extends.
The following code demonstrates how you can start another activity via an intent.
# Start the activity connect to the
# specified class
Intent i = new Intent(this, ActivityTwo.class);
startActivity(i);

Why not just use a new thread or just call the function?
No matter what Thread you use, there would still need to be a mechanism to direct the message which is what an Intent does. It is a way to send a message. Now, it needs to be called on the UI Thread or have an appropriate Context passed because it needs this to send the message. Call what function? You are. It calls a constructor of the Intent class.
A simple code showing why Intents are better or when are needed would be great!
I don't have a simple code to compare to because I'm not sure what you want to see. No one is saying that it is better than something else. As to why Intents are used opposed to something else? I don't know...you would have to ask the developers of the Android platform. That is what they decided to use.
When they are needed is when you want to pass a message from one Activity to another or from one application to another. From the docs
An intent is an abstract description of an operation to be performed
I said "message" but the docs say "description of an operation to be performed" (I guess can mean the same thing). You can use them to start an Activity, pass data between Activities, and more such as telling the OS what to do at boot time. Why is it better? Better than what? That is what the developers decided to use so I guess you would have to ask them but maybe they didn't think it was better rather different.

while I don't have an example, Intents encourage coupling components loosely.
It negates the necessity of you building your own Observer design patterns and enables Inter/Intra-Application communication.

FindViewById in a class type Service?

I'm working with the sample media player given by the android sdk. MainActivity starts Service MusicService with startService(new Intent(MusicService.ACTION_PLAY)).
I need to find a view by ID inside the Service but I don't know how to do it:
findViewById(R.id.playbutton).setVisibility(View.GONE);
I've found some similar questions but none provide a simple solution (the most similar question's accepted answer is actually "no you can't" and I'm sure it's possible). How can I make this line work inside the Service? Do I have to pass the context from MainActivity to it, how do I do it?

Since the service handles media playback the interface should be updated directly before playing/pausing that's why I need to update the ui from it
No, you do not. You need to let the UI know, if it exists, about the state change. The UI will affect its own changes how it sees fit. There may not be any UI at all, depending upon what the user has done.
For letting any affected bits of UI know about the state change, you can:
send a regular broadcast Intent, or
use LocalBroadcastManager to send a "narrowcast" Intent (works a lot like a broadcast, but it is completely within your process), or
use Otto as an event bus

Sending an ordered Broadcast locally (within my process)?

My requirement is this: My app needs to register for certain broadcasts. If my Activity is "showing" when I receive the broadcast, then I update the UI; else, I show a Notification.
Commonsware has come up with an elegant solution for this; using ordered broadcasts. My problem is that I want to do all of this locally, i.e., within my process. Unfortunately, LocalBroadcastManager does not have a sendOrderedBroadcast() equivalent.
Is this just an oversight in the LocalBroadcastManager?
Or is it pointing to a best practice (something to the effect that sending ordered broadcast locally is a bad idea)? If so, why?
Or is this plain unnecessary and can be achieved by alternate means?

Is this just an oversight in the LocalBroadcastManager?
Google does not have infinite engineering time.
Or is it pointing to a best practice (something to the effect that sending ordered broadcast locally is a bad idea)?
I doubt it.
Have you considered using onUserLeaveHint() and onUserInteraction() callacks in Activity class?
onUserLeaveHint() is insufficient here (e.g., does not cover the case where the user accepts an incoming phone call), and I fail to see how onUserInteraction() helps any.

I ended up implementing my own LocalBroadcastManager with ordered broadcast capability. The project is shared at github.
Although it serves my immediate purpose, it is still rough around the edges. It needs a few enhancements (for example, the setResult* and getResult* methods). Code contributions are welcome :)