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.
Related
I want to use the same build.gradle files (project level and application level) for multiple projects. Right now I am accomplishing this by copying and pasting those files from an older project to a newer one. However, I would like to know an easier and less tedious way of going about this, such as perhaps importing gradle files from a certain directory and replacing the default versions.
You have two good options here. You can read about all the options in Gradle's docs.
But it boils down to two options, the first is easier but less safe. You can do what #Subby recommended and put them into a repo where you do something like "apply from 'http://raw.github.come/bla/bla/bla'" which will work, but as soon as you loose internet connectivity you will no longer be able to build. This also makes it hard if someone updates your build may just break.
The second is to publish binary artifacts for your org/company where people can use dependency resolution and Gradle's cache to save the artifact locally so you can build offline. This is called binary plugins. You can read about it in the docs, or I have a blog post that works through how to do this with something you can work along with here.
If you open the project file you will find a file called build.gradle you can transfer this file to other projects like any other file in your project, and also you can upload it to any drive service like google drive or Dropbox so other developers can use it.
I am new in Gradle.
I've been made android library and I will upload this into maven repository.
But is it possible to add "Readme.txt" into my library?
for example,
When someone add my library into dependencies section in build.gradle and sync.
then Gradle creates(or copy) "Readme.txt" into target project(probably $projectDir or $projectDir/app) and user can read it(Like NuGet)
(Important things of this library, how to use example or something like that.)
I think it is really annoying visit project web-site and read "How to use" every using single library.
I want my library contains how to use text file.
Thank you.
I don't think this is possible, you don't know how the calling use is referencing your project. They are likely only referencing the compiled source code and never running your gradle file.
This is not a good idea, you don't know their exact folder structure, and even if you did you can not be sure that your readme.txt would have a unique name that did not conflict with their project file.s
When using a .jar file you cannot include this as resources cannot be compiled into it. But you can export your library as an *.aar file which can contain resource files. You get this by using "com.android.library" as your plugin type and can then find the aar-file in your build folder after you have built it.
This can then be included in your other project e.g. as a file reference.
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.
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 :).
I have seen this question, and have some more doubts regarding creating a jar file which I can distribute and can be used in any android applications.
What my requirement is
As I said, I want to build and distribute a closed source library. I
don't want the source code to be visible.
In that library I don't want to use any assets, layouts, resources
etc. But I want to use some android specific codes, like getting
android device id.
The most popular answer in the above linked SO question tells to create a regular java project and import android.jar in it. I tried to do that, but I don't know how to add android.jar to any java project. I would like to get some clarification on that too.
Moreover I would like to know if there are any other methods using android sdk itself (without using java project) create a closed source library jar file.
I think what I want is possible, since google analytics for android native apps seems to have done it. I am sure in the .jar file they distribute they are using android specific codes, since there seems no other way for them to get the device information to display in the analytics viewer.
EDIT : CAN SOMEONE CLARIFY THIS??
I think I have made some progress. This is what I have done
Created a regular android project (not library project, the "is
Library" checkmark is unchecked)
In the project I have coded out my logic. It uses some android
specific classes like SharedPreference, UUID, PackageManager. But
nothing related with assets, layouts also no class extending
Activity. Just a java class extending java.lang.object
Exported the project using Project->rightclick->export->Java->JAR
file. In the next screen I unchecked the checkbox near
AndroidManifest.xml. Set a destination directory to export and
clicked next thrice with keeping the default settings. Then I clicked
Finish, and got a lovely libMyLibraryName.jar at my desktop.
Then I created another android project, added this libMyLibraryName.jar to new project using project->rightclick->properties->java build path -> libraries->add external jar.
And I tried to use my class in the library, in my new project
MyLibraryClass objClass = new MyLibraryClass(this);
And I was able to compile and run successfully. I even sent the library to one of my co worker who was able to use the library in his on machine (Just making sure library project in my workspace wont influence the project using it).
Now I have 2 questions.
1) My first question is , what they meant by the term "true library" in the below given documentation ? Is it any non android java project which can be exported to a JAR file?
However, a library project differs from an standard Android
application project in that you cannot compile it directly to its own
.apk and run it on an Android device. Similarly, you cannot export
the library project to a self-contained JAR file, as you would do
for a true library. Instead, you must compile the library indirectly,
by referencing the library in the dependent application and building
that application.
Well this portion is taken from documentation under title "Library Projects".
2) My second question is, anything wrong with the way I have created the JAR file? Any possible pitfalls which might bite me back later? I would like to make sure I am not doing something terribly wrong, before using it in my important projects.
I might add that I didn't try the method of creating a JAVA project and importing android.jar. I am ready to try that one, if what I have done currently is wrong.
The android.jar will be located where you installed your Android SDK. Under the platforms directory there should be a number of other directories named android-<version>. The android.jar will be there. Choose the one specific to the minimum android version you are targeting.
Once you have that, copy it into your project. If you're using eclipse I think you can just cut and paste jars straight into your project, right click and add it to build path. If you're not using eclipse or any other IDE, you just need to ensure that the android.jar is on the classpath when building your jar file.
After that your newly built android library can be dropped into any Android project.
In answer to your additional questions:
What they mean by a true library is a jar file as opposed to an Android library project.
I don't think there's anything wrong with the way you created the jar file. I would have made it using the android.jar as I mentioned above but your way should also work. To verify this I would examine the jar contents and make sure all you have in there is .class files.