Welcome prospective Google Summer of Code or Outreachy participants! Please use this thread to discuss your ideas for the Device to Device Transfer App project.
Introduction
One common requirement organizations using ODK Collect have is to transfer filled forms from one device to another without having access to a Wi-Fi network. This is important for forms with multiple parts that are completed by different people and for forms that need to be aggregated to a single device (e.g., a supervisor) for review before sending.
To explore this idea, you will build a standalone Android application that shows users a list of forms and instances from Collect. A user can then select a form or an instance and send that form to a nearby Android device also running Collect. You will use some combination of Bluetooth or Wi-Fi direct for this transfer. To make it as accessible as possible on a wide range of devices, NFC cannot be used. Alternately, this functionality could be built directly into Collect.
@Shobhit_Agarwal@LN
Hello , I am Ankur Mittal a gsoc 2018 aspirant, I have 3+ years of experience as android developer.
I would like to work on project to build accessory application to collect app for transferring data from device to device.
For those considering this project, note that Commcarehq uses WiFi Direct to transfer files between devices. Commcare shares some DNA with ODK so it may be useful to look at their approach.
I agree the functionality could either be in a separate app or directly in Collect. The CommCare example of direct integration is a very interesting one, thanks for sharing, @Ronald_Munjoma! From what I understand, their model focuses on the "supervisor sends completed forms" use case and forms can't be modified by the recipient. Is that right?
The advantage of a separate app is that it make experimentation somewhat easier. As @Akshay_Patel points out though, building the functionality into Collect would make it easier to use. Because Collect is mission-critical for a lot of organizations, the changes to it would have to be tightly scoped and not affect how it works for most people. I would not advise trying to introduce new modes, for example.
I would encourage anyone considering this project to think about building it up iteratively. What's the smallest and simplest bit of useful functionality? For example, sending a blank form from one device to another would be quite useful in a disconnected environment. What would that functionality look like in Collect? In a separate app? That would be a great first, shippable milestone. What other such milestones could you come up with?
What did I learned by doing this?
Wifi direct is API for android is not easy to use.
There are lot of discsussions online about issues with wifi direct.
I would personally refrain from using something that is not yet proven to be reliable.
I don't want to put Wifi direct in bad light but this is what I experienced.
Hi everyone,
My name is Vrushabh Jambhulkar. I have experience in building Applications for mobile, as well as familiarity with drafting computer applications. I have developed more than 15 Apps in the past 3 years out of which 5 were full-stack developments, & were done solely by me.
I would like to join you for this developing project as a part of GSoC'18. This project looks very intriguing and would surely be a great experience developing it.
My github username is vrjgamer.
After reading all the chats here it seems like Wifi Direct has some issues with connectivity. @adam.butler at the end, you switched to bluetooth for your project.
As far as i know, data transfer using wifi direct will be way faster than bluetooth.
@LN@Shobhit_Agarwal@Akshay_Patel@adam.butler So how about combining both the technologies bluetooth and wifi direct? What if we use bluetooth for connection maintenance and wifi direct for data transfer?
Thanks @vrjgamer, that's a good question. You're right of course that Wifi is faster than Bluetooth, but in my experience, bluetooth is "good enough". IMHO the advantages of shaving milliseconds off the transfer time are outweighed by the disadvantages of implementing and maintaining the extra complexity, as well as handling the UX required by increasing the potential points of failure.
I completely agree, transfer speed should not be a significant consideration.
I'll admit it has been a while since I've tried to build on top of Bluetooth (pre Bluetooth 4!). It used to be that the pairing process was painful and unreliable but @Akshay_Patel, @dexter21 and @adam.butler, your recent experiences seem to suggest otherwise. I would say ease of discovery and pairing is critically important for this feature.
Ultimately, it will be up to internship applicants to make a compelling case for the technology they wish to use and/or include some time for technology selection in the project timeline. The proposals should make it clear what criteria they find important for selecting an underlying technology to build on. The project timeline should include time for making sure discovering, pairing and transfer are robust and strategies for verifying that they are.
For those interested in this project, I highly recommend starting to think through not just the final state of the feature but also how you would build it up incrementally and verify that it is robust.
Pairing, or discovery, is still pretty painful, in my experience. That's why we ended up using NFC (Near Field Communication) for that part. But I'm excited to see what other people come up with!
I just came across an interesting project building on top of ODK Survey called EpiSample that provides the ability to transfer files via WiFi direct (Google Play, Github). I've tried discovery and pairing between three very different devices and it works really well so it's evidence that it is possible! If you'd like to try this for yourself, one of the devices needs to be set as the team lead device in Admin Settings > Device belongs to team lead.
Some of you may be interested in studying some of the approaches there. The code is Apache 2 licensed so parts of it could even be cited and used.
@ln Thanks for sharing the links.
The app works well. I didn't face any connection drop issue.
But, there are a couple of points that I would like to share.
It wasn't mentioned anywhere about setting one of the devices as lead. If you hadn't mentioned it, it would have been difficult for me to use it. Correct me if I am wrong, it hasn't been mentioned about this setting in README(there is no README). Nor does description on play store mentions it. My point is that, for such applications, the user interface for establishing connection should be kept as simple as possible.
App uses a socket connection to communicate with the other app. The port number has been hardcoded. See here.
This is what should be avoided in Supervisor app. One of the possible ways to do it is using Local Service Discovery. See here.