I'm writing my first Android app and want to pick up good coding practices. I have an Activity which contains the following:
Button btn = (Button)findViewById(R.id.btnPressMe);
btn.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
// TODO Auto-generated method stub
startActivity(new Intent(Main.this, SecondScreen.class));
}
});
or
startActivity(new Intent("net.mysite.MediaPlayer.CLEARSCREEN"));
AndroidManifest.xml:
<activity
android:name=".landingpage"
android:label="#string/app_name" >
<intent-filter>
<action android:name="net.mysite.MediaPlayer.CLEARSCREEN" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
The first way described is best used within your application, the other is used for other application to call your activity.
Abu,
The answer to your question depends largely on what you are trying to accomplish. Keep in mind that the other answers provided thus far have valuable input in regard to making your decision.
The Android Philosophy
Android is designed such that the User ultimately decides which applications take care of which tasks. Applications may overstep them, but should only do so if they are the only ones reasonably able to take care of that task OR if it is necessary for the functioning of the application as a whole.
An Intent marks the User's or the System's or an Application's desire to perform said task. Just because an Intent is made does not require that the User know or initiate it, though often it is best. However, if the Intent is hidden to the User, one might question whether it should be an Intent at all. This is something that is still being worked out by the development community and there are advocates both for and against the practice.
Static Class Intents
startActivity(new Intent(Main.this, SecondScreen.class));
These should be used when you cannot trust another application to handle your desired Task effectively. These kinds of tasks should also be "hidden" from the User, as the User may not care what is happening or who is doing it, so long as it gets done. Additionally, they should only be used for stable code that is not subject to changes. As Snicolas stated (and I personally agree):
Classes can vary in the life of an app.
Action String Intents
startActivity(new Intent("net.mysite.MediaPlayer.CLEARSCREEN"));
These should be used whenever possible. However, they should only be used when the Task can be performed by another application without destabilizing your own application. The Action String can be designed in such a way that it is rare enough to not be called by anyone else, but understand that an Action will prompt the User if more than one Application can handle it.
Analogize the idea similar to: "I use Microsoft Office for Databases and Word Processing, but when I want a Spreadsheet, I use Open Office". Both provide compatible results, but one is preferred for one reason or another. This works because Excel is not required for Word or Access to work correctly. Neither are Open Office's equivalents required for any other working part. They are all installed together but work independantly because they work with different resources and data entirely.
Hope this helps,
FuzzicalLogic
It's better not to use a static class name to call an intent. Classes can vary in the life of an app. Later, if you decide that this activity should change for another class, you would just have to change it in one and only one place if you use the AndroidManifest way.
Also, defining this kind of configuration provides other apps with a way to call your activities to get a service done. And that's the actual power of android to let apps communicate through intents.
Related
In Android, what is the purpose of < activity-alias > ? From the documentation, it seems that it is just another name for an existing < activity > with intent filters that override the target activity's filter (my understanding so far).
What is its practical use ?
Can a caller send an intent both to the target and the alias ?
it seems that it is just another name for an existing < activity > with intent filters that override the target activity's filter (my understanding so far).
I'd define it as "providing additional filters", more so than overriding.
What is its practical use ?
You can disable components, like <activity-alias>. You cannot disable <intent-filter> elements (though that'd be seriously handy).
Hence, if you have an activity that you want to be available all the time, yet only some of the time offer up a specific filter (or filters), <activity-alias> is for you.
A modern example of this comes courtesy of the new Storage Access Framework. It used to be that to make documents available to third-party apps, you would implement an ACTION_GET_CONTENT activity, with an <intent-filter> advertising relevant MIME types (and, possibly, ContentProvider paths for a provider of yours). However, if you are adopting the Storage Access Framework on Android 4.4+, you don't want to also have the ACTION_GET_CONTENT activity available -- the net effect is that everything of yours will show up twice. So, on Android 4.4+ devices, you need to either disable the whole activity (if you do not need it for anything else), or move the ACTION_GET_CONTENT <intent-filter> to an <activity-alias>, so you can disable it separately. This is covered in greater detail in the documentation.
TL;DR: I doubt that many developers use <activity-alias>, though it has its use cases (e.g., the launcher one cited in a comment on your question).
Can a caller send an intent both to the target and the alias ?
Um, if by that, you mean "can I use startActivity() to start either the activity or the alias?", then, yes.
I am working on a system application and I need to know programmatically what intents an application is capable of handling. I have seen other questions related to this, but none of them seem to have an answer but also do not seem to be concerned with system privileges.
PackageManager only seems to provide methods to query activities for a given intent. I can not find a way to get intents for a given activity.
For example, if I have an activity which has intent filters defined as such:
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
<action android:name="android.intent.action.USER_PRESENT"/>
</intent-filter>
And I know the activities class name and package name, I would like to find out from the package manager (or any other source) what intents it can handle (in this case, BOOT_COMPLETED and USER_PRESENT).
Good question. I don't think it's possible to find out the intents that an app can handle. Some standard activity actions and broadcast actions are listed at http://developer.android.com/reference/android/content/Intent.html. If you are writing your own app that's having it's own intent filters, then i don't think other apps will know what intents your app can handle because there is no way to publish them or announce them to the world, i believe.
But what is possible is that you can make a call for a particular intent and if that returns null, then you know for sure that there are no apps on the device that can handle that particular intent.
HTH.
So after just asking this question, I found this wonderful answer here:
Android — How to I get a list of all available intent filters?
Which leads to this 5 year old issue
So it doesn't seem like there is any way to do what I want to do at the moment. If it becomes available, I would love to know.
you could try a decompiler, such as "DexDump" (available on GooglePlay), and retrieve the "AndroidManifest.xml" of the application you want to know about.
I am creating an app with a service, and I would like other apps to be able to interact with and extend it. I can think of two scenarios:
another app wants to interact with the service
someone develops a better version of the service that they would
like my app to use instead of my built-in service
Most of the things that I have read about actions say that you should name your action something like com.mycompany.appname.CUSTOM_ACTION. However, I do not think I should put the actions in my own namespace since other developers might want their apps to be able to receive them. Instead, I think they should give them a more public name, like intent.action.CUSTOM_ACTION.
Is there a convention for naming public actions? Is it ok that I name my actions like intent.action.CUSTOM_ACTION, or is that a no-no?
It's bad idea to give it generic names. It comes with your app and therefore you should stick to com.mycompany.appname.CUSTOM_ACTION namespace
openintents.org is a website that appears to allow developers to register intents that they want other applications to use.
I have a webview in my app, on trying to do actions like making a call (Tapping call button from results displayed in webview), sending mails and other actions, my webview doesn't perform those actions
I Found a solution to add the intent actions in my web view activity as
Intent intent = new Intent(Intent.ACTION_DIAL, Uri.parse(url));
startActivity(intent)
Instead of doing so is there any way to add in the android manifest file
or Is there any way to turn on all of the intent actions for the webview so that
there wont be further issues in handling the actions
Can someone help me on this pls
Your answer seems to me a bit strange, I think you are a bit confuse about the difference between Intent and manifest permission. The first one are the system used by android to let app communicate with each other, the second one allow you to use some feature of the device like wifi and direct phone call that need the explicit agreement of the user to be used (the prompt that popup when you make the first install of an app).
With this clarification it is clear that if you want to do something that require another app you will have to make an Intent. This Intent, if well formed, will be elaborated by the os that will take care of sending it to the correct application able to accomplish the Intentrequirement.
So the answer to your question, as far as i know, is no, you have to use intent if you have the need of calling external app. It's also a good practice to set in the manifest only the permission really needed by the app, this way the user know what the app really can do and and what it can't do.
Hope i understand your question and answer it.
What's the proper way for other people to reuse my Activities? Should they hard code the intent actions in their app or is it customary to provide them with a jar file enumerating my app's intent actions? Is there a less tightly-coupled way to lookup the intent actions?
First of all, take a look at openintents.org and see if there's any match to what your activity does.
Secondly, documentation is always a good idea.
Having the intent details hardcoded in their applications should work just fine. After all, the intents are part of your public interface and shouldn't change.
Your applications manifest should announce what sorts of things your activity can handle, via intent-filters. Outside users can read the manifest to determine what actions you support, and invoke them via action intents.
See intents and intent filters for more details.