1

I am working on a project for Android (I'm currently using Android Studio, coding in Java) that requires a large amount of very long strings to be loaded dynamically in some TextViews. It's a sort of book, with each string being a page.

I was considering two options to achieve this:

  • Use some .txt assets and read them at runtime (but I don't know how much this could affect performance)

  • Save every page inside a string resource.

Could you tell me what do you think is best practice, and why?

Lyil
  • 11
  • 3
  • If you want to be able to update the text independently of the application make it an asset. I wouldn't use resources for large data. – user207421 May 19 '20 at 01:52
  • Relevant https://stackoverflow.com/questions/36612859/best-practice-for-saving-long-text-in-android – Zain May 18 '22 at 23:46

2 Answers2

0

Strings resources are best used to store string values pertaining UI related stuff, like EditText hints, Dialog messages and etc. Mainly because it helps to avoid hardcoding texts on views (often considered a bad practice). It also allows for optimal formatting and makes easier to translate your app to other languages.

Depending on the amount of data that you are going to put there, it's probably best (for the sake of your project's organization) to use a external source and load it from there.

For more info on string resources, please refer to this link: https://developer.android.com/guide/topics/resources/string-resource.

0

In general, if you are doing IO intensive stuff, it should be done outside of the Android UI thread. This can be achieved using AsyncTask, RxJava or Kotlin Coroutines if you are using Kotlin.

Save every page inside a string resource.

Using Context::getString(int) doesn't seem like the best option for large amount of text. It is unclear to me from the Android specification whether it uses threading. It appears to me that all the string resources are preloaded into memory. If that is the case, large amount of text would mean inefficient use of memory. Although, this blocking call shouldn't take too long since it is implemented with several native jni methods.

Use some .txt assets and read them at runtime (but I don't know how much this could affect performance)

This is what I would do. Have the text in the assets folder, then use an AsyncTask to read the file without blocking the UI. Optionally show a loading spinner.

Daniel
  • 400
  • 1
  • 2
  • 12