I had a similar problem with wrapping my head around this libraries issue
when I started using Android Studio and Gradle just a few weeks ago (see
discussion here
<https://groups.google.com/forum/?fromgroups&hl=en#!topic/android-developers/O1hSIbQK0SU>,
also for an overview of the available options). You would usually add 3rd
party libraries as module dependecies to your app project (hit F4 and go to
"Dependencies" tab, click the green plus icon and select "Library
dependency"). An online repository is searched for the requested library
(also taking the requested version number into account). As far as I
understand, that library will be downloaded once into your local Maven
cache, which will be used by all your app projects. So in this case there
should be no redundancy.
When it comes to self-developed library modules you can do the same. I get
around this module-inclusion problem by deploying development snapshots of
my own libraries into my local Maven repository and adding them to the
dependencies list of my Android app. No redundancy here. Libraries can be
centrally maintained and developed outside the app project. The same with
3rd party libraries, they also can be added as dependencies from online
repositories. The whole project organization and setup is driven by Gradle
build files. You are free to configure it any way you wish.
I do not quite understand the system property problem and I think there's
also no point in requesting any change. Android updates are super-slow to
roll out and it would take many years until you could rely on that feature.
A library that interfaces with the Android API is also usually compiled
against the Android SDK, so the programmer should be well aware of the
presence of Android. Unless you access the Android API via reflection, but
in this case you can just use reflection to figure out that your code is
running on Android.
On Wednesday, February 11, 2015 at 2:40:22 AM UTC-8, Ristar wrote:
>
> As written in the title, the Android Studio needs a "*create library*"
> function very very very very very badly.
>
> Chucking the source files from everywhere to everywhere else is very bad.
> It is the lazy man's way out, yes. But if one uses his own libraries across
> many projects, it'd be a nightmare. The current method of having different
> libraries inside the same project is very bad.
>
> Libraries should be managed from one project to reduce headaches, double
> work, not knowing which file is where, etc. In other words, 1 lib project
> for all app projects to use will definitely prevent many FUBAR scenarios
> that waste everyone's time and makes everyone angry.
>
> Look at how Netbeans does it. That is the way to go.
>
> One more thing I have noticed, is that os.name returns "Linux", not
> "Android". This is not so good. If it returns "Android", programmers can
> utilise existing libraries for desktop versions of Java and adapt it to
> android quickly. Hell, you can even put "Linux Android" or the other way
> around. As long as there is a way to differentiate between desktop and
> mobile.
>
> For example:
>
> if(System.getProperty("os.name").equals("Android")){
> //android implementation here.
> }
> else{
> //desktop implementation here.
> }
>
> Thanks.
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
---
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
