I am quite new to Android
I studied how to use category (in the intent-filter). And I know category is used for grouping the activities. But didn't understand what is the real use of - category.
Can any help me in this regard - siting the practical use of category.
Thanks
The category gives additional information about the action to execute. For example, CATEGORY_LAUNCHER means it should appear in the Launcher as a top-level application, while CATEGORY_ALTERNATIVE means it should be included in a list of alternative actions the user can perform on a piece of data.
Here is a full list of categories with a short description
Related
<shortcuts xmlns:android="http://schemas.android.com/apk/res/android">
<shortcut
android:shortcutId="compose"
android:enabled="true"
android:icon="#drawable/compose_icon"
android:shortcutShortLabel="#string/compose_shortcut_short_label1"
android:shortcutLongLabel="#string/compose_shortcut_long_label1"
android:shortcutDisabledMessage="#string/compose_disabled_message1">
<intent
android:action="android.intent.action.VIEW"
android:targetPackage="com.example.myapplication"
android:targetClass="com.example.myapplication.ComposeActivity" />
<!-- This -->
<categories android:name="android.shortcut.conversation" />
</shortcut>
</shortcuts>
What other value is available? Do I need to include this category and what if I delete it?
I did not find this in the official documentation - https://developer.android.com/guide/topics/ui/shortcuts.html
categories tag is used to provide a grouping for the types of actions that your app's shortcuts perform. One of the available groups is android.shortcut.conversation, and this is used if you want to add a shortcut to conversation of chat application. For example, a shortcut to the most recent chat head. You would only need to add this in your shortcuts.xml, when you want to provide the said shortcut. Otherwise you don't need it. You can delete it.
For API level 26 or lower this is the only value that is avaliable. But for higher versions there are multiple.
For a list of supported shortcut categories you can see this page.
At this moment only one type supported category is android.shortcut.conversation. You can find it in ShortcutInfo
/**
* Shortcut category for messaging related actions, such as chat.
*/
public static final String SHORTCUT_CATEGORY_CONVERSATION = "android.shortcut.conversation";
Also in
/**
* Sets categories for a shortcut. Launcher apps may use this information to
* categorize shortcuts.
*
* #see #SHORTCUT_CATEGORY_CONVERSATION
* #see ShortcutInfo#getCategories()
*/
#NonNull
public Builder setCategories(Set<String> categories) {
mCategories = categories;
return this;
}
Shortcut category for messaging related actions, such as chat.
TL;DR in 2022: Seems like the "category" inner element became a forgotten feature of Android Shortcuts, and there only ended up being that one pre-defined "Conversation" category. Capabilities, on the other hand, are very well fleshed out and fill those boots quite well! Check out the link below for what capabilities can help you unlock!
In more detail as of 2022, Android API Level 25 introduced the ability to define shortcuts, letting you provide the user with a static set of shortcuts into your app for common actions like creating a new email as well as a dynamic set of shortcuts like sending a message to a recent contact.
It seems that the "category" inner element was intended to group certain similar shortcuts together. Unfortunately it seems the idea was abandoned likely due to the limited number of shortcuts that could appear in the small popup menu. These days the most I've seen is 5, and it can definitely vary based on your device. As a result of the limited space, it seems the only category that has been defined, even today with API level 32 available, is the "Conversation" category.
Due to its limited development, I find it best 99% of the time to leave off the "category" inner element in favor of the "capability" inner element which has quite the long list of pre-defined options that correspond to Built-In Intents (which can add amazing Google Assistant actions to your app)!
Here's the list of all of them!
I've been following Facebooks Open Graph tutorials (the Scrumptious tutorial to be precise) for an Android app that lets the user post a custom story. I've got everything set up and working, but I'm not sure if I'm understanding the object types correctly. In the Scrumptious tutorial they have an eat action and a meal object, that much I can understand. What I don't fully understand is that there are different meals. For example there could be a hamburger meal, a pizza meal, chili meal, etc. Now those are all meals, but each one is different, do I have to set each one up as its own object type? Or do I just keep the single meal object and just pass in the different urls (each has its own image and description) associated with the different foods to create the story like I have it setup currently? I probably missed something along the way explaining that, so any answers would be greatly appreciated.
All you need to do is to create an object Meal, and then using different URLs.
The URLs are defined in strings.XML, and they are fetched in SelectionFragment.java, in this line:
foodUrls = getActivity().getResources().getStringArray(R.array.food_og_urls);
I'm trying to build a complex form where almost all of the elements are optional. It starts with just a single field and an "add element" button. When you click add, the form shows a Spinner of the types of elements you can add to the form (location, photo, detailed note, timestamp other than "now", etc). When you select an item, it will launch an Activity, and each item has a different associated Activity.
In addition, each choice will have several bits of data, which it would be nice to store "with" the Activity somehow:
An icon and the displayed name in the Spinner
A key for storing the data in the db (as well as passing to a webservice)
A layout for how to display the result on the original form (i.e. a thumbnail for the photo, the lat/lon for the location, etc)
I was considering a set of classes that all extend an abstract FormElement class, and would have static elements for each of the above extra pieces of data. (An additional bump for this solution is how much of a pain Resources are in a static context.)
How can I make this as clean and maintainable as possible? I'd really not enjoy editing five different files to add a new type of element to this form. (Mostly because I can guarantee I'll miss one and spend hours chasing down unbugs.)
A few tips...
Unit tests will prevent "unbugs" :)
When each Activity has obtained the information it needs from the user, call Activity#setResult() with an Intent that contains your per-type data. Intent supports all the Bundle methods, so you can set different types of data as needed.
To support #2, make sure you're using Activity#startActivityForResult(Intent,int) to launch it, and listen for the result in Activity#onActivityResult(int,Intent)
I would probably maintain the list of available "element" types for use with the SpinnerAdapter (e.g., ArrayList<Class<? extends AbstractFormElement>>, and invoke static methods like .getDisplayName(), .getActivityClass(), etc, in the Adapter's getView() method, in order to determine what to display and what Activity to launch.
In this way, your list would actually contain things like { MyPhotoElement.class, MyTextElement.class, MyDateElement.class, ...}).
As each element is added to the form, add it to an ArrayList<AbstractFormElement>, which will be used to back another Adapter for a ListView. That adapter will dispatch the inflation of a custom view layout, as well as the creation of a ViewHolder, based on what type of object it is -- that will require that each distinct AbstractFormElement will have its own "view type", according to the Adapter. See BaseAdapter#getItemViewType(int) and related getViewTypeCount().
It's worth noting that these will need distinct view types only if one cannot be converted to the other... For example, if you have two "Elements" that only need to display a string of text in the list, those can both share a "text-only" view type. Likewise, two elements that only display a photo, or can easily convert one to the other (e.g., an icon with a caption, vs a photo thumbnail with no caption), can share a single "image-plus-caption" view type.
With the above in mind, you actually would end up having to modify different files to add a new type (well, I guess technically you could have them all in one file, as inner classes, but there's really no good argument for doing that), but if you've done your interface API correctly, and follow good OO practices, and implement good unit tests, you'll considerably reduce the amount of effort required to find bugs -- simply because most of the things involved in adding a new type would actually force a compiler error if you do it incorrectly. Add to that the fact that a proper unit test suite will be able to programmatically add all possible types, and ensure that everything displays properly, and you should have a pretty streamlined process for easy extensibility :)
It sounds like a lot of work, and it might seem tedious and verbose at first... But the end result is actually much more maintainable, especially if your list of element types is going to be fairly extensive.
What are some layout file naming conventions people have come up with.
I haven't found anything online, but thought about using the following convention.
What does everyone think?
- activity_*
- dialog_*
- list_item_*
That's all I have worked with so far.
Also, what about the naming of the activity against its layout? For example:
-> res
-> layout
-> activity_about_us.xml
-> src
-> activity
-> AboutUs.java
Strangely enough, trying to google this question brings only this page as meaningful result...
For the past half year I am using naming convention similar to yours but with shorter prefixes. For example:
For activity that shows "About us" screen:
Class name: ActAboutUs. Prefixing class is kind of overkill but it clearly distinguishes activity classes from the others. Initially I used separate directory for all the activities (similar to your approach) but after some time I realized that for bigger apps may be it is better to group in directories by feature than by superclass (i.e. Activity). It is easier for me to work in single directory for example /src/settings/ when I work on Settings. That way all java files that I need are in a single dir so i don't have to wander around:
/src/settings/ActSettingsGlobal.java
/src/settings/ActSettingsNet.java
/src/settings/Settings.java
/src/settings/SettingsDBAdapter.java
/src/settings/etc...
This approach also helps to split the work among different developers, i.e. each one is working in his own dir on separate feature so no stepping on each other's feet :-).
Some people preffer suffixes but I found them less useful. Prefixes help to group things alphabetically like in the example above: Act* prefix is sorted first so all activities are conveniently at the top.
I am even considering of using Act_ as a prefix which is more readable although it is in conflict with java naming conventions...
Layout filename: act_about_us.xml. In res/layout/ we don't have the "luxury" of subdirs which is quite unfortunate so the only way to group things is using appropriate prefix like act_, dlg_, etc...
String IDs: <string name="act_about_us_dlg_help1_title" ...
string.xml is the place where we have most problems with duplicate names. It is very easy to create duplicates if naming convention like activity_element_item is not used. It adds a lot of additional typing but it saves you from a lot of confusion later on.
For global (application wide) strings we use prefix "global_", for example global_btn_ok, global_msg_no_inet_conn. Usually we make one person responsible for all global_ strings so if someone needs new string or change he needs to sync with him in order to avoid creating a mess.
(now I am realizing that activity__element__item (two underscores) is more clear and readable than activity_element_item)
All in all I still can't get rid of the feeling that there is something wrong with my approach because I can't believe that google devs created such an inconvenient framework when it comes to working with files, IDs, names, etc...
i think following naming convention should be follow
for activity
if our activity name is
DisplayListActivity
then our layoutname should be
display_list_activity.xml
for list items we can include category in list item layout name
country_list_item.xml
and for dialogboxes their action can be included
delete_country_dialog.xml
When looking for a group of layouts, which is how I tend to work on them, I find it effective to always prepend the class name and follow up with any sub-layouts. For Instance:
Class Name: AboutActivity.java
Layout Name: about_activity.xml
Sub-layout Name: about_activity_menu.xml
Sub Sub-layout Name: about_activity_menu_item.xml
Your activity will always be at the top of each grouping and hunting for non-activities becomes less of a chore. Anyone know why sub-folders aren't a thing yet? I expect for efficiency and simplicity on the back-end, but I imagine it wouldn't hurt too much.
This is a good read https://jeroenmols.com/blog/2016/03/07/resourcenaming/
Basically, you follow WHAT WHERE DESCRIPTION SIZE
For example, layout file
activity_main: content view of the MainActivity
fragment_articledetail: view for the ArticleDetailFragment
strings
articledetail_title: title of ArticleDetailFragment
feedback_explanation: feedback explanation in FeedbackFragment
drawable
- all_infoicon_large: large version of generic info icon
- all_infoicon_24dp: 24dp version of generic info icon
The first part of a layout file name should always be the type of the corresponding class.
For example if we have a class MainActivity (type is Activity in this case), the corresponding layout file should be called activity_main.xml
That means that lets say we have a dialog called WarningDialog, the corresponding layout file should be called dialog_warning.xml, same goes for fragments etc.
This might seem familiar because thats also how the activity/layout files are named when creating a new project in Android Studio (MainActivity -> activity_main.xml).
For me, naming should fix two important requirements:
it should give you a hint about files' content and type (for example activity_login/login_activity or movie_list_item/list_item_movie)
it should visually group related items together to minimize jumping back and forth
For the second requirement, most people define "related" as type related which gives you something like this:
activity_login
activity_movie_list
activity_user_list
activity_settings
fragment_movie_list
fragment_user_list
item_movie
item_user
etc.
I prefer to do grouping by feature since you'll almost never work on all activities or all fragments, but instead, you'll work on movies feature or setting feature.
so, my prefered way is this:
login_activity
movie_list_activity
movie_list_fragment
movie_list_item
user_list_activity
user_list_fragment
user_list_item
settings_activity
Source files are following xml naming but in CamelCase, so there will be
LoginActivity
MovieListActivity
MovieFragment
etc.
Clicked on create filter could not figure out from docs how to create a filter for say two or more tags. If I have two tags com.test.TestClassA and com.test.TestClassB how do I create a filter that shows log for both of these classes? I saw how you can start ADB for only certain tags, but how can this be done in eclipse? Please provide details thanks. What exactly do I need to enter on the tag line when creating a new filter in eclipse?
As pointed by Brain Reinhold you can combine tag filters with vertical bar | (which obviously means logical "OR"). You can also use that (as well as other Regex) syntax in the logcat search box (by preceding tags with tag: prefix):
tag:com.test.TestClassA|com.test.TestClassB
More complex filtering is also possible. For example here is the search filter that displays messages from either android.process.media or com.android.camera apps, which have at least one digit (\d) in the message text and are tagged with either dalvikvm or AndroidRuntime tags:
app:android.process.media|com.android.camera tag:dalvikvm|AndroidRuntime text:\d
One short and useful filter is tag:^(?!dalvikvm) which removes all those noisy Dalvik logs.
It's also worth mentioning that you can quickly disable any part of the filter by placing vertical bar at the end of the part you wish to disable (e.g. placing | right after app:android.process.media|com.android.camera in the example above effectively disables filtering by application name while still preserving filtering by tags and text).
In the latest version of the SDK for Eclipse which now shows two versions for logcat (one deprecated); in the undeprecated version one can combine filters using OR bars: |.
For example when clicking on the + and bringing up a dialog to create a new filter, give your filter a name and then in one of the fields (for example TAG) enter com.lampreynetworks|Bluetooth and you will see output for all tags containing com.lampreynetworks and Bluetooth. The '*' is implicit here as if any part of the TAG contains any of that text it will be displayed. Also note, there must be no spaces between the OR bars!
I have not tried combining the 'by TAG' and 'by (some other option)' but somehow I have a feeling that will not work.
On Feb 12, 2:58 am, AndroidDevTime wrote:
If I have two tags
com.test.TestClassA and com.test.TestClassB how do I create a filter
that shows log for both of these classes?
The "Log tag" field accepts Java regular expressions, so do this:
^com.test.TestClassA$|^com.test.TestClassB$
which matches exactly those tags you specified. You could be more economical/efficient/whatever with the regular expression, depending on how much you want to muck around with that.
It is not possible right now.
#see http://groups.google.com/group/android-developers/browse_thread/thread/17356ef7bdf1550f?pli=1
I also wish it were...
I just do it from the command line. Having a different terminal for each adb filter. Then if you line them up side by side you can get a good idea of what is happening.
The only way I have seen is Create a Filter using PID so that evey log message of your application will be displayed in that Filter. I wonder if this is possible through tag names in the current version of the ADT for eclipse.
Use proclogcat: http://devtcg.blogspot.com/2010/04/logcat-improved.html
It lets you filter by your package name instead.