ODK 1 Developer Call - ✨ 2018-01-03 ✨

Our next call will be January 3, 2018 from 14-15 UTC (make sure to see in your timezone)

  • I will be on the call Wednesday January 3, 2018 from 14-15 UTC (see in my timezone)
  • I can't make it this time but am interested in future calls

0 voters

As always, if there are topics you would like to discuss, please share below. :arrow_down:

This will be our first call of 2018 so how about a Best Practices / New Year's Resolutions theme? I'm thinking we could each share an open source or software development best practice we find important, how it applies to ODK projects and some resources on the topic.

For example, one thing I'd like to work on in 2018 is developing more consistent and helpful practices around commit history. Some resources I enjoy include:

@batkinson probably has some good resources for this as well -- his commits are always fantastic.

@icemc might have some favorite Java 8 resources that would be useful as more of the codebases start using Java 8 language features.

@dcbriccetti has been doing profiling, maybe there are cool resources on that?

@srv-twry might have some Android MVVM best practices and readings to share.

@jknightco any favorites on the new Android architecture libraries?

@danielrees18 and @Shobhit_Agarwal have been adding some Android tests and I'd love to see some good references they've used.

If you would like to participate, please share your topics and resources in this thread! I'm thinking each person could briefly discuss their topic and then we could have some quick discussion.


Since i may not be able to attend the call, I am going to discuss everything i want to share here only.

As we all know that at Google I/O 2017, the new Android architecture components were launched which enables us to, as i quote "design robust, testable, and maintainable apps. Start with classes for managing your UI component lifecycle and handling data persistence". These components are based on MVVM i.e. Model-View-ViewModel architechture.

While there are a lot of architectural patterns available, the two most prominent ones are MVP and MVVM in my opinion. I think this has been discussed already but if anyone is still unsure about using MVVM, this is a good stackoverflow discussion about why to use MVVM, even though this discussion is not meant for Android. MVP is also good and popular but with official support i think MVVM is a better option to go with.

Since @jknightco has set-up those components for us, now i think we should start refactoring our application. The four/five major steps in my opinion would be:

  1. Create ViewModel for Views(Activity/Fragment).
  2. Wrap data into LiveData.
  3. Migrate to Room.
  4. Writing ViewModel tests.
  5. (optional) Use Paging library.

I am going to briefly discuss each step and their best practices and readings.

The first step would be to create ViewModels for Views. The official guidelines article on ViewModel is a must read.

Some best practices:

a. The View should be as dumb as possible(Free of "if/for" if possible).
b. All the bussiness logic should be implemented inside the ViewModel.
c. (IMPORTANT)The ViewModel should never hold any reference to the activity context since it leads to memory leaks.
d. Keep the fields as final as possible(General guideline).
e. No need for onSavedInstanceState method now :slight_smile:

Here is a blog post which explains how to refactor with the ViewModel class.

The second step would be completed while working on the first one.

The third step would be to migrate to Room persistence library. Here also the official guidelines article is a must read. Here is an awesome blog post by Florina Muntenescu, about how to migrate to room incrementally using manageable PRs.

The fourth step would be to write unit tests to check the functionality of the ViewModels. I haven't written any unit tests for the ViewModel yet but this blog should suggest some basic ideas.

The fifth and the final step is optional in my opinion. Paging library is not stable yet, but it will be very soon. It helps load data incrementally when needed leading to improved performance. It's not very popular yet but certainly something to keep an eye on.

Github workflow: We can create these four/five issues as parent issues. Then we can create child issues for each parent issue which would mean we are incrementally refactoring our app and allow wider participation from the developers. Needless to say, it would make PR review much easier.

If i have missed anything please do let me know :slight_smile:


One best practice I'd like to talk about is helping devs interact with the user community through the forum (especially support, feature requests, showcase). I think this is important for a few reasons...

  1. If you don't know what users are doing in the field, it's harder to make good design decisions and come up with features that matter. The more devs participating in the user community, the more likely it is that we build the right things.

  2. Core committers spend a fair bit of time with the community. It's time that they can't use to review code, setup infrastructure, etc. Other devs helping with the community means core committers can do the things that make it faster and easier to contribute.

  3. It's pretty fun and rewarding. Users are working on socially relevant problems and are just really grateful for any help. That five minutes you put in may save a user five hours of work!

A lot of open-source projects are tools for devs, so the dev community is basically the user community. ODK is a little different because our tools aren't for devs so I think we have to actively encourage this practice. Perhaps we can discuss how best to do this on the call.

In the meanwhile, here are some resources on the "everyone on support" idea that I find useful...

1 Like

The dev call will start in about 25 minutes. The link to join is https://www.uberconference.com/opendatakit and notes will be at https://docs.google.com/document/d/1hszoTRzWG5W04JXgcBzE7BcdEZGB75lA8tftTNZ5lzA.

Great call today, it was very nice to catch up with everyone and hear that 2018 is off to a good start across the world!

The notes have been updated and include a link to the call audio.


  • Release frequency has been good, no major issues but there is a need for beta testers who use alternate servers
  • The Technical Steering Committee has now been established; Yaw will schedule the first call
  • Google Summer of Code project application deadline is 1/23 so we need to come up with project ideas
  • Developers need documentation on why and how to engage with user community on the forum
  • Will start concrete conversation on establishing commit message guidelines