Use lint to define what is public and what isn't

[SUPERCILEX]

@samtstern There have been multiple instances of people using non-public apis (#408, #490, and probably more) so I think we should define what is public and what isn't here. Firebase Job Dispatcher took the approach of putting everything in one package and making it all package private. I really don't think that's a good idea since it makes developing the library difficult and confusing. Instead, we can use the @RestrictTo annotation from the support lib folks to get around this problem.

I've left the provider package public because it could theoretically be used out of FirebaseUI, but all of this is up to debate. I've also left some helpers public for the same reason. @samtstern what are your thoughts on this?

[samtstern]

Never knew about this! That's pretty cool. Can you add a screenshot showing what will happen in Android Studio if you try to use a restricted class?

[SUPERCILEX]

@samtstern Sadly, there isn't an inspection for this in Android Studio yet. However, lint will blow up on you if use a class marked with @RestrictTo: I found out about the annotation when we encountered that bug in the android gradle plugin alpha3 (samtstern#3 (comment)). So it will look like this if we run lint manually:

@RestrictTo:

@VisisbleForTesting:

[samtstern]

Looks great, thanks!

[goncalossilva]

I've left the provider package public because it could theoretically be used out of FirebaseUI

This has been immensely helpful for us at Doist. Our UI flows are a bit different from what Firebase proposes, and it has been a great experience to be able to leverage all the work in the providers without having to use the UI bits as well. We hope this remains in the public API 😊

[samtstern]

@goncalossilva thanks for the feedback. This change only affects lint so you can continue to ignore it, but it at least makes the division clear. Do you have a public app that uses these modified flows? I'd love to check it out.

[goncalossilva]

@samtstern It's currently in review, should be out in about 2/3 weeks, and will A/B test two different approaches. We'll let you know once it's out.

[pedrodanielcsantos]

@samtstern our work with the integration of FirebaseUI (the authentication module) where we're using the providers directly, as @goncalossilva said, was released yesterday, so in case you want to take a look the work we've done, you can check Todoist 👍

[samtstern]

@pedrodanielcsantos thanks for the pointer, this is awesome! I love Todoist, will download the update and take a look.