Storing R.id indices in objects is inherently bad idea. Do not teach do this!

[ac2epsilon]

While code in the book works per se, but storing R.id indices instead of strings anyway bad idea by design. Beside abstracts like split of concerns this approach is: 0. Not mutable - to fix a typo you have, yes, recompile app. 1. Not scalable - to add or remove item you have… well, todo mismo. 2. Not incapsulated - some data stored in resources, while other part (answers) stored… ups right in the code. 3. Not hashable/comparable - object by itself can not calculate basic functions. like hashCode(), equals() and even toString(). 4. Not iterable - while android has string-array resources, this not helps to easily iterate over questions. Iterating an Array must not depend on accesing external Map. 5. Not streameable - kinda the same, as 4, but related to newer source-sink pipes 6. Not serializable - you can not easily serialize Question to file or socket. Remote systems (in best event) have no clue on your resources. In worst case your indices will be associated with wrong strings (questions). Temporary solution may involve some adapter pattern to convert inner objects to transport objects and vice versa. Little better to keep all objects as static object, sole role of which to hold Map-of-Arrays-of-Questions. In production you can even to serialize and dump this holder, to speed up loading process. Anyway storing raw strings IS the way for this, while optionally in mock-time you can get them from resources for object creation (again pointless).