I'm a beginner in Android programing, and I'm working with android studio...now i wander what is the best way for installing open sources libraries from gitHub.
my question is from organization principles point of view-
should i create a new package for every library and put all the library source code as is in that package? should the package be in the source.main.java folder?? (the one that the android studio creates automaticly).
sorry for the dumb question...it's just that im taking my first baby steps in a big scale program and i don't want to loose my head in the future because of bad organization practices.
There's no right answer to this question. A few wrong ways to do it, but common sense will guide you.
My advice:
Start by having the source of this open source code checked into your company's source control system somewhere and capable of being built or re-built as needed. Not necessarily in your project, but just getting the code checked in so it can't be lost or confused with the original author's ever evolving changes on GitHub.
As to how you consume it, you have several options.
Build the open source in it's own project (checked into source control, but separate from your main project). Then just take the drop of compiled files (.class, .jar, .lib, etc...) and check that into your main project. This is the most flexible option if you don't think you are ever going to need to change the open source code that often. Has the side benefit of being managed for several projects.
Drop the source code as-is directly into your project. This means you will always be rebuilding the code. This gives the most flexibility with evolving and changing the the code specific to your project needs.
There's probably hybrid solutions of these options as well.
The bottom line is that whatever you use needs to be copied and building in your own system. Because the code you pulled down from GitHub could go away or change significantly at any time.
A simple solution would be to use JitPack to import those GitHub projects into your gradle build.
First you need to add the repository:
repositories {
maven { url "https://jitpack.io" }
}
and then all the GitHub repositories as dependencies:
dependencies {
compile 'com.github.RepoOwner:Repo:Version'
// more dependencies...
}
Behind the scenes JitPack will check out the code and compile it.
I think you are looking for this. If you are using eclipse, you should check this
If you are looking for adding jar file to your lib, you can simply create a lib folder in your project and add jar file into the library and you must add the line compile files('jarfile.jar') in the build file(gradle build). If you are using eclipse you can follow this
By the way, creating a package for each library and putting all library source codes doesn't look sane to me. It is almost equivalent to recreating the project. I'm sure that it is not the proper approach.
If the third-party code is packaged as a .jar or a .aar and made available in public-facing maven repository (e.g. maven central), then you should add the library as a dependency in your build.gradle file.
If it is not available as a maven/gradle dependency, you could add the library's code to your project as suggested in other answers here. I have never liked that solution at all.
You could also build the .jar or .aar and add that to your project's lib directory, as also suggested by other answers here. For a small, simple project with few dependencies, that might make sense.
What I like to do for larger, longer-lived projects, is to set up my own Nexus server (a Maven repo server), and put the third-party dependencies there.
Related
I understand this might be an extremely obvious and ridiculous question to ask, but please excuse me as I'm a beginner. I want to integrate this file into my project so I can call its methods:
https://github.com/RomainPiel/Shimmer-android
The question is, what do I do with it? Is it considered a "module", "library" or "file"? Should I manually copy the source files and create new classes in my project, and then call the methods from there? This would be the most straight-forward but in the "how to use" section in that package, it was mentioned "compile 'com.romainpiel.shimmer:library:1.4.0#aar'"
What I tried:
I downloaded the file as a .zip and then File->New->Import Module then navigated to the unzipped file. I believe I'm then supposed to add "compile 'com.romainpiel.shimmer:library:1.4.0#aar'" so I went to the gradle file to try to add it.
There are two: build.gradle (Module:app) and (Project:ProjectName).
I've tried adding to either and\or both and got this error: (Error:9,0) The project 'ProjectName' may be using a version of Gradle that does not contain the method. Did I do something wrong? Is it supposed to be this easy?
I would be extremely grateful to anyone who can point me in the right direction :)
You have three option
Using the GitHub Desktop you can clone the project and open it like a local project. Every change you make will be tracked. You can then commit and push using the GitHub Desktop. It's all UI and simple to use.
https://desktop.github.com
On Android Studio, when you open it, you'll see this, select GitHub and continue by adding your credentials.
You can then commit and push directly from that.
Using the terminal / command line.
If you are new, I recommend the first. It's simple to use and you get a hang of using it as it is the same steps with any project on any IDE you use.
Note: Downloading it as zip and then using it a bad idea because you're making it difficult on yourself because you can't keep track of changes and you'll have to re-upload everything every time. Which defeats the purpose of version control
If that GitHub account is not yours, then you'll have to fork the project, this way you'll have a separate version of the code on you GitHub on which you can modify. If it is yours then you're good.
Typically, you do not want to include external source code manually. This inhibits your build tool's (i.e. Gradle's) ability to manage that source code. It's very easy in Gradle to, say, set the version (like you have done by specifying "1.4.0") and then later remind yourself what version you have by merely looking at your build.gradle file. However, how would you go about doing that with raw source code? Typically developers do NOT put the version number of the source code in the actual source code - that's what they use their version control system (e.g. git) for, usually with tags.
Another aspect of Gradle is downloading and caching (and compiling) the external project for you. So that's nice.
With that said, you typically want to put that "compile..." line in your module's build.gradle file. Not the Project's build.gradle.
A module corresponds to your application (or library) that you are building or using. Some project's have multi-module configurations, where one module acts as a dependency for another (or several others). A Project in gradle is more of a 'meta' configuration that you can apply to all of your modules. The gradle docs recommend you focus on your module's configuration first and adjust the Project's configuration only if you have a specific need and reason to do so.
For the error you mentioned, you might have some unnecessary configurations in your build.gradle file, or the tool version numbers might not reflect what's on your system - if you copied and pasted from the internet, you might want to correct this by letting your IDE generate that file (the brute-force approach would be to create a new project entirely, and use its build.gradle files as a reference). Before you do that, you might want to check if your IDE provides any warnings inside that file.
You have to add the dependency to your module's gradle file.
There are two gradle file present in an android project. One is the project gradle and the second is the module gradle for each individual module.
You just have to copy the given
compile '......' in the dependency block.
So I am starting to work on some open source libraries that is out there, mainly I have found bugs with the library using my specific project. As far as I know the Gradle library dependency is cached somewhere and not accessible.
What I would like to do is be able to create a branch for the fix and test in my project. Is there efficient way of doing this or do I need to comment out my gradle dependency and do a manual import of the library and do the fix?
I think that project is available on GitHub? You have 2 options then:
Open a issue at the project and describe your problems. Maybe the author will fix them himself
Fork the Project. You can work on your own on it then and make a Pull Request later if you want to.
You can of course download the source code and modify it yourself locally too, but that's not the purpose of Open Source Projects I think :)
I would like to open source a library project that I am working on in android studio (hosted on GitHub) and allow others to include the project as a dependency.
Example:
dependencies {
compile 'com.test:myproject:1.0'
}
I've done some research, and have only discovered how to create a module and import it locally within my project. Does anyone know the necessary steps to take to achieve what I want?
Basicly you can publish your app on a public repository like maven or jCenter. The easiest way is to published on bintray, it's free for open source public library. You can use the following library to help you
Also, look into jitpack.io. It is easily the quickest way for getting a JVM projects up and ready especially if you're already using Github. Here's the extra docs for it as well.
I was wondering what the easiest way is to display a simple graph of any sort based on values that I already have. I tried using a library but ended up with more errors than i can count. What is the trick to using libraries and can someone take a second and help walk me through the steps because online all i can find is tutorials that just go: Download this jar. put it in libs and tah dah. But I am not seeming to find such luck.
Is there a way to download it as if it was a compelete project and then just import it? Or do you have to go through and pick out each little thing?
Quoting the project documentation:
Recommended: If you use Gradle/Android Studio you can use the library from Maven Central.
Add that line to your build.grade file into the dependencies block:
compile 'com.jjoe64:graphview:3.1.3'
Download .jar file and copy it into the libs folder of your project.
GraphView-3.1.3.jar
Download or clone the git repository and link your project with the GraphView library project.
jjoe64/GraphView on GitHub
Since you have the question tagged with eclipse, option #2 would seem to be the most likely choice.
Note that the author also provides:
a series of demo projects
JavaDocs for the library
both of which may help you learn how to use it, as an adjunct to the rest of the documentation.
Ok, I realize that Gradle and Android Studio seem to think that all Library Applications are built for one project and one project only, but that is not the case. I have many shared Library Applications with common purposes that are shared throughout the organization. Gradle does not seem to be very accomodating to this desired solution. Can someone offer any insight?
My current Structure at a very rudimentary level is like this:
|--Directory
| |--PROJECT A
| |---Module 1
| |--Project B
| |---Module 2
| |--Project c
| |--Module 3
/////////////////////////////////////////////
My Current dependency structure is like this:
/////////////////////////////////////////////
Project A: (FYI, Builds Just Fine)
Project A's settings.gradle
include ':Module 1', ':Module 2'
project(':Module 2').projectDir = new File('../Project B/Module 2')
Module 1's build.gradle
dependencies {
compile project(':Module 2')
}
Project C: (FYI, BROKEN)
Project C's settings.gradle
include ':Module 3', ':Module 1'
project(':Module 1').projectDir = new File('../Project A/Module 1')
Module 3's build.gradle
dependencies {
compile project(':Module 1')
}
Breaks: Cannot resolve Module 2 inside of Module 1's build.gradle file.
This is because the directory structure for Module 2 is established inside Project A's settings.gradle so Project B has no idea where to render this from.
I understand that I can add
project(':Module 2').projectDir = new File('../Project B/Module 2')
to Project C and everything will work just fine. However Project C doesn't use or know about Module 2. I want other developers to have the freedom to use my common shared library project without having to dig in and see what library projects I used and include those in their settings as well. How can I specify my own dependency directory structure in the build.gradle instead of the settings.gradle to make it accessible to all that use it?
On a second note, but similar topic. I'm having the exact same issue with JAR files. If i specify a REPO in a Library Project's build.gradle like: myRepo1 and have a myJar1. Then when that library project is used in a parent project that doesn't define the repo that contains the jar in the library projects dependeny section, it fails to resolve the jar file from the library project when compile project(':libproject') is used. I have to duplicate the repo pointers in the parent's build.gradle file as well so that the libproject will build from the parent app. Any help on this one would be appreciated as well. As not every repo is used in every app so this can become redundant.
Ok this is a really old post, but still gets traction so let me update 3 years later since I originally wrote it lol.
Shout out to CommonWare who had the right best practice idea right from the start, but didn't provide an answer to mark up.
Let me start by saying that using project references like I was doing above should be limited to development stages only and should only be if the library project is also in development stage at the same time as the main project. Otherwise a dependency management server like Nexus, Apache Archiva, or S3 with Maven directory structure or equivalent would be preferred. I have learned many ways to manage dependencies since this, including transitive dependency management.
My preferred method is to deploy artifacts with POM files to Apache Archiva and then use these dependencies within the parent project instead of using relative paths to reference code projects now. This is the first choice.
However, if you are too new to dependency management and choose not to have a server for this purpose, you may package your AAR files or JAR files and put them in one centralized repo like artifact_repo and have everyone include that repo at the same folder structure and reference them relatively, but this is not good practice so I would steer clear if you can.
You can also take the artifacts and nest them in you libs directory and bring them in that way if you would like, but it becomes more of a manual update process which some people like and others do not.
Now this opens a whole different set of issues that you need to handle.
Transitive Dependencies and Child Repo pointers.
For example, if you wrapped your own Crash Reporting Library around Fabric or Hockey or other hoping to make it easy to trade libraries later, then you have found that the repo pointer has to live in the parent build.gradle files or the transitive dependencies are not found.
You could of course use one of those hacky Fat_AAR or Fat_JAR scripts that works "sometimes" until updated gradle then they break again until someone hacks it back together, but this is also poor practice as you are creating potential mismatch dependencies on support or other important child libraries and the "exclude transitives" only works if you are using pom files to control the transitives and not making the AAR or JAR file fat. So you are limiting your ability to control the dependencies.
So what i have finally come to terms with is that transitive dependencies should be managed through POM files to allow excluding or including without nesting into children libraries. Also libraries that require repo pointers inside of them, should probably not exist as they require parent boiler plate, introduce room for human error and typically don't save much time on wrapping analytics or crash libraries for example or you start getting into json configs that need to live in parent files for PUSH or other reasons. Just avoid it.
So long story short lol. Stick to dependency management tools they way they were intended to be used and you will be fine. It is when you are new to it or start getting hacky that you run into ugly code and ugly problems. Hope this encourages someone to do it the right way :)
One last thing :). I have recently started writing Gradle Plugins to manage my versions and dependencies as a separate file so that I can use intellisense to pull in dependencies and make sure all support, gms, and tool versions are the same across all projects. You can even copy down live templates with your plugin to enable intellisense for Gradle to work with your stuff. It's not too bad to do. Best of luck and happy Gradling :).