I have lots of large strings which I will use only in two places (2 methods). I could declare them globally in the class, but worried about the memory and dynamic memory allocation slowing down the app.
Even though I declare in strings.xml, I would have to load them using getResources().getString() Would declaring them in strings.xml make anything better? memory or speed.
I am not worried about localization.
In my opinion keeping the strings is strings.xml is a better option
1) As you will practically save a number of String objects which you would have created during runtime.
2) Easy to manage all strings at one place.
3) its better to allocate resources at compile time rather than runtime.
The main thing in a developer's life is not how well he writes a code but how well he maintains a code so that more people can work on the same
Keeping all strings in strings.xml is a better option to keep them in the same file and also editing/modification of these strings will be easier.
Strings.xml is more maintainable and best practice,however if the only thing in the world you care about is efficiency and speed hard code it. There is no correct answer.I hope the string isn't your company name and they get bought out for example.
Related
I have been looking at different ways to hold onto some predefined character data, however I am having a hard time nailing down which would be the best solution.
An example of data would be 10 strings, 5 int arrays (of size 10 each). There would be 10+ set's of this data. The application would load in the information and inflate generic "character" objects.
Possible solutions:
XML: Due to Android's structured XML requirements it can be hard to use without making a different XML file for every character, and even then it would have ID overlapping for similar named data values.
SQLite: Wouldn't be a huge database, but databases are ugly version controlled unless it is done with a create-database script which has its own downsides (such as making sure DB is up to date between builds).
Hard-coded Objects: By far my least favorite solution, using polymorphism to hardcode all of the objects. Too dirty, not nearly as dynamic as it should be.
I would like to consider things such as version controlling the files, ease of updating (due to them only being inflated, never changed by the app).
If this data is baked i would suggest to use harcoded data.
Reasons.
In those three solution you save the data in the application.
If you use XML-data, you have to consume the time while code parsing inside the code. And you have to write the code that parses your xml.
If you use SQLite, your data will be doubled because of you have to store this database in raw or assest directory, copied in the /data/data folder. Futhermore, if you use Strings and SQLite by default the data will be doubled again (due to UTF-16 encoding).
If think, if only you manage the data this is more usefull to store directly inside the code. Obviously, if you do not use tons of content:)
You might want to use the Realm framework, which is comparatively faster than SQLite and easy to implement inside in your current code.
It handles large data too and it feels like you're using only native android classes.
I am currently making an educational app that will need to have alot of text . I was wondering if reading from an xml file with the data use less memory than creating various strings of populating numerous textviews .I would like the app to be as small as possible like the physics solver app which has tons of text with images and is still 4mb large .If not, how can I put alot of text and still keep my app small?
Since you are asking about the "footprint" of the app (size of the APK - not size in memory necessarily), then things are little different.
First, when you say "XML" I assume you mean the Android "values" XML for storing Strings. Random XML depends on the XMLNS (the NameSpace) and attributes, etc. It can bloat fast.
For Android res XML files, the compiler will create a static reference to each String in the "R" file (resources) that you will later reference using "R.string.myString". This adds to the footprint, but only minimally.
Second, in bytecode static Strings will not have that reference, but they do have a "enumerated and indexed constant pools" as described in the docs here: https://source.android.com/devices/tech/dalvik/dalvik-bytecode.html
So either way you end up with a static reference to the String. Once in memory, they will essentially all be treated the same. For XML, the Resources object will getString which creates a CharSequence. For static variables, it might be a bit faster because the bytecode identifies it as a java.lang.String and instantiates it that way. But performance for either of these will be more dependent on platform implementations, thread and core queuing and other things that have nothing to do with you code - because both are really, really fast.
Also, you should consider that either of these solutions will allow a very large amount of text to be stored - most books contain about 400,000 - 500,000 characters (https://www.quora.com/How-many-characters-of-text-letters-are-in-an-average-book). So most of your footprint will come from compiling your java project (framework) and then images, if you choose to have them. A 500kb text string is a book. A 500kb image is one semi-decent image. (When they say a picture is worth a thousand words - in software, it's more like a hundred thousand or more :) ).
Well, using xml means less space but slower loading of the app, using Strings means a little more ram usage but Faster loading. Meaning if you launch the app it might delay with the xml for a second or two, but with Strings it will load with almost no delay. I would say xml, it means a little more mb but it also means less phone ram meaning it could run on any phone.
No, XML takes up more space both in memory and disk space. However, if you have XML file you don't have to read the whole thing either.
If you have a large data set, and you're worried about space for the app, I would have the data as a set of SQL database creation scripts and SQL inserts and then compress it and store it as part of your app.
Then on initial load you can extract it and load it up in the SQLLite so you can do lookups and release the data from memory when you're no longer using it.
I am making Android app, I have to use multidimensional data, either in String [][] or in Xml resource file. Please suggest which one is better from performance perspective and memory used in both cases.
As Jack stated, the operations on a String[][] would probably have better performance than working with an XML file. It would also likely have a smaller memory footprint. Depending on what sort of data you are dealing with, a String[][] might be cumbersome to deal with. If the data is hierarchical, I would go with an XML file for simplicity.
If you thing an XML file is the way to go, take a look at this article on parsing XML in Android. The article claims that an XmlPullParser is "efficient."
You may want to consider using a JSON format as third option :)
If you only care about the performance and memory footprint, String[][] would be better.
But place your data into xml and access them as resource has its advantages.
Following is quoted from Android developer's document.
Using app resources makes it easy to update various characteristics of your app without modifying code and—by providing sets of alternative resources—enables you to optimize your app for a variety of device configurations (such as different languages and screen sizes).
In addition, by zip aligning the resources, the resource can be mapped to memory which makes the speed to access them also very fast.
Yep I know its easy to fetch n it simplify code n even for localization. But I just wanna know because in android declaration of too much objects is not advisable, And im not too sure if arrays in resource is like dat in code (i.e in terms of object). That is why Im asking which is the best practice in android as we all know that each language as its own do n dont for effective output
I think the comments point to the answer that there is no real answer. What is the "best" depends on what you're trying to do.
Loading a fix array of strings from resources will be fast and negligably increase the size of the apk. However, as far as I know, a resource is fixed. You cannot add/remove entires to your XML resource file on the fly. You generally see fixed XML resouces when you know the values will not change, like with a ContextMenu where you know the options you will be offering will always be the same. In that situation, there is no need to set the values programatically (although you can if you want to).
Declaring the Array programatically is more flexible, i.e. it can be modified dynamically, but had other limitations. For example, it is not necessarily universally accessable like your resources file. I'd use the Array declared in you Java code if what you're doing is a dynamic function, e.g. generating a user selected list or grouping data on the fly.
As for speed someone who knows more may be able to elaborate but, unless the data size is extremely large, I cannot imagine that there would be huge performance differences for a basic string array in either form.
You just need to balance you're needs vs. the cost/benefit of each possiblity.
I have to manage XML documents and Strings in my app.
In terms of efficiency and memory usage, will a collection like ArrayList be much more expensive than String[]? Also, I could store the content as a regular String or XML. Is working with XML also more expensive? (When I say expensive, I am referring to the use of system resources.)
Those Strings will include xml's.. all i gonna do is pass them to another appz and those appz will deal with them.. nothing more..the ArrayList will hold dynamiclly around 20 Strings each.. and ill will need to 'for each' it, get the content of the string and send it to another app.
If there are differences, are they significant?
Thanks,
Ray.
It depends very much on what you're doing with the strings and how you're using them.
However, from my recent experience using an ArrayList of strings for processing quickly and repeatedly, I found a String[] array 8-10 times as fast for my purposes (read string and compare in a while loop).
It seemed really odd (and annoying because I wanted dynamic size), but the execution time spoke for itself.
Like I say, this is from my own experience recently and I'm just being general. Perhaps if you provide more information on what you're trying to achieve, we may give you more specific advice.