Size of library.

[levibostian]

Size of library.

[harkin]

@levibostian ah, you can safely disregard everything I said above then. I was talking specifically about this repo which is our general purpose Java bindings for the Intercom API.

The Android Messenger is large for different reasons. We've been a lot more deliberate about what dependencies we have there and so don't use ones like Guava or Commons. You can see the dependency list here. Briefly, it's the Square networking stack, Glide for images, and Gson for JSON parsing. If you use the same dependencies in your app it might be useful to check out this guide on how to use them transitively in your app.

I'm going to close this here as the issue isn't with this repo, if you want to continue the conversation could you open an issue here or just write in to us in Intercom; we're more than happy to help where we can 😸

[harkin]

Hi @levibostian,

This library wasn't designed for use in Android apps and, more importantly, shouldn't be used in them.

The main reason not to use it is security concerns: the naive integration involves shipping your personal access token in the apk that gets installed on every phone. It's trivial to retrieve this from the installed apk and once someone has your personal access token they have the key to access most/all of your data in Intercom and the ability to write whatever they want too. Normally we recommend having an intermediary service on a server you control that knows your PAT and can communicate with Intercom, having your app talk to that server with some verifications that requests are coming from your app, and only exposing the subset of functionality you need to your app (eg user updates and conversation replying instead of everything).

Another alternative is to use https://github.com/intercom/intercom-android which is our Messenger designed for Android. It doesn't have the same breadth of API abilities in there, instead it's focused on the life of a single user in your app with the ability to update that user and log events for them. Security is also a concern here but we've been deliberate about how api keys are scoped for the mobile Messengers and we've also built in a request signing process that we call 'secure mode' to verify that traffic to Intercom is coming from your app.

To go into a little detail about why this library is large the first place to look is it's own dependencies: Guava, Jackson and an Apache Commons codec are the three largest at 14k, ~2k and ~1k methods respectively. Guava is full of useful niceties and when we aren't constraining ourselves with a method count limit it's handy to have. I'm not familiar with how deep we've gone on it but I doubt we'd want to drop it as a dependency without a compelling reason. Jackson is a similar story, it's the JSON parsing library of choice here mostly because of familiarity to the writers and maintainers. Off the top of my head I don't know if Gson is substantially smaller and it's doubtful we'd switch to something like Moshi here. The Commons dependency is used for very few things and could be removed quite easily I think. Removing it is not a priority for us at all; PRs are always welcome :)

It looks like you're already using Proguard in your project (io.a is a giveaway) so i don't think there's much else you can do to make the library smaller. There are some optimisations you could make like also using Jackson if you need to do JSON parsing in your app so that they can share a dependency but that's about all.

I'm really curious why you are using the Java library in your project instead of the Android one. We've found that generally the limited API we expose in the Android library is enough for what people need to do; if that isn't true we'd love to know so we can expand it.

[levibostian]

@harkin, I am super sorry, but I am indeed using Intercom Android in my app. Simple mistake on my part.

Proguard does it's duty, but I am trying to slim my app down to cut down on compile time. Each compile of my app takes about a minute and a half to 2 minutes from an incremental build with all Gradle optimizations enabled. Cutting down on my libraries seem to be the next step.

I really wish Commons was broken into multiple dependencies. In a previous project I worked on, I found out I was only using 4 functions in the whole library and just pulled those functions out of the source code. Useful library, just so big.

Those libraries are useful to have in the library, I understand that. It seems like a pretty heavy library where I only use it for the messenger.

I don't want to take more time on your team to do this. Perhaps I will fork the Android lib and cut it down myself. I really appreciate the help!

[levibostian]

@harkin thank you for the time. Again, sorry about my mistake. You were very helpful.