Improve developer experience regarding integrating custom data

[reactormonk]

Currently, creating queries for custom data is well documented, which is cool and definitely above average for an opensource project, thanks for that!

The process is still quite long however, and could IMO be supported by e.g. using macros (my knowledge of kotlin metaprogramming is low :-(), e.g.

@CustomContactData(ZeroOrOne)
class WhatsAppCallContact(): CustomContactTable {
  val mimeType = MimeType.Custom("vnd.android.cursor.item/vnd.com.whatsapp.video.call")
}

For the gender case, I'd imagine

@CustomContactData(ZeroOrOne)
class Gender(): CustomContactTable {
      override val isBlank: Boolean
        get() = propertiesAreAllNullOrBlank(type)
  // I don't know if Kotlin supports this
  type Type = CustomGenderType
}

or as an alternative, an android-studio IDE plugin would also work. I think there's even a tmbundle format for snippets, which a lot of editors can use.

[vestrel00]

Thanks for creating this issue @reactormonk ! You made my predictions come true. Not sure if you missed it but in that same documentation page you linked, I left a note about how all this could probably use some auto-code generation like what other FOSS projects do (such as dagger-2).

I absolute agree with you! However, I currently do not have the expertise or the time to work on this. I welcome anyone who would like to contribute to making annotations and annotation-processors to auto-generate custom data code! Otherwise, I’ll do it myself. Folks might have to wait a while though since work and life are busy.

At the very least, custom data integration is something you just write once with very little maintenance and future changes. So, if you’ve got custom data you built for your app or you integrated 3rd party apps custom data like WhatsApp, please consider creating a PR for it so that it can be a part of this lib in its own module. I think others would use it :D

Thanks again for this issue. We will keep it open until the work is done. It’s important.

[reactormonk]

Whelp, that's what I get for not reading everything properly. 😁

For library adoption, front-loading work is usually very off-putting, because it's work you gotta do before actually figuring if you wanna use the library or not.

[vestrel00]

I agree with you. No arguments there 😅 I am 100% going to work on this at some point for sure, even if someone does not help me out with it 🤙

There is one thing I will say about how this affects library adoption. IMO, it heavily depends on what use case you need this library for. I initially had no plans of this library even supporting custom data integrations. I thought it was a nice-to-have so I added it in. Despite how much code and documentation I’ve written around custom data, I actually did not think it was something most users of this library will ever use. I could be wrong here and this issue you created could be a sign of that.

I believe, and I could be totally wrong here, that most folks are adopting this library especially prior to the v1.0.0 release (the first true professional production-ready version) just need to be able to perform all the essential CRUD operations on the built-in data models provided by the Contacts Provider. This does not include custom data.

For those that really need to integrate custom data, I can guarantee that they will want to rather do it with this library than without it. They’ll see past the copy-paste code and just do it. It’s pretty easy but mundane and repeatative. It will get better in time, especially when this issue you created is implemented.

Keep in mind that this lib does not just support custom data queries. It also supports inserts, updates, and deletes. You get full CRUD functions if you just write some boiler plate copy-paste code. Hopefully, people share custom data they write here in its own module so that others do not have to do the same work.

Even when this issue has been implemented and we can auto-generate all of this code, there are some cases where it's better to write it manually. Those cases are when certain logic needs to be done that the auto-generated code does not support and/or if lengthier documentation is required. So, in the future, folks can either use auto-generated or manually-written code 😁

---

Btw, there is another issue I created myself long ago that is related to custom data. Maybe it’ll interest you? #112

Also, as a side note, I think I have written more documentation about custom data than the official Android documentation. The official docs really does not cover any of this stuff that I do at all, from what I have seen.