I've passed your query over to the Medic Mobile (formerly FrontlineSMS:Medic) team, who will be in touch. They'll be able to provide details of how you get a FrontlineSMS build with TextForms bundled.
Cheers, and best of luck! We'd be curious to hear how you get on.
Thanks a lot for your answer. So far I haven't been contacted by Medic Mobile, is there any way I could get touch with them directly and/or can you think of someone else I could speak with?
Sorry you've heard nothing. Email them at firstname.lastname@example.org and see if you get any joy.
we've come across similar problem that the Forms module is closed source and we also needed the UI to be in another language (Chinese). Therefore we chose JavaRosa as the mobile client instead. Screenshots.
It should be possible to convert the JavaRosa format (which is plain text, delimited by tags, submitted via either SMS or http) to the FrontlineSMS Forms format (the methods for encoding/decoding should be available, although not the direct source code, but you can re-use the jar files), so that the messages can be read by FrontlineSMS (desktop client).
Let me know if you have any questions.
This is exactly what I thought of as a solution, but the Forms module of FrontlineSMS is not powerful enough when it comes to creating complex questionnaires like the ones I need (for example, it doesn't support multiple choice questions or "child questions"). For what I've read so far, TextForms does support this, but it doesn't have a graphic UI in the cellphone and all the coding has to be sent manually.
What I was hoping to do is to establish a bridge between the TextForm database in FrontlineSMS with JavaRosa. However, I think it is also possible to establish a more powerful solution through integrating it with a OpenRosa aggregate platform, like ODK, openXdata, etc. (please reffer to http://www.ictedge.org/node/924).
I would love to hear more from the technical side on how you managed to integrate JavaRosa with FLSMS.
Thanks a lot,
I am aware of ODK and ODK aggregate (not yet OpenXdata though), but the difference between ODK and JavaRosa is that ODK requires Android phones (more expensive) and data connection, whereas JavaRosa (same as FrontlineSMS Forms) only requires a bit cheaper Java enabled phones and no data connection (if you transmit via SMS). That was the reason why we haven't used ODK but JavaRosa, because the recent project (links to the technical model) I am working in is based in small villages in rural China (=limited resources).
My previously mentioned idea to use/write an adapter for the JavaRosa inbound messages towards FrontlineSMS is just a theory, we haven't actually used it ourselves, but from what I saw from the code, it should be possible without a problem, since the decoding and encoding methods are available. But I haven't fully thought it through if it actually makes sense; probably only if you are making use of any of the FSMS module that require the FSMS format for inbound messages (i.e. PatientView maybe, not 100% sure), otherwise you might not need such thing.
I haven't used JavaRosa in combination with the FSMS desktop client myself yet, just used JavaRosa and 'FSMS for Android' (a current port for Android I'm working on) as a SMS hub and for forwarding messages to the (custom) backend server and auto-replying messages to it's senders, that's all.
Thanks a lot for your insights. I'm aware that ODK is thought for high-end mobiles, but for what I read in the article, the idea is to use only the aggregator (not the collector), instead of building a custom back-end, and use JavaRosa for the data collection. This is possible because JavaRosa and ODK (and openXdata, and CommCare, and so on) use the OpenRosa standard, which is based on the W3C XML forms standard.
Right now I'm in another phase of the project, but when (if...) I get to the coding and back-end solution, I will let you know.
Cheers, good luck and thanks a lot,