views:

303

answers:

1

Hi everyone,

I am working on an App which let's a user answer sets of questions from a questionnaire. The questionnaire will be created and published on a web-server. The Android client periodically queries the web-server to check if new questionnaires are available.

Each item from the questionnaire will be displayed in its own Activity TOGETHER with its direct predecessor (i.e. one item + the recent one on a screen).

Now I thinking about which format to choose. The choice seems to be between XML and SQLite3. I could either transfer an entire XML-document from the server to the client. I guess representing a questionnaire with different question types (e.g. rating, categorical, ordinal, etc.) will be easier in XML since it is more flexible. Sure, I could also do it in SQL but that would produce a couple of tables which reference one another.

Well, here come the actual questions:
- how should the layout be done? Should I create a couple of different xml files (one for each question type) in res/layout?
- how should I access the questionnaire data (probably from XML)? I could pass the Uri to the file via intent.setData(uri); as well as a pointer to the current item. But I'd have to re-read the XML-file each time which will be expensive. Or I could create a Questionnaire-Object which implements Parcelable which could then be added to an Intent as well.
- The questionnaire will have to be put together. So I am wondering if there are any open-source tools which will support designing the questionnaire graphically. I've only found queXML so far. It sounds very promising but items have to be created in XML code. Are there any GUI tools?

As you can see my Android experience is pretty limited so the data question (#2) is most important to me. So any comment will be appreciated.

Thanks in advance,
steff

+1  A: 

#1 - You should create reusable XML layout elements for each section of your view, and probably put together in your Activity via inflater.
#2 - I would download a compressed JSON content from the webservice, process and put in local SQLite3 database for further reference, and history.
#3 - This is relative, since you have a bunch of screen resolution to target, you should build your own UI elements like in #1, and forget of using a open-source data representation.

Pentium10
#1 - sounds good#2 - so why JSON? And why JSON to SQLite3? What's the advantage of JSON over XML, except being less verbose? #3 - I forgot to mention: this is going to be a research tool. Devices will all have 800|854x480 and it will NOT be released to the Market.
steff
If it's a prototype, don't bother with fancy stuff. Just do as you find the easiest method that works out for you. Google for the vs. question your raise. Transferring SQLite3 database is heavier than any other method, because it transfers additional data with raw data, such as indexes, keys etc...
Pentium10
What do you mean with 'fancy stuff'? And what do you mean with 'transferring SQLite3 database'?
steff
If it's a prototype don't bother to create the best code for it. When you download a full sqlite3 database file over network, that takes longer.
Pentium10
Just because this is not going to be released to the market it doesn't mean it is just a prototype. As I said, it is intended to be a research tool with a very limited scope of employment. But it still has to run neatly.
steff