I am writing an android library project and trying to test it. I found testing a library project
more difficult than it has to be using my current method.
Right now, I am exporting the library project into jar file. Then I put it into the libs folder of the test project and the test target project. Then I add it to build path of both projects and run the test.
Every time I make a change to the library I have to do this again. Is there easier way to do this?
There is some reference to this in the google docs. Check out http://developer.android.com/tools/projects/index.html#testing
Basically, the easiest way is to write an application that uses the library project and then add unittests to that application.
When creating the tests via eclipse, you can choose to test modules from within your library project. This way, changes to the library project are automatically applied.
Related
I have started working on a project where I will need to share a bunch of Java classes across a bunch of apps. In Eclipse it was possible to create one project with all such classes and use it as a library in a workspace with all your dependent projects, but in Android Studio it doesn't seem possible to do so (At least not easily).
I have been reading a bunch of posts and a lot of them suggest setting up a library project, generating an aar file and then using that in my projects. But, as I understand it, this will make my library open-source (Am I right?), which I don't want. I am doing this for a client and I want the code base to be private.
Also, I know that a module can be imported into a new project. But this creates a COPY of the original module. This is not what I want at all. I don't wanna maintain multiple copies of the same classes, which completely defeats the purpose of 'code sharing'.
Is there any good way of achieving what I am looking for? Any help is appreciated.
You have a couple different options.
One option is to maintain your libraries as separate projects and compile them to an archive format, such as JAR or AAR; JAR files are for pure Java libraries, and AAR is for Android libraries (which contain code that accesses Android APIs and/or has Android resources). As was pointed out in the comments, AAR doesn't force you to publish your code to the world any more than JAR files would; it's just an archive file format whose files can be local to your machine or your organization.
With that archive file in hand, you can include it in other projects. If you're part of a multi-developer organization, you may find it convenient to use a repository manager to publish and maintain those libraries within your organization, and you can use Maven coordinate-style specs to include libraries in your projects, which you don't have to manually copy over to your development machine.
The disadvantage of this approach is that it makes it a little harder to make changes to those libraries: you need to load up the project, make changes, build an archive, and distribute the archive.
The other approach is to keep the library as a source module like you did in Eclipse. You observed that Android Studio will make a copy of the module if you import it via UI, but if you bypass the UI and modify the build scripts directly, you can do what you want, which is to use the module in-place and share a single copy among multiple projects. To do this, work in your settings.gradle file and add this:
include ':module_name'
project(':module_name').projectDir = new File(settingsDir, '../relative/path/to/module')
I would strongly encourage you to not use a pure relative path here; in this example, the path is anchored to the settingsDir variable supplied by Gradle, which is defined to be the directory where settings.gradle is found. If you use a pure relative path (i.e isn't anchored to anything), you're dependent on the working directory being the same in all environments where the build file is run (command line vs. Android Studio vs. CI server), which isn't a good thing to assume.
You need to think in the eclipse projects as Android Studio/IntelliJ Idea modules. Then, you can generate android (or java) libraries and then include them in your project.
To mark an Android Studio module as a library you can go to File -> Project Structure -> Facets and there click on Library Module
I was in same situation as you, and i founded an approach using git.
Steps to do, to have library:
Create project in Android Studio.
Create android library module in that project.
In that library module create git repository.
Add modulename.iml in .gitignore file
Use GitHub or Bitbucket for private cloud repository. and push your library to it.
Create new android library model in any project that you want.
Close Android Studio (not sure is that mandatory).
Using explorer go to your created module folder.
Remove all data in it, except modulename.iml.
Clone your library from "GitHub" into it.
That's all.
Now you are able to use library in multiple project whether you are at home or at work. Just after finishing you work not forget to push library changes. And after opening new one pull them.
I think you can automate this thing somehow.
The benefit is that you don't need to build any jar, or aar.
You can certainly create and use a library without making it open source or available to others.
First, you don't need to make it an aar unless it contains Resources.
If it's just plain classes, you can just make it a .jar file.
Either way, the easiest way to share these libraries (either aar or jar) is to set up your own repository. Nexus and Artifactory are the two most common repository managers.
You keep the library in its own project, and then publish it to your own, in-house repository.
Then, projects that need to use the library are configured (in gradle) to use the in-house repository, and get the library from it.
So I recently migrated to Android Studio from Eclipse. For the most part, it's better, but I haven't found a good way to maintain a shared codebase between multiple projects.
What I want to do is be able to share some code between several of my applications. Each application is in its own project. From what I've seen, most people add it as a library module in the application's project. The problem with that is the module is accessible from only one project. The other projects within which my other applications reside can't access the library.
It seems to me like there should be a mechanism for creating another library project and then allow each of the application projects to access that code. This worked in Eclipse, where I would create another project in my workspace, mark it as a library, and then have the other projects reference it. I would be able to change the code in the library and then all of the projects referencing it would automatically build with the updated code.
Is this something I could do in Android Studio?
Yes this is possible:
Create the project you would like to have as a shared library - we'll refer to it as sharedProject.
Now in the project that you want to use this library open settings.gradle and paste the following:
include '..:sharedProject:app'
Open your build.gradle and paste the following under the dependencies element:
compile project(':..:sharedProject:app')
You can use this technique for as many projects as you'd like to refer to your common codebase in sharedProject. Note that this assumes your project and your sharedProject directories are in a common workspace directory (which is almost always the case).
I am working on a Android app in which I would like to add plug and play module functionality ,Say I have Two android project
[A] An app for capturing a image using camera and storing it in memory
[B]Enabling map and locate current location .
now I want to add add this functionality in my Another Android app.While going through android developer link and Android Library Projects - Tutorial I figure out that to use plug and play module I have to make my above project as library project so that I can use it in my new app ,now my questions are
1 Is this only way to use library project to add plug and play module
functionally in my app or there are another way also?
2 what are the pros and cons of using library project in order to add
plug and play module functionally?
basically I am researching on how to add plug and play service in my android app and trying to find best solution ,so any clarity on this topic will be extremaly helpful !!!
thanks in advance !!!
An alternative would be to use a linked source folder. In Eclipse, you can set this up in the project settings in the Java Build Path section. You can choose some source code directory outside your project that will virtually be in your project's space (and other projects that use it will do the same). I find this to be handy just from an IDE UI standpoint when I'm co-developing a module along with an app or two. What I don't like about library projects is that they sometimes don't update correctly within your project so you have to rebuild it and your project or clean your project to continue. Also, the module is simpler because it's just a directory of source code files, not an entire Eclipse project.
One other downside of libraries is that they can introduce conflicts that can be a headache to fight. For example, your library might have a different version of the Android compatibility library in it than your main project, and therefore give you compile time errors. Or there are sometimes errors with duplicate libraries, and you have to go fool with the Order and Export settings of your project.
If your module is going to rely on String, layout, and image resources, etc. that are common to all apps that implement the module, then a library project will be easier to work with so you don't have to pass all your resources in through your module's class constructors and duplicate them in each project.
A third option is Gradle, although as far as I know, that would essentially just help automate one of the above two options. I'm not very familiar with Gradle.
I am building series of android projects with almost the same classes, only some sources like images are different.
I want to make it like a source or library, so that I can create projects by only referring to that source/library, inherit the class, and put in images.
For example, I create a project call "Prototype", which is the template. Then I build new projects, adding "Prototype" in Build Path -> projects. Then I extend the classes in "Prototype", it compiles. But when I run it, it says "Could not find Prototype.apk!"
Am I doing correctly? Or I need the Prototype.apk? If so, where should I put it?
Are you using Eclipse as the IDE for your Android projects? If so, you can create library projects as described in: http://developer.android.com/tools/projects/projects-eclipse.html
You can then use a library project as your Prototype.
According to this SDK guide, unit-testing a Library project can be achieved by creating a standard application project, reference the Library project and then instrument the application for unit testing.
However, when I do this and launch the test application I get the message
No tests found with test runner 'JUnit 3'.
I'm using Eclipse and the Android ADT plugin, all latest versions.
Note: the projects compile just fine. The test project also installs fine to the emulator. But in the console I can see that it looks for <library>.apk, which of course doesn't exist since I'm compiling this as a library into the test project.
Anyone got this to work? And if so, what is the trickery here?
Update: after discovering and fixing a problem, which was actually including the test classes (!), the test runner now can find all tests. But, all the tests fail with the following exceptions:
java.lang.NoClassDefFoundError: <nameOfClassInLibraryProject>
nameOfClassInLibraryProject are classes defined in the library project. These classes should be compiled into the test project, and indeed, everything compiles just fine. But when running the test project, the runtime doesn't seem to find the library classes.
After much fiddling and wasted time in Eclipse I have managed to get Android Library projects to work.
According to the Working with Library Projects article:
Instead, you must compile the library indirectly, by referencing the library from a dependent application's build path, then building that application.
The problem was that I interpreted this to mean that the library project should be added to the Projects tab in Java Build Path. Doing this makes the test project compile since the library code is obviously available to the compiler. But since the library is not compiled into a .jar or .apk in itself, the library classes are never deployed to the device.
The solution is to not add the library project to Projects, rather on the Source tab, add the library /src folder using the Link Source... button. And yes, it is the library src folder, not the library project root, that must be linked into the test project.