JVM support

[nbransby]

What feature would you like to see?

Pure java version to run in non android environments, I believe the original sdk supported this, what was the motivation to drop it?

Before I attempt such as task how difficult would it be to fork this project and remove the android specific code?

How would you use it?

Desktop java (In my case an Android Studio / IntelliJ plugin)

[samtstern]

@nbransby this is unlikely to happen with the Android SDK, and attempting to do it yourself would be somewhere between "very hard" and "impossible" depending on which features you're talking about.

I think a more realistic feature request would be to allow for client-safe authentication in the Firebase Admin Java SDK. That's what we recommend for use in "pure Java" environments but right now it authenticates with a service account which means it would not be appropriate for something like an Android Studio plugin which wouldn't always run on your trusted machine.

Does that make sense?

[nbransby]

Yes makes sense, does it support all the realtime sockety goodness of the android sdk? Im primarily interested in using the firestore from a client perspective, don't need the UI bits of auth obviously, would be using a custom auth system

[samtstern]

Yes the Java SDK has support for real-time queries using Cloud Firestore.

That SDK is open-source as well and you can check it out here:
https://github.com/firebase/firebase-admin-java

I would suggest opening an issue on that SDK requesting the ability to authenticate as a user for Cloud Firestore. @hiranya911 is the maintainer there, so I am cc-ing him here to let him know I sent you!

[nbransby]

Well that went well 😆 firebase/firebase-admin-java#206 (comment)

So tell me more about the "very hard" option? If its just pulling out a firestore wrapper, doable?

[nbransby]

So I've started with a fork of this repo and replace all apply plugin: 'com.android.library' with apply plugin: 'java-library', commented out android { } blocks (except for source sets) and added an android-polyfill module that implements the required android functionality.

So far I have firebase-common, protolite-well-known-types and firebase-database-collection building and all tests passing. But with firebase-firestore I get the following errors from protobuf:

Cause: protoc: stdout: . stderr: /Users/nbransby/Documents/firebase-android-sdk/firebase-firestore/src/main/proto: warning: directory does not exist.
google/api/annotations.proto: File not found.
google/protobuf/struct.proto: File not found.
google/protobuf/timestamp.proto: File not found.
google/type/latlng.proto: File not found.
google/firestore/v1beta1/document.proto: Import "google/api/annotations.proto" was not found or had errors.
google/firestore/v1beta1/document.proto: Import "google/protobuf/struct.proto" was not found or had errors.
google/firestore/v1beta1/document.proto: Import "google/protobuf/timestamp.proto" was not found or had errors.
google/firestore/v1beta1/document.proto: Import "google/type/latlng.proto" was not found or had errors.
google/firestore/v1beta1/document.proto:86:3: "google.protobuf.Timestamp" is not defined.
google/firestore/v1beta1/document.proto:93:3: "google.protobuf.Timestamp" is not defined.
google/firestore/v1beta1/document.proto:101:5: "google.protobuf.NullValue" is not defined.
google/firestore/v1beta1/document.proto:116:5: "google.protobuf.Timestamp" is not defined.
google/firestore/v1beta1/document.proto:136:5: "google.type.LatLng" is not defined.
google/firebase/firestore/proto/maybe_document.proto: Import "google/firestore/v1beta1/document.proto" was not found or had errors.
google/firebase/firestore/proto/maybe_document.proto: Import "google/protobuf/timestamp.proto" was not found or had errors.
google/firebase/firestore/proto/maybe_document.proto:34:3: "google.protobuf.Timestamp" is not defined.
google/firebase/firestore/proto/maybe_document.proto:44:3: "google.protobuf.Timestamp" is not defined.
google/firebase/firestore/proto/maybe_document.proto:55:5: "google.firestore.v1beta1.Document" is not defined.

These files do exist in /protolite-well-known-types/build/extracted-protos/main but don't seem to be being picked up. I don't know anything about protobuf so hoping you might have some pointers?

My gradle changes are here if you are interested:
https://github.com/firebase/firebase-android-sdk/compare/master...TeamHubApp:master#diff-ca85ccc77c0711a2ebabca587683e98a

[wilhuff]

The protocol buffer compiler (protoc) generates Java sources from .proto files. The resulting .java files are then compiled as usual.

Protoc needs all the .proto files for dependencies to be available when compiling, even when those are otherwise being built into separate artifacts. I can't see anything in the changes you've made that would perturb that setup, but the error you're seeing suggests that protoc is no longer able to see the .proto files from the protolite-well-known-types library.

The way this is supposed to work is that each jar result should include the protos used in itself as resources. Then anything that depends upon it should be able to extract those onto the filesystem such that protoc can then find them. In the android build, I see the common types ending up in firebase-firestore/build/extracted-include-protos. You should be able to see those there too.

[nbransby]

Yes I noticed that, they are not there on my fork but are present on the original - any ideas on how to get them back?

…

On Fri, 28 Sep 2018 at 19:11, Gil ***@***.***> wrote: The protocol buffer compiler (protoc) generates Java sources from .proto files. The resulting .java files are then compiled as usual. Protoc needs all the .proto files for dependencies to be available when compiling, even when those are otherwise being built into separate artifacts. I can't see anything in the changes you've made that would perturb that setup, but the error you're seeing suggests that protoc is no longer able to see the .proto files from the protolite-well-known-types library. The way this is supposed to work is that each jar result should include the protos used in itself as resources. Then anything that depends upon it should be able to extract those onto the filesystem such that protoc can then find them. In the android build, I see the common types ending up in firebase-firestore/build/extracted-include-protos. You should be able to see those there too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUob8cIhQDqcP-botj_Q-MxjnJvBA7yks5uflhcgaJpZM4Wlv9k> .

[nbransby]

I've got auth/functions/firestore from this sdk mostly working on the JVM now - and in the end without forking the source. Instead I have written a firebase specific android polyfill that implements the android sdk classes that are used by the project

[samtstern]

@nbransby that's badass! Would love to see a writeup once you're done working on it.

[nbransby]

@samtstern intercepting fire auth calls via google play services and replacing them with REST API calls is proving the most difficult mainly because I have to work with the obfuscated decompiled class files 😢

is there any plans to open source auth?

[samtstern]

@nbransby we'd like to open source all of our SDKs! Auth is trickier than most because it depends on the Google Play services app on your phone so even if we open sourced the client SDK it would still be missing the heart of the implementation for many parts.

[nbransby]

Understood but would still be useful for doing something such as this - I have got it working by removing the auth module and implementing it by hand using the REST API (only using custom token sign in currently)