Develop Reference

Link one resource file to another instead of duplicating

According to this thread, in order to make Hebrew available on all devices, I need to maintain two similar files of each resource type, one in values-iw and another in values-he. Having a ready-to-use strings.xml, I was wondering if there's a way to "link" the files in one of these folders to the files in the second folder instead of making an alias for each string (exampled here).
Thanks!

Changing drawable (PNG) in android application

I have a standard aplication. It uses resources - PNGs that are when programming in the DRAWABLE folder. They build up menus, buttons etc etc. ... Classic application nothing special.
And what I need to have is - "theme" support. Lets say I use this PNGs in my app:
menubutton.png
scrollbotton.png
arrwo.png
and these are in the DRAWABLE folder.
And I would like to be able to change the THEME of the app by changing this PNGs for different ones. Lets say I have PNG's with same names, but under a different url:
.../template1/menubutton.png
.../template1/scrollbotton.png
.../template1/arrwo.png
and than I have a another "template"
.../template2/menubutton.png
.../template2/scrollbotton.png
.../template2/arrwo.png
IMPORTANT: Of course all the PNGs have exactly same size, and name
So and the app shall have the functionality to download this PNGs and replace the ones that are currently in use. The important point is that the additonal PNGs from different templates HAVE to be availiable online - I dont want to ship the app with many templates that would not be used.
Can you please confirm this can be done and that it should not be a problem?

The Drawable resources are packaged in to the application and cannot be modified. You idea of using an SD card will work (or you can use the applications sandboxed directory), you just need to manually load the png resources (ex. myImageView.setBackgroundBitmap(...); [pseudo-code]).
As a note: If I ever open an application that immediately tells me to wait since it is downloading resources, I will force-close it and uninstall. Applications on Android, iOS, Windows, etc. should work right away without the need to download more resources. If you want a default "theme" then package it with the app, don't make the user download it (which will cause problems if the user is on mobile networks or doesn't have an internet connection when they open the app)

Using large text files in different languages in Android

In the app I'm building, I'm using multiple languages. It's easy to add a different language into an app by adding a new folder (for example: values-fr) and adding a new strings.xml file in there. But I have pretty large text files (complete articles) that I need to add. These articles are also written in different languages. What is the best way to add them to my app?

I'd consider using res/raw-<qualifiers> as alternative to the assets. The raw folder can store arbitrary files in their - you guessed it - raw form. For example, a 'Hello World' article written in French and English, would be stored under:
res/raw-fr
res/raw-en
The raw resource can then be opened by calling openRawResource(int id) on a resources object, similar to how it works for other resources like drawables, strings etc. The id's generated by the framework will be in the familiar format of R.raw.filename (without file extension).
The benefit of using this approach is that you can fully leverage Android's localization system, meaning that as a developer you basically don't have to worry about any of that at all. You can also easily add more qualifiers to further filter on device characteristics (e.g. screen size, density, platform version etc etc - see here for a full overview). The downside is that it imposes some limitations in terms of the original file name/extension and doesn't support a proper folder/file hierarchy.
The 'better' approach (/raw vs /assets that is) will probably depend on your project's requirements.

I would probably use assets -- that is, create assets/data/fr/ and store the fr files there. Note that assets require explicit extraction -- which probably is good since you may save memory having only one set of articles installed.
Another possibility is to place everything on an http server, and thus make both keeping and accessing the articles somebody else's problem :) .
BTW, if you files are really big, you will have to install the application without them, and download the articles later. (There are restrictions on the apk size.)

Is it possible to make use of the Android resource resolver on a self-created folder in the file system?

I'd like the ability to "overwrite" the Android resources packaged within my apk by having the app periodically download a zipped file containing overrides that follow the same naming convention as the source does. For example, the zip might consist of the following paths:
res/values/strings.json
res/values-land/strings.json
My code would parse those files and produce a Map> that would map the string resource id to a folder->value pair (or something along these lines). At this point I'm really only concerned with strings and images (maybe arrays), but not layouts, etc.
To the point: Is there any method available, that, given a list of folder names, would tell me which one the Android resolver would choose based on current state? I'm assuming this is difficult because the compiler breaks everything down to ids, but figured it was worth a shot. Any ideas?

Is there any method available, that, given a list of folder names, would tell me which one the Android resolver would choose based on current state?
No. You are welcome to roll this yourself based on Configuration, DeviceMetrics, and kin. You will also need to create your own parsers for your own files, as Android's resource system only works with resources, not arbitrary files retrieved from arbitrary locations.
The expectation in Android is that if you want to update resources, you update the app, probably because there were also code changes as well. Admittedly, this approach has its limitations.

organizing android apps in eclipse

I have an app on the iPhone and need to port it to android. For this I would like to group screen related files like classes and xml per screen in one "screen group" per screen somehow, ideally also strings and other value files
if I use folders I can only group res files separately and src files separately.
what would be the best way?
Thanks very much!
EDIT:
If that should not be possible, how to best then solve this issue? Do you create a subfolder in the src and another in the res for each screen?

The way you group files for the iphone is not possible for an android project. Android has pre determined folders which hold specific files, if you break this structure, your building process will fail. Its not ideal but that just how it it.
When it comes to source java files, they follow the concept of packages which are basically folders. The 'src' folder is the part where you can create sub folders as you desire. If you are adamant about keeping the files related to a screen in one place, you should create the layouts with java code and not use layout xml files.
But using xml layout files make development much easier and faster. Consider that as the presentation and java files as the logic+data. So group java files as you want and leave xml files in the layout folder with easy to identify names.

android uses certain directory layout for project structures (i.e. convention over configuration). Basically you will want to put your XML layout files in res/layout directory. Please read http://developer.android.com/guide/developing/projects/index.html#ApplicationProjects for further information.

Unfortunately, there's no easy way to do this in Eclipse. You can't create custom directories in your Android app's /res directory, you can only use permitted dir-names. E.g. you can't have a /res/layout-myscreen1 and /res/layout-myscreen2. You also must put your resources in /res, and your code files in packages, so they're at separate places in your project.
You can use Working Sets to group related files together however, but they're quite painful to use IMHO. Check the eclipse docs and tutorials out on them.