Some of my apps use publicly available libraries. I feel comfortable downloading such libraries as jar files, given that the code of a jar stored locally is "safe" with me.
Sometimes, however, the library is only available to be added as a dependency in the module's build.gradle, as below:
implementation 'com.darth.vader.lib.filechooser:filechooser:1.1.0'
This worries me because I have zero control over that code, and no clue if/when it changes.
Can somebody enlighten me on the pros & cons of the 2 approaches? And, on how I can "save" such "dependency" code?
Depending on where the filechooser:1.1.0 comes from, you do know when it changes (never).
Once the version is published in an immutable repository like maven-central or jcenter you can expect the version to remain immutable.
I've been working on an Android app project. I'm using quite a few libraries (because why redo work that someone else has done to make other people's life easier?).
My question is: what are the costs of importing libraries in a project? (I'm talking about the implementation XXX.YYY:v2.0.0 type of line added in the build.gradle dependencies list.)
Just as an example (though please provide a more encompassing answer): when compiling and publishing my application, does it take all of the libraries' classes and methods and put them in my application, thus making it much heavier than it would need to be?
Each library dependency requires an additional download while you compile your app. So these will increase the amount of time required to compile.
The code for each library is included in your final APK so they will increase the size.
For Every Library a download is necessary In order to built your app.
e.g If you want Libraries regarding to Firebase then You download the Library by adding the Firebase Project to your App. In build.gradle File you see the dependencies after you add them to Your Project App.
I have an Android Studio project in which I build an SDK and export it to Jcenter so that clients will be able to use my SDK in their own project by adding 1 line of "compile.. " to their build.gradle.
So far everything went well but I do have one problem, my clients can see all of the SDK code from their project. I'm trying to understand what will be the best way to hide my implementation without breaking anything. Obviously proguard will probably be involved in the solution, however to my surprise I haven't seen any "best practice" solution to achieve what I want.
Any thoughts?
At first, a library on the public jCenter repository provided by Bintray is OSS (Open Source Sofware).
This is what I've done to protect my code :
1. All the code is obfuscated with Proguard. There are some rules on very specific classes so the library work correctly.
2. My organization have subscribed to the Professional plan on Bintray witch allow us to not have a OSS library. See pricing. Doing this, the developer will need to add your bintray repo and after the dependencies. If you prefer, I guess you could do as Fabric/Twitter to have your own code repositories using maven, and host your library yourself.
Don't forget that a class file can always be Decompiled so you cannot really prevent this.
As a personnal note, If your planning to earn money with your library, maybe think about an OSS library and a prenium server side service like Parse.com where the client library is OSS.
I want to organize all my java, C and Android projects with Git.
I have several folders:
something_like_gdlib
example_library1
example_library2
...
example_project1
example_project2
...
In each of those projects I use some of those libraries. But if I update a library, I want all projects to get the changes for that library.
Usually I work alone on those projects and I just want to have a change history.
Now I want to work together with another programmer, that should get access to only one project and the corresponding libraries.
How should I set up git? I heard of subtrees or submodules? Or is there a better solution?
Submodules or subtrees could indeed be a solution.
On the other hand you could keep the repos totally independent from a git point of view, and publish your libraries.
Eg: Assuming you're working with Maven in Java, when you want to upgrade example_library1 in example_project1 you could:
Build a new version of the library (and tag the corresponding commit)
Put this binary either in a local or shared maven repository
Update the version of the library in the pom.xml of your project
An advantage of this approach would be that there are no need to do anything complicated with Git
Drawbacks would be:
It may be cumbersome if you want to upgrade in your application every time you commit in your library
If you don't already have a "package architecture", you may need to set it up first
I'm evaluating whether to use Ant or Maven to automate my build process for Android development. I've been trying to read online to make an informed decision, but haven't found many specifics that relate to Android development. Based on your experience:
What are the main differences ?
I've read some people saying they have different purposes ? What would those be ?
What would make you pick one over the other ?
What are the strong points and weaknesses of each ?
Which is easier to setup and maintain ?
Is there one that is proffered/most used in the community ?
I found a similar question What benefits does Maven give (over ant) for building android projects?, but he was asking about the
benefits of Maven over Ant and, first, I don't even know the Ant benefits and, second, he just got one answer that didn't make things clear for me.
I use Intellij, just in case it makes any difference though I hope it doesn't.
If you can use Maven, go with Maven. And, don't you dare try to change the standard directories! Heck, even when we use Ant, I insist we setup the directories like Maven. That way, new developers know where things are, or have to trace through the build.xml to find where things are located. The other things is that if you do use Ant, you should also use Ivy. That way, you get the Maven dependency handling within Ant.
The big irony is that once we use Ant and Ivy, and stick to the standard Maven directory structure, moving from Ant to Maven is a cinch. But, the need to move to Maven is lessened too. Our build.xml is clean and simple to understand. All the files are in the right place. Builds are quick, simple, and easy to maintain. Who needs Maven?
The problem is once we've reach this state of Nirvana, is to keep the project from heading back to the State of New Jersey. Developers start carving out exceptions in our build.xml. Don't compile this *.java file. Move this *.xml into our java directory, put test code under the main directory, but we'll put the name test in the file, so we know it's test code... New and complex things are done. And, somehow, we're back in Secaucus.
So, once I've got my Ant project clean and neat enough to move to Maven, I make the leap.
One more thing: Maven makes it very, very simple to copy a project from one computer to another. Maven handles all the dependencies stuff -- even the build stuff. No more, you need AntContrib, or you need to download the hibernate Ant tasks. If you need something, it'll download itself. It's one of the big reasons Maven is so popular with many open source sites.
My big complaint about Maven is that it's so poorly documented. There's a Wiki, but almost no content, and very few manuals.
I've not used Ant or Maven much for Java recently, but I can tell you the main differences between them -- it basically boils down to automated conventions (Maven) vs. absolute flexibility (Ant).
Maven will do almost everything for you, but it's much easier to use if you arrange your projects to suit it. It'll handle dependency tracking and resolution, building, packaging and storing the built packages, while also helping with branch maintenance and release engineering. I find it an awful lot easier to release my (flex) projects that are built with Maven.
Ant is much more flexible. You can do whatever you want, build in whichever way you want. If you have pre-existing projects, you can automate much of what your IDE is doing without changing anything else. It doesn't hand-hold as much as Maven, which also makes it easier to diagnose when things go wrong... You're on your own for dependencies, branches and releases, though. Where we use ant, we use it because we had a project set up which we wanted to automate, and Maven wouldn't adapt to fit it. If you need to do something not supported by Maven, Ant may be your only hope.
Personally, I'd use Maven over Ant if possible, but I'd admit that it's not always possible.
Consider using Gradle!
It combines the best from Maven (convention over configuration) with the best from Ant (the flexibility and the huge library of pre-made tasks).
A Gradle build is written in Groovy, so you have the full power of a scripting language at your fingertips!
There is an Android plugin for Gradle. I haven't used it though, so I cannot tell if it's good or not.
See http://www.gradle.org
I agree with Andrew's answer in its entirety. However, I would note that the maven support is not supplied by the android SDK team. It's provided by a third party. Now, they are an active participant, but it still means that there may be a delay in getting support for the very latest features.
That said, I don't particularly like the ant support provided by the android SDK team. If you run android create project you'll end up with a build.xml that recommends you copy paste chunks of XML in order to customise it. This makes it burdensome to move to a new version of the Android SDK.
Overall, I suspect that moving to maven will be easier to maintain over the long run.