I have an android project versioned with SVN. I have three eclipse projects inside my repository. Library project, free version project, paid version project. My current repository structure is:
repository/
branches/
tags/
trunk/
freeversion/
paidversion/
library/
Is there a better structure for this contents?
Thanks!
Are the two versions of the application going to be so different that they require their own views, intents, activities, etc or does the paid version simply add more functionality to the application?
Either way, I would probably share everything except for the views, which is usually all that's going to make a difference to the user once they run the application.
Something like this:
repo/
branches/
tags/
trunk/
src/
lib/
views/
free/
premium/
Upvote for rage faces!
I use the above structure, with a few tweaks to support re-use of library projects:
In each app project, I create an externals dir, with all library projects loaded via relative svn:externals
svn pg svn:externals externals/
../../libSquello libSquello
../../FacebookSDK FacebookSDK
In each project, I modify default.properties, to reference relative paths to libraries
android.library.reference.1=externals/FacebookSDK
android.library.reference.2=externals/libSquello
I like this approach because as my collection of apps grows, I can checkout a single project instead of needing to checkout every app to ensure I've also got the dependencies
The down-side of this approach is that you need to take a little care if you edit the library files inside multiple projects.
Related
I have an old eclipse android workspace which has the following structure:
one library project which has all the code and default graphics and resources
other projects which depend on the library project, but with different package names, different strings.xml and different graphic resources.
Basically what this means is that all my code is in the Library Project, and all other projects are really just different apps, based on the same code, but looking differently with different names
All these were in one Eclipse workspace and now I need to update the project, so upgrading it to Android Studio sounds like the best way to go.
The easy way is to hope that export works for your case. I battled with Eclipse->Studio migration for weeks. I had exactly that situation - one common project and other apps on top of it. Studio will just convert your common project into an Android library module, and other 'app' modules will be converted into Android app modules. Check out this answer: https://stackoverflow.com/a/22797387/2102748
When you're migrated, you should look to move your source files from the ant-style hierarchy to the gradle-style hierarchy. There is a lot of content for that here: http://tools.android.com/tech-docs/new-build-system/user-guide
Android Studio will also ask you to replace .jar libraries it knows about (like appcompat, google-play-services, etc) with gradle dependencies - do it. Life becomes so much easier.
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.
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 recently wanted to adopt submodules from GIT with my Android projects but stumbled into some problems.
Backstory
I have multiple projects but many use the same external library (Android library-project), in order to make the GIT cleaner and make the GIT for each project contain all the needed material I though of using GIT sub-modules for the Android library project. This part works fine I got the library included as a sub-module for the projects.
Issue
But Android uses these library-projects which basically is a regular project which is added to the project and I can only add the same project once in Eclipse. So if I need to work on more than one project at a time I have to use multiple instances of Eclipse/workspace instead of using Eclipse the regular way.
Is there a way to have only 1 instance of my library project in eclipse and at the same time have all the projects reference to their respective libraries? Or any other suggestions how I should handle this?
Any help is very appreciated
You cannot have the library project as a single instance in Eclipse for the following reason.
Each project which uses the library might reference a different version of the library. Since your submodule is a physical checkout (working directory) of a particular version there is no way to represent more then one state of the repository at a certain point in time.
Workaround:
Prepare a "server" location for the library project. It is good enough to create a clone using git clone --bare.
Clone the "server" library project into your workspace.
Prefix the library project to reflect the name of the main project it is used in.
Repeat step 2 and 3 for each main project you need the library to work with.
Everytime you do changes in the library project create a feature branch. In each main project consider if the new feature might be useful or hindering. If it does not fit you obviously need to rewrite the feature you just created. When you are done update the version of the library (don't be shy using tags with Semantic Versioning).
I have an Android code base which uses APIs with settings to get different data for several apps. All apps use the same code base but with one or two design tweaks. So how do I re-use the main code base without having to copy the whole Android project each time?
iPhone uses multiple targets in the same project which works well. If android cant do this do I need to compile binaries of the code base in one project and then import into each new app project? If so how? I'm using Eclipse and am an intermediate Java developer.
Any help much appreciated!
Doug
Check out "Working With Library Projects" from the Android documentation. This should be just what you're looking for: http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
The current way to approach this issue if you are using Android Studio with Gradle is by using Gradle, Build Type + Product Flavor
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
Build Variants
One goal of the new build system is to enable creating different versions of the same application.
There are two main use cases:
Different versions of the same application
For instance, a free/demo version vs the “pro” paid application.
Same application packaged differently for multi-apk in Google Play Store.
This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.
Note: This answer is basically obsolete now that one can create .aar libraries with resources. It still works, though, and there may be times when the portability of a .jar is desirable, so I'm leaving it here.
Blumer's answer is a good one, and you should definitely look into Android's idea of library projects. However, there is another alternative. If you have a module that contains only Java code, but no resources of any kind (images, layouts, etc.), you can compile it to a .jar file separately and use the resulting .jar in multiple application projects. It works like this:
Create a new Java project in Eclipse (not an Android project) and move the source code of your module there.
If your module references any classes from the SDK, you'll need to add the Android SDK .jar to the project's classpath (Project > Properties > Java Build Path > Libraries > Add JAR).
When your module is ready to use, bundle up its .class files into a .jar. You can do this manually, or you can look around to figure out how to get Eclipse to do it for you.
Copy your module .jar file into the "libs" directory of your app's main project.
Add the module .jar to the project's classpath (again, Project > Properties > Java Build Path > Libraries > Add JAR).
Now you should be able to build multiple apps using the same .jar, while maintaining only one copy of the module's source code.
Depending on your particular situation, this may or may not work any better for you than the standard Android library mechanism. But it's worth considering as an alternative.
The Android documentation recommends another approach if there aren't too many "different APIs" used.
The idea is to use reflection instead of making direction references to the code. Make sure to use optimized reflection instead of lookups every time.
References
http://developer.android.com/training/multiple-apks/api.html
http://developer.android.com/google/play/publishing/multiple-apks.html#ApiLevelOptions
You might want to consider using a source control system like Subversion (or GIT). Keep your most feature complete version in the trunk, and make branches for your separate versions that use different data sources or require minor layout changes, etc.