Develop Reference

Best way to load ~500 paragraphs plus options

I'm just getting started and trying to make a simple app after going through some of the Google Codelabs. I wrote a Choose your own Adventure type of game. It consists of 500 paragraphs, and at the end of each paragraph is usually a choice of the next action to take (ie paragraph to load) and possibly some game logic. For now I am concentrating on the text only.
It seems simpler to make 500 text files and load up whatever file number is necessary, however it makes more sense to load ALL the paragraphs as the entire text takes up roughly 300Kb as a text file.
How would I even attempt this? I know I would need a text array and I file reader. I think it would be more work to format the paragraphs with a delineator to separate them, as it may be simpler to just create 500 files and write a While loop feeding my array.
That should fulfill my current objective, but when I want to add the choices at the end of the paragraphs, it seems as if a JSON or XML file that includes the text and choices would be better. I could not figure out how to even attempt this.
Example Paragraph: "You hear a horseman galloping and spin towards the sound. Do you have the skill of Forest Stealth? If you do, turn to 95. If you do not, turn to 234."

Image scrolling app - bitmap too large to be uploaded into a texture

I am working on a very simple app that shows one jpg, which is scrollable on vertical axis.
I would like this image to be very large(20000x1000 px), however, when I try to run the app on my device, it says that "bitmap too large to be uploaded into a texture".
Is there a way to display the image of such size in an android app?
If not, would it be possible to divide the image into segments, and after I scrolled to the bottom
of one segment, I would proceed to another?

To quote the answer for your question here:
All rendering is based on OpenGL, so no you can't go over this limit.
Note that this would take a huge amount of memory. With such big
images, if you want to zoom in out, and in a mobile environement with
heavy memory constraints, you should setup a system similar to what
you see in google maps for example. With the image split in several
pieces, and several definitions.

You could split the images into let's say 128x128 chunks. Add them to an array, and loop the array to create and fill an ImageView with the image that is currently served.
some pseudocode would be: (excuse me, I've been programming a PHP application the past few days)
Private BitMap[] imageArray = {your bitmaps from internal or external storage};
For(BitMap bm in imageArray) {
// create a new image view here, use the correct layout params or use a parrent grid view.
imageView.setBitMap(bm)
}
now once again, I am 0% sure about that pseudo code, but it should help you along.

Why is WebView so much faster than a TextView

I have an activity that's supposed to display a text file. The text file is 165 kB. Originally, after I read in the text file, I would do something like this,
textView.setText(fileText);
But that took over 10 seconds on my Nexus 4, and I confirmed that this was due to the call to setText() and not reading the file. Then, after searching around a bit, I got the idea to put it in a webview, using WebView.loadData(). This takes less than a second.
I'm curious as to why a WebView is able to load text so much faster than a TextView. Does anyone know?

From what I remember;
The WebView will only render the text that it needs to display at any given time. Meaning that when you first load it will only load 20 - 30 lines of text. Whereas when you call textView.setText(fileText); it causes Android to render all of the text even though it is not displayed. If you are trying to add a lot of text to a TextView then you should use textView.append(fileLine); in a loop which should load quite a bit faster.

Possible TextView imeplementation to handle very large data

I have been looking for a while but haven't been able to find an answer. I have a text view in my APK that needs to potentially handle large amounts of text being appended to it a little at a time. So it could grow over time as stuff streams to it. So far I haven't seen any issues and I have let the underlying Android implementation take care of the data. Does anyone know if Android caches these all in memory or that if it passes a watermark level it could then write to file for the TextView? What if it gets too huge, would the APK run out of memory and get killed by Dalvik? If that is the case I am open for any suggestion as how to mitigate this possiblity. One solution in my mind is that have a custom textview that does exactly what I explained and caches data to file if it passes a water mark. However, I am not sure how tricky it would get to detect where the user is navigating within the TextView to pull the data back and forth from the underlying data file and populate the actual TextView object.
Thanks

While I was unable to find the actual threshold, it has been discussed and suggested that extremely long text be displayed in smaller chunks. You can also write to a file which you can then read back in as necessary for your project.
Edit: regarding the TextView bookmark (for lack of a better term), you could always programmatically check to see where the user is in the TextView (checking for a certain character or string at the end of the TextView) and reading the next few lines of text into the TextView. You would have to match the getText().toString() value of the TextView against the readable text in your file.
I'm wondering now too if you would be able to do that in either direction. To save space, you could write your text to file as the user needs it, and update the TextView to only display 5 or 6 lines (arbitrary number). You could trim the TextView in either direction to save memory. You could ellipsize both sides of your text, scroll enable it, and trim/read those points as necessary.

Large images in WebView cause Out Of Memory

I have activity that parses XML feed (with news) and loads parsed data (text and image url) in WebView's, which are inside gallery widget.
Something like this:
mimeType = "text/html";
encoding = "utf-8";
String html = "<img src=\""
+ newsImageUrl.get(position)
+ "\" style=\"max-width:200px; max-height:200px;\" align=\"left\""
+ "/>" + newsDescription.get(position);
data.loadDataWithBaseURL("", html, mimeType, encoding, "");
Everything works fine, but sometimes inside news feed there is this BIG IMAGES. Well, they dont cause any problems unless you start to rotate a phone. And after couple of orientation changes we have happy Out Of Memory exception.
Well, in Android, OOM is always hiding somewhere near Bitmas, that's why most people use BitmapFactory with inSampleSize, or something more exotic. Well, supposedly, I can download and resample images, and then just load them from SD card. But for now I will try to avoid it.
Anyway, the question is - what to do with large images when they are being loaded in WebView? Is there a way to resize them (not only visually)? Is there any way to clear memory occupied by WebView onOrientationChange (webview.freeMemory() doesn't really helps).

Actually, you don't have so many choices. Freeing memory doesn't help as your images are still allocated in memory, and the images are too big to fit.
The only workable way is to reduce their size, either at the source (this way you have nothing to do programmatically) or at download time, before you display them (you save them scaled down to the SD and you display these local copies instead of the source images).
This depends of whether you have to use the full-scale images at some point. If not, there's absolutely no point in keeping them so large.

Anyway, the problem was not in webview large images.
I downscaled app and apparently the problem was in my gallery widget design. To be more specific in graphical interface elements that surrounds it. Even with empty gallery after couple orientation changes I got oom.
And I found the reason to it only today. I used /drawables/ folder which downscales all images to mdpi. And all phones I tested it on was hdpi. Apparently android uses some maybe no so efficient scaling method, and it's leaking somewhere there.
I moved all my drawables to hdpi and mdpi folders and crashes magically stopped.
So, conclusion - avoid using /drawables/ folder.