I know using a resource is good for redundant uses like any label that is generic across a platforms application but are there any other benefits to using a resource instead of hard coding?
for instance I have a button that is only in one view, is there a benefit to using a string resource for the buttons text even if it is one button that is only in one place in the entire app?
Otherwise I feel like its easier to go in to the one specific view to find the button and change the text if i need to rather then scrolling through an entire resource file to find one string resource.
There is more than one reason for using strings.xml than hardcode it. Please read the localization documentation. It allows you to easily translate text into many languages as you provide.
Related
i did not put some text in string.xml and there is a yellow alert symbol in side of Textview field. i want to know does it have problem and what happen, if do not put texts in string.xml in android?
Well, setting your text directly on your layout file can be a source of future problems and its not recommended.
Consider this scenario: You use the same string "Foo" in many layout files and then you decided to change to "Bar". If you have hardcoded that, you will need to make changes in all layout files and there might be a chance to leave some inconsistent text. But if you place it in the strings.xml file, you will have only to change in one place.
Also, if you want to add translations to your app, the Android system can handle it automatically for you if you use the strings.xml.
You might want to take a look here and here.
Nothing will happen.
string.xml used to:
localization
res/values-fr/strings.xml
res/values-ja/strings.xml
ease of editing and to save memory when reusing.
I Recommend you to put text files in string.xml
Whilst it will not cause a problem in the short term, it is not good practice and will cause you issues in the future if you decide to support multiple languages.
Whenever I make any app I always hardcode the string instead of referencing it from string resource from XML. App works fine but gives me warning to use #string resource
Example button:
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="click here" />
My question is whether it will affect my application performance if I do so or it(#string resource) is just used for internationalization.
This is an Android lint warning to help you with localization.
Technically, hard coding strings would make your app perform a little better, as it won't have to look up the string from the corresponding R int each time. However, this performance difference will be negligible, and no human will be able to notice it.
However, you should always keep your String resources in the values folder as it makes localization very easy.
I see no reason that you would get worse performance by using a hard-coded string. There are fewer steps involved with hard-coded strings. However, it is certainly best practice to separate resource strings from application and UI code.
It will not create any performance issue. But defining strings in strings.xml is encouraged for the ease of maintainance and lolalization. For example consider the below two scenario.
Scenario 1
When you need to change a string used in many places. In your case You will have to change all the "click here" in all layouts. But if you declared in strings.xml then only change made in the xml will change them all.
Scenario 2
For another example if you want to show different language for different locale then you need to use the string.xml.
As others said, it's for localization,
but for performance, it depends on how many times per second those strings are getting looked up.
I've seen a case where an app is slow in startup, and stack sampling showed 50% of the time was being spent in resource lookup of strings, and the reason the strings were being looked up was to display them on the splash screen that gives the user something to look at while the app is starting up!
I dont think hardcoding a string will make your program to run any slower.. Infact it will enhance the performance as there's no need for any lookup for the String in the R.java class.
Referencing the string from strings.xml is best practice due to 2 reasons:-
1- Localization
2- if you're using the same string in multiple places and would like to edit the same in all the places saves you the overhead of editing all the hard-coded strings individually.
Hard coding strings will not affect the performance directly. It affects the maintainability.
In case when you hardcode a string and in later stage if you want to change the string "Click me" to "add" or something else, then you need to search your complete project to change the string where and all it is used. So Better to follow strings.xml always. :)
Your app will not support Localization then, if that is not the requirement of your app then there will be no problem using hard coded strings.
This is a question for Android developers but it is not a programming-related question as it affects nothing but the developer.
What conventions are the most commonly used when naming various resources like colors, drawables and strings and etc?
I have no doubts naming my layouts activity_main or layout_secondary. However, I have always doubts when naming resources mentioned previously. I never know whether I should name these resources after their use or the content. For example:
Color: dark_blue vs text_highlighted
Drawable: blue_gradient vs top_bar_background
String: welcome_to_app vs first_time_prompt
Is there any community-created resource for good practice?
Naming is pretty much personal preference. The name is perfect as long as the name indicates what the functionality of the defined thing is. Also you and any other developer using these definitions should know how what the names mean and which definition to choose. Quite easy if you are consistent with names throughout the project.
For example dark_blue is obviously a blue color while text_highlighted is the color of highlighted text. The name you should use depends on what you need: if you want to classify colors by their name take the first, if you like to abstract from the actual color take the second. For general layouts using text_highlighted will often make more sense since the actual color does not matter and the functionality (text highlight vs text regular etc.) is more important. In this example choosing between text_highlighted and text_regular is a lot more obvious than choosing between color_light_blue and color_dark_blue although they could refer to the same color. The name can help prevent errors.
Android uses prefixes for names in [android.R.drawable]
(http://developer.android.com/reference/android/R.drawable.html) for example:
btn_ for button graphics
ic_ for icon graphics
ic_menu_ for menu icons
ic_dialog_ for dialog icons
stat_ for status icons
The schema is certainly not perfect but the advantage of using prefixes that start with the most generic classification is that you can use code completion to search for specific items step by step. So color_blue_dark could be better than dark_blue_color, at least if you consider the color classification more important than the dark / light classification. The same applies to first_time_prompt. If you have a lot of prompts it would make sense to name them prompt_first_time, promt_other_time, ... If they can be classified by an activity for example that could be used as super category: mainactivity_prompt_*, secondactivity_prompt_* so you know where they belong to.
Android SDK will be a good place to start for the good practices. You can open up any sample code in the SDK and go through the code and see the variable names.
I usually name assets like colors and pictures for their content, but I will name a style or multiple state drawable for it's function.
for example:
button_On.png; button_Off.png; button.xml
That way if I want to use the same resource in multiple places it does not get confusing.
For example using a color as a text color in one style file and a background in another style file.
Just start developing with android and think instead of reading a book a webinar could be better because a webinar could also teach me short ways and how an android developer thinks when writing the code but now got a problem
<CheckedTextView
android:id="#android:id/text1"
android:checkMark="?android:attr/listChoiseIndicatorMultiple"
</>
I dont understand the above code up to now see lots of different id definitions some of them was for resources and start with #resource/name, and some of those id definitions was like #+id/name just for creating a new id for the component but this time it is using android:id/text1 and I dont understand why it is using it in that manner
Besides, the checkMark thing make me confuse more what are all those ?android:attr/listChoiseIndicatorMultiple means?
Could you please explain me and show me some resource where can I find all those magic attributes so I can cope next time by myself and hope someday can answer other newbie questions
Thanks a lot in advance, and all comment will be appreciated.
Well, reading the docs has always been helpful to me:
Android Developer Site
XML Layout specific docs
#android:id/text1 is just a format used when the id has been previously defined. When you put a + in there that means the framework should create the resource id if it doesn't already exist.
It's normal to use #+id/thisid when defining a new view in a layout, and then use #id/thisid to reference the aforementioned view from another part of the layout (say, in a RelativeLayout where you need to tell one widget to be below another).
A question mark before the ID indicates that you want to access a style attribute that's defined in a style theme, rather than hard-coding the attribute.
#android:id/text1 basically this is used when you create any android component like button, layout, textviews etc.
but when you need any external component which is general for different platform like any color, image etc then you can declare it as #resource/name.
actually there is nothing different just keep one thing in mind that in #android:id/text1, id will simply work as an class name will contains other objects like textview, imageview or any other.
now if you declare #resource/name then in that also instead of id class name will be resource. actually when you will use it in java then these(#android:id/text1) will be converted into object hierarchy.
Maybe this is a silly question but is there a difference,besides the obvious,between
android:text="#string/...." and android:text="..."?.I'm thinking that maybe the text that appears on the screen has the option for styling when using #string.Which one is best to use in general or it really doesn't matter?
When you're using android:text="#string/" the app is going to find the value of the string in the ressources file, with this technique you can manage multilanguage app, with a "strings"'s file by language.
Choice Matters, if your app has a lot of text in it, supporting a different language would be easier if you used #string, you would not have to scramble through every xml file to add text in the other language for every piece of text, simply go to strings resource and change there.
But then again, when checking UI for errors after work is done, it might make life harder (or work boring) as fixing a typo would require you to go to the xml file that the erroneous text is located, look up the name of string and then go to Strings to correct (unless you were very organised and named things well in your Strings such that you know which text belongs where)