Has anybody implemented ]Android] Google Api Client (Sign On) with Oxygene / Elements?

Elements
, ,
1

It’s been a while since I built any Android code using Elements / Oxygene involving Google Api Client and things seem to have changed quite a bit from what I remember.

There now appears to be a reliance on Gradle build tools/services and whilst Elements / Oxygene supports dependencies via Gradle quite nicely, other aspects (as far as I know) are not supported. So, for example, all the guides that describe building a google-services.json and then adding an “apply plugin” to the app gradle, whilst adding a classpath to the project gradle don’t appear to translate to Elements / Oxygene.

I have been unable to find any references to what these build tools do. i.e. how to reproduce manually what these tools do for me automatically. As a result I cannot get even a simple Android app with Google Sign In to run.

It builds fine but as soon as I try to “build()” my Google Api Client the app crashes and in typically modern fashion there appear to be no error messages or other feedback to tell me what’s gone wrong (or what I’ve done wrong/missed/left out/etc).

i.e. if I comment out this line of code:

  mGoogleApiClient := new GoogleApiClient.Builder(self)
            .enableAutoManage(self, self)
            .addApi(Auth.GOOGLE_SIGN_IN_API, gso)
            .build;

Then my app “runs” fine. In that the activity presents in the UI. It does nothing of course since the sole purpose of the app is to exercise a bare bones sign-in and this code is essential to that.

If I leave this line of code uncommented, the app start perfectly fine but terminates (exit code 0 - thanks a bunch Google). I did have a message in the logcat telling me that I was missing a google_app_id string, which I have now added, and so no longer get this message but this made no difference to the terminating behaviour.

Does anybody have a working example of implementing Google Sign In for an Android app using Elements ?

2

I’ve used other Google APIs, such as Maps and Cloud Messages in the app i’m currently working on, but not sign-in.

i’d love to have look, can you point me to the tutorials that you are using?

—marc

3

Sure. It’s simply the Google guide:

https://developers.google.com/identity/sign-in/android/sign-in?configured=true

Since posting yesterday I have now found documentation that describes the purpose and actions of the Google Services Plugin (which is the source of the “project” vs “app” level gradle configuration requirements).

https://developers.google.com/android/guides/google-services-plugin

With this documentation I think I can manage without Google Services Plugin capabilities. I’m starting over with a barebones app and will let you know how I get on.

Cheers. :slight_smile:

4

Cool. please do keep me posted on how it goes and how you solved it, if you do.

5

I finally got this working! Yay!

First up, the google-services.json is not needed at all, at least not for just Google SignIn. I anticipate I will need to apply some of the values from that file in order to work with other Apis (maps etc).

It appears that some of my problems were due to the gradle based dependencies in the Elements build chain seeming a bit flaky, though whether this is the Elements implementation or an unavoidable side effect of mixing gradle with Elements is unclear.

The problem arises when changing the version of a dependency in the gradle file or removing a dependency. The no longer used dependency files remain in the obj\..\dependencies folder (and in the project references) but any new version or newly added dependencies are processed correctly (i.e. added). Those older versions/no longer used dependencies then cause problems in the build. The problems can appear genuine which cost me a lost of time trying to resolve them before I realized what was going on.

Just cleaning the solution doesn’t resolve things. To fix dependency issues (after changing the gradle) I currently:

  1. Exit Visual Studio
  2. Manually delete the Android folder from the obj folder in the project
  3. Restart VS and reload project
  4. Clean solution

At which point the dependency related issues are resolved and a rebuild is successful. Exiting Visual Studio appears to be necessary as otherwise the subfolders don’t get deleted (file locks being held ?). Closing the solution might help but didn’t appear to be 100% reliable, or I could just have been impatient. Either way, recycling Visual Studio isn’t much slower than recycling the solution and gives me more confidence that things have been “purged”, so that’s what I’m doing.

If you get your dependencies right first time (and assuming they don’t change in the future) then this won’t cause a problem, but in trying to resolve issues with gradle I had ended up with wrong versions and so ran into this when I set them back to the versions as used in the guide I was following.

It is also possible that my use of the v7 appcompat library wasn’t setup correctly. The Android Studio template sets this up using a gradle dependency so I decided to adopt that approach as well, resulting in the following (Elements) gradle:

dependencies {
    compile 'com.android.support:appcompat-v7:25.1.0'
    compile 'com.google.android.gms:play-services-auth:9.2.1'
    compile 'com.github.bumptech.glide:glide:3.7.0'
}

Assuming all the dependencies are correct, to get Google SignIn to work two additional changes appear to be required in Elements, additional to the steps described when following the Google Guide. Both are additions to the AndroidManifest.android-xml:

  1. a meta-data tag for google_play_services_version
  2. an activity declaration for a SignInHubActivity

Specifically:

<meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version" />

and:

<activity android:name="com.google.android.gms.auth.api.signin.internal.SignInHubActivity"
          android:screenOrientation="portrait"
          android:windowSoftInputMode="stateAlwaysHidden|adjustPan" />

Neither of these are required to be added manually when building apps in Android Studio but are not present in the project manifest (source), so I can only presume that these are added during the build by the Google Services gradle plugin.

The final duck to get lined up is to ensure that a project is correctly setup in the Google API with credentials that correspond to the application package name and (crucially) with the correct signature fingerprint which took some digging through the build log to confirm which keystore was being used.

Now to move on to Maps! :slight_smile:

6

Curious. obj\dependencies does not get cleared when the .gradle changed and gets reprocessed?

7

Nope. With my working project I just repeated the steps, changing the version of play services auth from 9.2.1 to 10.0.1.

Here’s my dependencies folder before the change:

Gradle-Before.png578×504 28.3 KB

And here it is after changing the gradle and rebuilding:

Notice that the 9.2.1 aar’s are still there along with the new 10.0.1 aar’s.

The result is build errors:

And it makes a mess of the project references, not only with both versions of libraries referenced but duplicate references:

References.png280×670 4.96 KB

FYI - this is with Elements build 9.1.100.2077 and Gradle version 2.14

8

To clarify: The before gradle:

dependencies {
    compile 'com.android.support:appcompat-v7:25.1.0'
    compile 'com.google.android.gms:play-services-auth:9.2.1'
    compile 'com.github.bumptech.glide:glide:3.7.0'
}

which was changed to:

dependencies {
    compile 'com.android.support:appcompat-v7:25.1.0'
    compile 'com.google.android.gms:play-services-auth:10.0.1'
    compile 'com.github.bumptech.glide:glide:3.7.0'
}

i.e. the play-services-auth version changed from 9.2.1 to 10.0.1, resulting in the changes in the dependencies folder as previously described.

9

Thanks, logged as bugs://77103

10

bugs://77103 got closed with status wontfix.

11

(this is being completely rewritten for v10, and our of the scope to still fix for v9.1 because it would be too intrusive a change this close to RTM, sorry)

12

Could you not at least make “Clean Solution” completely delete the obj folder in an Android project (perhaps only if there is a build.gradle in the project) ?

It’s not something I need to do every day, but when I do it’s a bit of a faff having to remember to close VS to clear out obj (the obj folder cannot always be completely cleaned out with VS open, even if the solution is closed).

This is the work around I’m having to use and it would seem (from the outside :slight_smile: ) quite a simple change to Clean Solution.

13

it doesn’t? i’ll have a look and see if. can fix that part, yes.

14

Logged as bugs://i64868.

15

bugs://i64868 was closed as won’t fix.