This is a pretty broad question and there are a lot of things you need to consider. For example, the modelling of your questions, and persistence -- storing them in the DB. I made a similar Android app a few years ago.
The first thing I suggest is working in incremental steps; things are much easier if you start out with, say, multiple-choice questions only (that all have four answers). Then once you have that working, add other types of questions.
For modelling your object domain, I suggest starting with a single base Question
class. This can contain some common properties, like the unique ID, the name/shortname, perhaps some sort of difficulty metric.
After this, you can have sub-types of questions, such as a MultipleChoiceQuestion
, a ShortAnswerQuestion
, and an EssayQuestion
. They may have other properties (like the list of possible answers for mutliple choice).
Mapping all this to a bunch of tables is not trivial. The usual method is one table per class; another option is one table with all the properties for all classes, and some sort of 'type' discriminator. I suggest the former, since it's a cleaner separation of attributes.
Finally, in terms of random, there are two approaches: random on the database level (more efficient, since it returns less data) or random on the application level. The difference is "hey database, get me N random questions" vs. "hey database, get me all the questions; hey application, pick N random questions."
To leverage the DB, you can use this answer here, where they use ORDER BY RANDOM() LIMIT N
. I don't know about SQLite, but in SQL Server, with large data sets, this can be extremely slow; if you have a lot of questions, profile it and see if this is too slow for your app.
If you have a base Questionstable with all questions, this will work quite easily for you. If not, you may need to do something similar where you poll for
Amultiple choice questions,
Bshort answer questions, etc. where
A + B + ... = N` number of questions you want.