Binding libraries without including the jar file.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Binding libraries without including the jar file.

Jared Kells
I needed to use the android-support-v7-appcompat library so I created my own bindings for it and the google play services library as I needed to link against Rev18 of the V4 support library not the one bundled with Xamarin Android.

How do I make my bindings pull the jar file from the installed android sdk directory at compile time like the GooglePlayServices library on the component store?

My binding is significantly larger and includes the jar as an embedded resource. The version on the component store doesn't but still seems to work.

Cheers,
Jared

_______________________________________________
Monodroid mailing list
[hidden email]

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
Reply | Threaded
Open this post in threaded view
|

Re: Binding libraries without including the jar file.

Jonathan Pryor-2
On Oct 1, 2013, at 2:48 AM, Jared Kells <[hidden email]> wrote:
> I needed to use the android-support-v7-appcompat library so I created my own bindings for it and the google play services library as I needed to link against Rev18 of the V4 support library not the one bundled with Xamarin Android.

> My binding is significantly larger and includes the jar as an embedded resource. The version on the component store doesn't but still seems to work.

The version on the component store is a hack. (And I say that having helped design it in the first place...)

Embedding the .jar into the assembly is BY FAR the better way to go, because of versioning.

For example, assume [0] that you have a Google Play Services r10 binding. (_Just_ the binding, not the corresponding .jar!) Further assume that "somehow" the system .jar was updated to Google Play Services r12. Further assume that r12 added a _new_ abstract method on a class also present in the r10 binding, and (finally) assume that you're attempting to subclass that type with the added abstract method.

Boom, you have a javac error at ACW generation time: http://forums.xamarin.com/discussion/6881/mapsandlocationdemo-v3-google-play-services-build-error

This, plainly, sucks.

So why did we do it? Because the Google Play Services license prevents us from embedding the .jar into the binding assembly and shipping the resulting assembly. (At least by our reading of the license.)

We have plans to make this process more resilient, but it's _still_ a hack. Embedding the .jar into the assembly is a FAR better solution if you're able to do so.

> How do I make my bindings pull the jar file from the installed android sdk directory at compile time like the GooglePlayServices library on the component store?

If you _really_ want to do this [1], you would do this via the added-in-4.8.1 (and currently undocumented) Android.IncludeAndroidResourcesFromAttribute and Java.Interop.JavaLibraryReferenceAttribute custom attributes. These are assembly-level attributes:

        [assembly: Android.IncludeAndroidResourcesFrom (@"Path\To\res\directory")]
        [assembly: Java.Interop.JavaLibraryReference (@"Path\To\Library.jar")]

Again, I do not recommend using these attributes. Embedding the .jar and resources into the binding assembly makes for a FAR saner and less painful experience.

 - Jon

[0]: This has in fact already happened.
[1]: Note: you don't want to do this.

_______________________________________________
Monodroid mailing list
[hidden email]

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
Reply | Threaded
Open this post in threaded view
|

Re: Binding libraries without including the jar file.

Jared Kells
I suspected it may have been something to do with licensing. 

Thanks for the information on how it works, I will just embed the jar file as suggested.

Cheers,
Jared


On Wed, Oct 2, 2013 at 1:33 AM, Jonathan Pryor <[hidden email]> wrote:
On Oct 1, 2013, at 2:48 AM, Jared Kells <[hidden email]> wrote:
> I needed to use the android-support-v7-appcompat library so I created my own bindings for it and the google play services library as I needed to link against Rev18 of the V4 support library not the one bundled with Xamarin Android.

> My binding is significantly larger and includes the jar as an embedded resource. The version on the component store doesn't but still seems to work.

The version on the component store is a hack. (And I say that having helped design it in the first place...)

Embedding the .jar into the assembly is BY FAR the better way to go, because of versioning.

For example, assume [0] that you have a Google Play Services r10 binding. (_Just_ the binding, not the corresponding .jar!) Further assume that "somehow" the system .jar was updated to Google Play Services r12. Further assume that r12 added a _new_ abstract method on a class also present in the r10 binding, and (finally) assume that you're attempting to subclass that type with the added abstract method.

Boom, you have a javac error at ACW generation time: http://forums.xamarin.com/discussion/6881/mapsandlocationdemo-v3-google-play-services-build-error

This, plainly, sucks.

So why did we do it? Because the Google Play Services license prevents us from embedding the .jar into the binding assembly and shipping the resulting assembly. (At least by our reading of the license.)

We have plans to make this process more resilient, but it's _still_ a hack. Embedding the .jar into the assembly is a FAR better solution if you're able to do so.

> How do I make my bindings pull the jar file from the installed android sdk directory at compile time like the GooglePlayServices library on the component store?

If you _really_ want to do this [1], you would do this via the added-in-4.8.1 (and currently undocumented) Android.IncludeAndroidResourcesFromAttribute and Java.Interop.JavaLibraryReferenceAttribute custom attributes. These are assembly-level attributes:

        [assembly: Android.IncludeAndroidResourcesFrom (@"Path\To\res\directory")]
        [assembly: Java.Interop.JavaLibraryReference (@"Path\To\Library.jar")]

Again, I do not recommend using these attributes. Embedding the .jar and resources into the binding assembly makes for a FAR saner and less painful experience.

 - Jon

[0]: This has in fact already happened.
[1]: Note: you don't want to do this.

_______________________________________________
Monodroid mailing list
[hidden email]

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid


_______________________________________________
Monodroid mailing list
[hidden email]

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid