logical fix – change from lateinit to a var and handle nulls with

?

If I do that, should I define custom public backing property?

looks hacky, but let me try

it’s not hacky at all, it’s the only right way

I guess it would also make backing field public

Another possible solution is to specify use-site target, but I’m not sure if dagger supports method injection:

@set:Inject var presenter: StartViewPagePresenter? = null

Got it, thanks

Seems to work fine

Is there a way to enable auto suggestions (under alt+enter) for static imports? Or is this a bug in Android Studio?

It’s under Editor -> General -> Auto import -> “Show import suggestions for static methods and fields"

Is anyone here using GraphQL for their apis? If so, how are you interfacing with it on the Android client?

@bryan Yes. At Hudl we’ve built a String Builder to create Queries, however other companies (I know Udacity) is just using a straight string for the query and gson for the response. HOWEVER I would highly suggest joining the apollo slack team, as we are working on a way to make this better for developers

You can get a slack invite at the bottom of their page here http://www.apollostack.com/

@john.shelley Thanks! The internets seem to be almost empty on this topic.

We were planning in open sourcing our project, but then realized it needed an overhaul so a couple of people are working on making apollos open source client great.

Apollo is Meteor decoupled right?

What is the name of the Android client library?

Yeah! project is located here, but its really up in the air as to what it will become so join the conversation in slack is what I would suggest https://github.com/apollostack/apollo-android

@bryan For temporary solution, Please have a look for this https://github.com/taskworld/kraph

@verachadw Thank you!

Hello everyone! I'm using Kotlin Android Extensions to reference view from Kotlin and on the doc it says that Android Extensions plugin supports Android flavors

but to support flavors you have to specify the flavor within the import

but this way you lose the power of Android flavors that let you switch resources by changing the build variant

Am I missing something?

I think you should only use the flavor imports when your code lives in the same flavor

generally, I doesn't matter at all which import you use as the same resource name always maps to the same id.

it's just that some ids don't exist in certain flavors

what do you mena with "flavor imports"?