If you want to use your own server you will have greater flexibility if you need to create custom functionality and I would also recommend if you foresee usage requirements getting quite large (hundreds of requests per day), however for initial development and testing I think you can rely on kobo’s own hosted solution.
Yes you have understood as intended. if you already know the forms you are using you could also hardcode the urls in (what you see when you open the form in web input mode). This url can be loaded in an iframe to view, alternatively if wanting to load dynamically the /forms api endpoint has a request to get the webform/enketo link which could then be loaded. The service that opens these is called ‘enketo’ https://enketo.org/, and is a service that integrates with kobo. You can run your own enketo server, or again the hosted solution has an existing enketo integration.
Chris
Ah yes, I can see how that might be confusing. Essentially both tools stem from the same base of standardized, open-source survey form format (OpenRosa), but have taken different approaches to how they display and interact with the forms. Kobo is specialised for mobile collection via android, and enketo specialises in web collection via browser. They have many areas of commonality (including development team), and have been made to work together to provide option to collect data both in a browser and mobile app. Things get a bit more confusing in the case we’ve been discussing as we’re using the enketo web browser on a mobile phone to replace some of the kobo functionality, but still relying on the rest of the kobo system for aggregating and storing data etc. (enketo requires another service such as kobo for this). You can read a bit more here: https://enketo.org/openrosa/ . Of note is the section at the bottom which explains some of the key differences in specific question types which can and cannot be displayed in both platforms.
Hope that helps,
Chris
You do not need to interact directly with enketo as kobo can handle this for you (it does this automatically every time you click to preview your form online in the web browser, or collet data via web). ONA is very similar to Kobo (as I understand they both were created from the same original project, however have since split to add different functionality). They both also do many of the same things as ODK aggregate, however in my opinion have improved on the core functionality in almost every way. Kobo remains completely open source and free, whilst ONA has since limited it’s free offering and provides subscription services. They are both completely inter-compatible and allow data moved from one platform to the other (including the odk aggregate platform).
I would suggest you start experimenting and see how you get on, all the platforms mentioned also typically have excellent support forums and guides to get you up and running. Don’t worry about it, we all started somewhere!
I really like Ionic and it is definitely one of the more popular, but as most things it depends on what you’re trying to achieve. There are other frameworks which are much easier to use (e.g. drag and drop style creators) which can be great for simple use cases but may be prohibitive in the longer term. Ionic is built on top of angularJS, which is an MVC framework where the rendering is done client-side (compared to ASP.net which I believe is more server-side?). This could lead to slower rendering and compatibility on older devices, however in my experience (usually working in low-resource environments) this hasn’t proven overly problematic. I’ve always been quite a fan of anything javascript as it seems to go pretty much anywhere you want it to and save me having to become an expert in too many different languages!
Ah, interesting issue regarding cross origin requests and internet security. https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Basically when running on an app there’s more freedom to send certain types of request and the app can communicate directly, however when testing in your own web browser things are stricter so I’m proxying requests via another server.
As this is no longer very relevant to kobo I suggest you either contact me direct (c.cl...@stats4sd.org) with any follow-up or post on github.
Chris