Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Atsushi Eno
    @atsushieno
    As I mentioned earlier, you wouldn't be able to dynamically create Java objects (anything derived from Java.Lang.Object) as they most likely need corresponding Java classes that may be called by Android framework.
    Marek Habersack
    @grendello
    are there any folks around who use Linux distros not derived from Debian or Ubuntu?
    Jonathan Pryor
    @jonpryor
    @grendello: on this channel? :-)
    that might be a question for your Twitter followers
    Marek Habersack
    @grendello
    hopefully on this channel :)
    Jonathan Pryor
    @jonpryor
    that's hilarious
    Marek Habersack
    @grendello
    my Twitter followers are probably all OSX or Windows users :D
    Jonathan Pryor
    @jonpryor
    we barely even work on Linux, and you expect anyone using Linux here?
    ...though we did have someone, impressively enough
    i wonder what distro he was on.
    Marek Habersack
    @grendello
    we had people here contributing to Linux
    Jonathan Pryor
    @jonpryor
    yeah. one?
    not many. :-D
    Marek Habersack
    @grendello
    well, that's 50% of our contributors :)
    Jonathan Pryor
    @jonpryor
    @0xFireball: linker-wise, so long as everything you need is referenced in the .apk, you shouldn't need to worry. Though if you're doing an IDE/toolchain, you might want to just disable linking...
    @0xFireball: so long as you're not extending Java.Lang.Object/Java.Lang.Throwable -- directly or indirectly -- generating and loading IL should be fine, afaik.
    so your IronPython/whatever case doesn't sound entirely implausible
    the linker will be a worry, but disabling it might be a viable solution for your use case.
    (I'm not sure what your use case is, but disabling the linker might be useful ;-)
    Atsushi Eno
    @atsushieno
    xamarin/xamarin-android#127 - you cannot just change v6.0.99 to v7.0 without changing this code.
    0xFireball
    @0xFireball
    @jonpryor Without linking, my APK blows up to 30+ MB because of Xamarin.Android.dll, which is by far the largest assembly in the APK. Instead of that, wouldn't it be better to link only that assembly, especially if dynamic calling of android code is implausible?
    Atsushi Eno
    @atsushieno
    There is LinkSdkOnly mode which is exactly for that purpose
    0xFireball
    @0xFireball
    @atsushieno , yes, i am aware of that, but i want to expose mscorlib and System.Core. Would adding those to the list to skip work?
    Atsushi Eno
    @atsushieno
    If you list them in LinkDescription file yeah they should be skipped (preserved)
    otherwise, they will be linked
    Atsushi Eno
    @atsushieno
    @jonpryor why do you think AndroidApiLevel is configurable? https://github.com/xamarin/xamarin-android/blame/master/Configuration.Override.props.in#L5
    It isn't
    If you set lower API Level, anything that depends on ANDROID_23 will not build
    e.g. MSBuild tasks
    I'm going to have to make changes to it to 24 because otherwise this is impossible. https://bugzilla.xamarin.com/show_bug.cgi?id=39984
    (oops, that was private bug on N attribute support.)
    Atsushi Eno
    @atsushieno
    Hmm, so, at this state this is going to need silly set of PRs: to add new manifest attributes, Java.Interop/src/Xamarin.Android.NamingCustomAttributes/~/{AttributeTypes}.cs will be changed (PR-2). But To make it build-able, xamarin-android needs AndroidApiLevel change from 23 to 24 (PR-1). Then xamarin-android needs additional changes to src/Xamarin.Android.Build.Tasks/Mono.Android/~Attribute.Partial.cs to actually take effect (PR-3). And our product code also needs changes (PR-4+?)
    And at this state I haven't even bothered about <layout> element. It's already too much of the changes (also I have been waiting for too many PRs being merged, cannot really manage more)
    Atsushi Eno
    @atsushieno
    k, they all need to be merged xamarin/java.interop#56 xamarin/xamarin-android#128 xamarin/xamarin-android#127
    Jonathan Pryor
    @jonpryor
    @atsushieno: I'm confused by your mention of $(AndroidApiLevel) and src/Xamarin.Android.Build.Tasks. The latter only uses $(AndroidApiLevel) to find the generated sources from src/Mono.Android; it has no impact on whether e.g. ANDROID_23 is defined within compilation of src/Xamarin.Android.Build.Tasks.
    i'm kinda surprised that src/Xamarin.Android.Build.Tasks doesn't already have a $(DefineConstants) which includes ANDROID_23 and company.
    MakarkinPRO
    @MakarkinPRO
    have a issue
    blob
    Jonathan Pryor
    @jonpryor
    @MakarkinPRO: that's a warning message, not an error
    looks like two different assemblies are binding the same Java types
    which will result in no end of confusion
    MakarkinPRO
    @MakarkinPRO
    blob
    @jonpryor this is error
    any ideas of what can I do
    ?
    HariharanArumugam
    @HariharanArumugam
    how to upload and retrieve image in sqlite database??
    Atsushi Eno
    @atsushieno
    @jonpryor indeed. There should be ANDROID_24.
    @MakarkinPRO remove references to Fabric.Sdk.Platform and anthing that indirectly references it.
    Maybe you are either mixing different versions (where assembly set differs) or referencing that is not supposed to be "installed and/or run on Android target" e.g. "development environment only" assemblies.
    @HariharanArumugam isn't sqllite database just a file? Then you can use "adb push" and "adb pull"