This is not a code question.
I was just naming a Fragment and it got so long that I got confused.
I'm not sure if the Fragment's name is appropriate because it's too long.
What is the right way to name Activity or Fragment?
When naming, does the word Fragment or Activity have to be included?
For example, MovieListFragment -> MovieList, MovieActivity -> Movie
It's because sometimes it gets too long if i include these.
Or does it matter if I include it and it's long?
There are more than 22 letters to make it easier to recognize the Fragment I'm trying to name.
It all depends on what you and your team are most comfortable with. It does not matter if the name becomes too long or too short. I always name my project files keeping in mind that if I come back to my project after few months I should not be confused with file names and it is pretty intuitive.
It is the right name when it's intention gets clear.
You should avoid abreviations like MLF or MLFragment.
MovieListFragment makes it perfectly clear.
This counts not just for class names but also for variable names.
Though the smaller the scope, shorter names are fine, like in a loop for example:
for (i in 0..array.lastIndex) {
// i might be some index
// the loop has a small scope, so it's easy to get its meaning
}
In other words, if you have to scroll pages of code up to get the idea what that name is, its probably not a good name.
Think about, when you are not looking at this code for long time and you are coming back, would you still get what that name means?
And don't make names shorter just to save 2-3 characters. Days where this kind of optimization were required are long gone, and the compiler will optimize it for you anyway.
It doesn't matter if you're working with Activities or fragments, Your Activity or fragment name should be simple and meaningful such that when friends or colleagues read your codes it will make sense to them. Your project files names should also give a pictorial idea of what each variable, function or class does.thus it doesn't matter if the name is long or short. finally adding the word Activity or Fragment when naming your Activity or Fragment does not make sense and I will advise you not to do it.
Related
I've been wanting to make the code cleaner, but I do not give it away. I mean...
To name the ids of the views in the XML I use Hungarian notation like this:
<WHAT> <WHERE> <DESCRIPTION> <SIZE>
For example: tvExampleSectionEmptyBig,tvExampleSectionEmptySmall
Previously, using Butter Knife, I did not get too much coding because to do the bindings, I did things like this:
#BindView (R.id.tvExampleSectionEmptyBig) TextView tvEmptyBig;
#BindView (R.id.tvExampleSectionEmptySmall) TextView tvEmptySmall;
The code was much clearer and more reusable since the Hungarian notation used to avoid the confrontation between ids with the same name in different activities, fragments, etc. it was not present in practice more than in XML.
What's going on?
Kotlin has synthetic, which makes your life easier since with putting the id of the view, the binding is done directly, but with such long ids the code is very dirty ... Besides, makes sense that all the views I use in an activity called ExampleSectionActivity, contain within its variable nameExampleSection?
What would I like?
Surely there are better solutions that, but initially, what I feel is to implement a way to rename variables by removing a given String. As I follow a convention in all the names of the ids, it would be something internally in this way:
val tvEmptyBig = tvExampleSectionEmptyBig
val tvEmptySmall = tvExampleSectionEmptySmall
But of course, I would like to do it in an automated way.
On the other hand, I already tried naming the ids without the and to be careful with the imports, but for the moment synthetic fails very occasionally in this respect and I had to rebuild constantly. Especially if I open another instance of Android Studio, which I usually do quite often for consulting other projects I have.
Any idea? :-)
In my opinion, the easies and the most clean thing you can do is this:
private val myTextView: TextView
get() = f_layoyt_text_view
This way you don't have to use ridiculous, at least in 2018, ButterKnife and even more inconvenient findViewById.
For a few weeks, I already take for granted, that with the latest stable updates of Android Studio, there is no problem with repeating names of ids in different activities or fragments. Therefore, it is no longer necessary to put long variable names. Only there is to pay a little bit of attention to the imports, everything works like a charm, more readable and reusable. :-)
There are some questions about naming id in xml layout.
If i have a Activity used to create student.
What is the most suitable id for the EditText of student name?
et_student_name
et_name
et_create_student_name
I always use 3, because it is relate to the class name.But sometimes i think it is too long. I want to use 2 / 3, it is shorter but i am afraid it will repeated with other xml.
What is the good naming for the id?
Is it not good on repeated id in different xml layout?
Waiting for Help,
Thank you.
First, unless you are creating a distributed "jar" or "SDK" then you will discover name conflicts at build time. Worry about it then, not now. You are spending more time trying to avoid the problem than it's worth. Sometimes you need to prevent problems, but this isn't one of them.
If you are still worried, then there are 2 prefixes you can consider using. First, add a prefix that is somewhat descriptive of the XML file that has the element. For example, if the XML file is called "create_student.xml" then add "cs_" as the element for the prefix. (FYI - This really sucks when you change the filename, but that rarely happens.)
Second, add a prefix (or another prefix) for the package/class you are targeting. This prevents duplicates for SDK's and other libraries that may end in another developer's build. For example, if your SDK is "Student Registration and Identification" then add "sri_" to each element in the package.
The rest of the name is solely up to you. Having "et_" in the name for an EditText is helpful, the rest is going to be either "too long" or "not enough" almost every time.
to add to #AjayP.Prajapati your ids should not be the same as java keywords like break,continue ,switch,for etc..., and also your ids do not need to be special. if you have repeated ids the first occurrence will be returned.
So I have this big stupid problem with the preferences in my live-wallpaper.
First, PreferenceManager.getDefaultSharedPreferences, doesn't work. I'm calling it in my Main class, a subclass of WallpaperService in the function onCreate. For the parameter, I first tried "this" and then this.getBaseContext(), but it doesn't matter. So, when I print the values, nothing shows up!
Second, I saw in another answer here that to put some default values, use something like PreferenceManager.setDefaultValues(this.getBaseContext(), R.xml.setting, true);. So, this, doesn't get my defaultValues at all. They're all zeros and even one values from my setting.xml doesn't show up in the list. I explicitly put a android:defaultValue for each of them.
Note that once I put values for each of them in the preferences, this problem doesn't happen. But still, for someone who installs my app, it needs to work on the first time it's launched.
Preferences are a bear. I always start with a working example, and then modify it to suit my needs; it's impossible to remember the formalisms :-). The "obvious" place to start is the "second" Cube example in the SDK, which uses a preferences activity to choose between cube and dodecahedron shapes. For something more sophisticated, you might wanna look at Moonblink's "Substrate" package, which combines multiple wallpapers, and has complex settings. Project home is here: http://code.google.com/p/moonblink/wiki/Substrate , then click Source at top left, then Browse, Trunk, Substrate, src, etc. GF
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.