Problem

You have a fixed set of information with a simple structure that you wish to deliver to clients.

---

Questions to Reflect On

1. Do I expect this information to significantly changed or modified ever?
2. Do I expect to increase the amount of information available?
3. What kind of help do I have? Do they have a background in software engineering or is it someone of a different profession that has to wear a lot of hats?
4. What is the scale of the project? Are you expecting a large amount of users or just people interested in a very niche application?

---

JSON or XML

JSON and XML provide similar services: they are both data transfer protocols. If the information is not expected to grow both might be a great option. If its public information, just serve these files statically over nginx. You can point a worker with limited software engineering experience to update these files; they're just files in a folder presented in a human readable format... its extremely simple to do. These updates should be minor and infrequent.

JavaScript Object Notation(JSON) Pros

• solid browser and backend support
• small size and fast parsing by the javascript engine
• very human readable, easy for the untrained eye to make changes

Extensible Markup Language(XML) Pros

• standard meta-data option
• supports namespaces
• solid backend support and is often baked into frameworks

This article explains XML and JSON differences really well (in 2020) if these highlights were not sufficient for your investigation.

---

Database System

There are a plethora of database systems out there. Their job is to efficiently retrieve specific information from a large volume of data stored. The key reason to use databases is scalability. Scalability means a number of things; I view it as adapting to drastic change. If you expect this information to frequently change or grow, go with a database.

Object Relational Mapping (ORM)

Databases can be cumbersome to use. I would recommend using an ORM on top of them. These encapsulate a database and makes it more user friendly (language specific). Room makes sense in your use case especially for java android development. Encapsulation also allows you to migrate to other databases later without change your code. Here's a good article that discusses Room and SQLite!

---

Miscellaneous

"Is it bad practice to use an XML solution?"

No. The important thing is that it works, is understandable, and runs efficiently. Just keep in mind that XML and JSON are data transfer protocols and they do THAT job well. This stackoverflow discussion may be helpful to gain a better picture of what that means; be sure to read more than just the accepted answer.

"It doesn't seem to be using too many resources and it isn't running slow at all when tested on a few devices."

Although testing for functionality is great, keep in mind that your test is not a load test and does not verify what you're trying to confirm. I would explore load testing, Wikipedia is a good place to start!

I have a collection of 350 locations in the United States with each containing about 25 subcategories.

The main issue is scalability

Will you, in the next few years, keep just a few hundred locations, or do you imagine, that, if your software becomes successful, your data would grow to many thousands of locations?

If yes: choose SQLite because it could store many records, in an efficient way. Don't forget to have a good database schema with appropriate indexes. See this and read about database normalization. Also, an SQLite database could later be migrated (with efforts) to PostGreSQL.

If no (your data has just a few megabytes): keep JSON or XML. The data is in the page cache.

Consider also YAML, and sometimes a mixed approach.

don't forget to document how your data is organized and accessed.

See also the data persistence chapter of this draft report

I would suggest using JSON. Reason below

JSON vs XML

• JSON is lightweight than XML and would take fewer resources(network and storage). Performance of the app increases.
• JSON parsing is easy and as mentioned above, its trivial.
• JSON is friendly to javascript, in case it's required.

JSON vs SQLite

• 350 data set with 23 attributes, can be easily managed by JSON. RDBMS is not required.
• SQLite becomes an overhead. It's an extra layer and layer comes with a cost. Especially if the application is containerized, the architecture becomes complicated. One needs to deal with volume mapping etc, in case of JSON you can keep the data as part of the application code.

Importantly, since data is static, keep the application stateless by keeping the data alongside the codebase. This makes lot more sense from architectural perspective.

Go with JSON.

Advantages :

1. Low overhead ( Vs SQLite )
2. Lightweight parsers like Jackson available using which you can easily convert your data into custom object or data-structure if you need.
3. Maintainable. As most of the developers understand the format.

Undoubtedly, among all of these RDB is the most efficient one, both in terms of storage and query response. I personally do not see any point in using xml and json as these have been traditionally used for exchange of data and are inefficient for storage and queries.

I would suggest that you evaluate the following:

a) how are you going to store the data: single file vs multiple files(for example by subject)

b) are you going to be doing updates on the strings or just appending(SQL will be better suited for updates but if it just reading data after a batch processing flat files might be better suited)

c) How complex are the queries that you want to implement.XML and SQL are better suited for queries that might try to address metadata (date stored, original location address, etc.) than JSON

Once you determine what you want to optimize: whether it is on adding metadata, fast updates, fast querying, ease of storage, fast retrieval of subject files, etc. then you can decide the tradeoffs with other less important goals. In this specific instance the devil is very much in the details.

well that depends on the situation or what you want. if you want to the data that changes from time to time or maybe after a specific period of time then you have to use Json or XML, But if you are using static data then you have to Database , Room will the best option for you.

In most cases it would be better to use a database because it increases readability and maintainability. Especially if you want to show these information inside a kind of list-view. If you use JSON or XML you'll have to parse or write a lot of code to switch between things or load them with a good performance. Consider the case of using Room, LiveData and a RecyclerView, this will reduce the code you'll need and improve( a lot) performance and readability of your app code. By the way you should provide more information about how you want to use and where you want to show these information. XML (or the Android resource system) should be used if you plan to use the resource system itself with its qualifiers to reduce your work. Most of the time JSON is used to communicate outside or with another app in an easy way or for REST requests/responses.

The one option that wouldn't make sense to use at all for your use case is SQLite. Unless you plan on running specific queries on the data for preprocessing before loading them into your view it doesn't worth the overhead (even if I don't imagine is a lot with 350 locations)

XML vs JSON serve the same usecase without much difference, read up their specifics in this website: https://www.json.org/xml.html

I would personally go for JSON due to the simplicity of the format.

Edit:

@simo-r Argument is also a valid one in regards to readability of your code. While there are libraries that can make reading json/xml easier by default Android has really good SQLite support so it might make sense to use it. Ultimately it is in your personal preference and where you see the project growing.

If you gonna simply bind data into text views, you can just store the text as strings.xml. As simple as that.