I would like to create a limited version of my Android app, excluding about a dozen class files from the final APK. Of course, I can just move them to a different folder, or use "Build Path > Exclude". I am wondering if there were a more elegant way of achieving this, via a single flag somewhere in the project. Any ideas?
One of the ways is to use build flavors in the new gradle based build system. It is an elegant solution and recommended by Android developer site . With Build Flavors, you can share common set of files between two versions of the same app, and customize it as needed. For additional details on how to do this please see this SO question.
You can use gradle build with eclipse too, please see this and this.
Related
So I took a Coursera course that had me work with external libraries. Two .jar files which most of the weekly projects depended upon.
I'm not entirely sure how eclipse compiles and runs the files, and how it links to these external libraries -- what is the proper way of organizing this? Do I put a copy of each .jar file in each project directory?
Is there another, cleaner way that I should be organizing this?
Thanks --
As a beginner programmer it is OK to put it in each project. But consider that this is ongoing work and at some time in future you want to upgrade to a new version of these external libraries. Then you would have to copy it everywhere.
Instead another option is to store them in one place and add it in classpath in each project. Now you have only one copy of it, which is always better.
Now, if and when you do get a new version then the file names might change, so you will still have to change the classpath of each project.
But I advise you to worry about these and other such problems later. For now, focus on programming related problems rather than configuration.
If you want to maintain your libraries professionally in a formal manor then you're better of using a build tool like Gradle of Maven.
I'd suggest you to use Gradle to maintain the project since it has a whole lot of useful build tools available to you to use. Eclipse has a Gradle plugin available which allows you to use Gradle projects with it. See link below.
To give you a idea of how Gradle is used professionally. Android uses it by default to maintain their projects now. So Android java projects uses the Gradle build tool to maintain its library sources, compilation processes and such.
The difference between a Gradle project and a normal java project is that a Gradle project has a list of pre-defined scripts available to you which fetches the libraries, compiles them and prepares them before exporting the final bundle (jar). So really all Gradle does in before hand is fetch the libraries and prepares the specified tools before compilation so you won't need to mess with them your self. It prepares your project directory and remotely maintains your libraries so if they're available from a repository then it'll make sure to prepare them appropriately in before hand and setup your projects directories.
So really the difference you'd physically notice is that instead of using the default Eclipse export button to create your bundle (jar) you'd instead use a button from the side menu which the Gradle plugin adds and also you'd cleanly list the libraries in a structured order in a file that gets added to your project root.
If you want to get a basic understanding of how it works and really want to start to proffesionally or formally structure your project then try to create a very basic android app in Android Studio. see link below
If this isn't what you want at all and don't want to take it to this advanced level yet then adding the library bundles into some kind of lib folder that's located in your project root is properly best practice.
If you wonder why? Well basically different projects might use different versions of the library which may add or remove support to them. So to keep the versions consistent and make sure to have the right version available to you, you have the direct source near the project it self.
Here's some useful link:
http://www.vogella.com/tutorials/EclipseGradle/article.html
http://developer.android.com/sdk/index.html
I have to do a very laborious task on a regular basis and am looking for a way to automate the process.
I have to Clone 2 git repos, open in eclipse, add one repo as a dependency of the other,c hange package names, refactor, replace the res folder with another and build.
I want to write a script or something that will automate the whole process. Is this possible? If so where do I start?
Is this possible?
Um, sure.
If so where do I start?
I would start by choosing a programming language and toolchain for doing the work.
A slick solution would be to use Gradle with the Gradle for Android plugin, as it already knows how to do the build. "add one repo as a dependency of the other" can be done right from the build.gradle file. If your objective of "change package names, refactor, replace the res folder with another" is simply to have a different application ID (e.g., to allow it to be uploaded to the Play Store as a distinct app from others), Gradle for Android can do that just via applicationId, without any actual changes to the code itself.
However, you do not have to use Gradle. You are welcome to choose any other programming language, at least one that can run external commands to do the builds.
Try Jenkins its a continuous integration server.It can even pull code from the github repo and produce android builds without having to go through the tedious manual steps
Hope this answers your question
I'm new to Android and wanted to use AspectJ with it.
I had searched couple articles online and follow the instruction to have it working:
http://blog.punegtug.org/2010/11/adding-aspect-to-android.html
But I wanted to know whether if it's possible to separate the aspects away from the Android project. In the tutorial link above, it has both the Android App and the aspects inside the same project, but in many cases, we wanted to leave the Android Project untouched in its isolating spaces.
Let said I have AndroidProject in my Eclipse workspace, I would like to create a separate projects for my aspects called something like "AndroidAspectProject" which only contains the aspects for it.
I'm not sure whether this would work because it seems we need to let AspectJ compiler inject point cuts and advices to the .class files before creating the .dex files. In this sense, I may not able to do it in a separate project.
Does anyone try with this?
Another related question would be:
Is it possible to have Ant build the AndroidProject with AND without aspects on it? Can this be done outside of Eclipse?
I'm looking for a way to build different flavours as I'm only injecting pointcuts into the AndroidProject on dev/debug build, but will leave it untouched on release build.
Whether or not to do the compile-time aspects is a matter of whether or not you run the aspectj ant tasks. Have separate targets or properties for the AOP- and non-AOP-builds and either build one based on a target name or property, or build them both and change the artifact name.
IIRC Eclipse allows you to specify an Ant target to run on a build.
Inside of Eclipse, this is simple. Just add AndroidAspectProject to the aspect path of AndroidProject.
Inside of ant, there are several ways of doing this. But, the simplest is to define 2 targets. One that uses iajc and the other that uses javac to compile your sources. You then need to use a little ant magic switch between targets depending on whether you are compiling for dev or for production.
A team working on a project will tend to need a common configuration of Eclipse. This includes general configuration and project specific configuration. For example, generally, everyone might wish to share indentation, installation of certain plugins (say m2eclipse, testng, egit, Spring support). Further, for a project, you might want specific plug-in configurations (e.g., for m2eclipse, setting up a custom Maven settings file, configuring extra Maven targets for eclipse build events), or a custom Eclipse target platform, or even just to set-up certain custom launchers.
Currently, my team executes a series of manual steps to try and get everything configured correctly. This is tedious, error-prone and difficult for new developers to follow. Instructions also tend to get out-dated.
To what extent can this sort of configuration be automated? How should it be done?
The simplest thing available without modifications is to have a common preferences file (Export->General->Preferences), which everybody can then load. Works the best with the same Java installations present.
It is possible to drop in plugins these days but I have not worked with it. Also it might be beneficial to create a local repository with a default package depending on all the plugins you want. Then you can just install that and it will pull in the references. A local cache might be very beneficial as some repositories are quite slow.
There are several solutions for sharing Eclipse Installation/Configuration and settings. For example, Pulse (has a free version). If you browse previous questions in StackOverflow, you will find many discussions regarding these issues.
I would suggest against copying the configuration and workspace folders. From my experience, it won't always work. Plus, this technique only works once. It doesn't sync later.
Update: I just recalled that there's another useful plugin to checkout: Google Workspace Mechanic.
configure the eclipse at one workstation and then make a zip file or rar file for the same and pass it to others.. that will help and otherwise you can also write cmd scripts to copy the plugins and other useful stuff in to the same and these will be less error prone.
Configure it once and then make copies of the configuration folder. If its not enough, copy the entire Eclipse folder.
i agree with "Thorbjørn Ravn Andersen" but the preferences export doesn't export all preferences, especially from additonal plugins. you should additionally als zip a working eclipse and provide it to all teammembers.
I think different parts have different ways to configure/share.
installation
The installation could be installed in the nfs as central deployment, and maintain by administrator. All team members share the installation(eclipse and other plug-ins).
plug-ins preference
The preferences of some feature could be exported a file, then imported in other environments. But it depends on the implementation of the plug-ins. For example, you can export/import key setting and jre setting.
project's specific settings
For example, the java compiler level and code format setting are stored .pref configuration file under the folder of project. You can manage them via source control tool. So those setting can share among team members.
I'm having a difficult time figuring out how to add a .jar/library to a Netbeans project in such a way that I can get it committed to the repository.
The typical way to add a library (per the Netbeans documents I've already gone through) ends up with it just being local to me. Anyone who checks out my project ends up missing my required library.
Inserting it manually and trying to work around Netbeans results in Netbeans hanging while trying to scan the project...
So, how can I tell Netbeans to pick up a jar as a library and include it in my project in such a way that Subversion will be able to handle it?
There are a couple ways to fix this.
A. When you define your Library, use a path to a common location. A location that's identical on everyone's machine--such as the location of a JAR installed with a third-party app into Program Files or /usr/local/ works well or a network drive.
Then, when they check-out the code, the path will still be correct and they do not have to define the Library on their Netbeans workspace.
B. Edit your project.properties file to use a relative path. Open your project.properties file and look for "libs.LIBRARY_NAME.classpath=...". That will be the "default" location used if the Library is not defined.
Change this to use a path relative to your project and store the jar files in your project. For example:
libs.Log4J.classpath=lib/log4j.jar
Keep in mind that the Library definition in your Library Manager will override this value--so make sure you keep them in-sync (i.e. append a version number to the library name!).
C. Use Vincent's suggestion of using a build-system such as Maven. The Maven build-process will take care of downloading dependencies, etc. Netbeans has plugins for several popular build systems.
There is a new feature in NetBeans 6.5 (variable-based paths in projects) which should make this easier.
See http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-VariableBasedPathsInJ2SEJ2EEProjects for details. Note the screenshot includes variable references in the library customizer.
Not really an answer to your question but... generally you should not include these libraries in your subversion repository. There is usually no need to have them managed. What you might want is to set up a central repository similar to what happens with maven. If you use maven, you can create a local repository of libraries on a server accessible by the team. The dependencies on these libraries are entered in the pom.xml file and this is in the subversion repository. Now, as team members check out the code from subversion they all have access to the maven repository.
[I am looking for a reference to this right now. When I find it I'll edit this answer.]
I use NetBeans IDE 6.5.1 and the best solution I've found so far is to include the needed libraries from your local host and then change their paths to relative. After that you have to remove the libraries manually from the NetBeans file explorer, and then copy them from their OS location in your computer manually to the file explorer again. That way NetBeans detects the change and you can commit it to the repository.
Note: I Highly recommend to clean and build the project again after updating.
An easy way to pack up your lib/jars into your project so that subversion "just handles it" so you can grab it out with all the attached libraries ready to compile and go is to include them all under your project directory via the "shared libraries" option by managing the libraries folder.
When creating a new project you can specify "Use Dedicated Folder for Storing Libraries" and then use the suggested relative .\lib path. If you have an existing project, you can edit it's properties, Libraries Category, and Browse for a Libraries Folder. Again a first-time run will suggest .\lib and then offer to copy existing dependencies to that folder. These graphical actions should provide similar results to James Schek's 'B' answer.
Commit the project with the newly added libs in .\lib and you should be able to checkout and build from anywhere and know you'll have the same libs (at the same version) as you had when you last built and committed.
I don't know how long this feature has been in NetBeans. For more details see:
http://netbeans.org/kb/docs/java/project-setup.html#projects-shared-libraries
I ended up just downloading my own set and putting them on my local drive for this project. I setup my Netbeans to look there and warned the other guys what I did... Eventually, we'll have to do something a bit more scalable though... :-)
OK, the working solution that I've now moved to is to extract the class files out of the jars and dump them into the Source Packages area. Then it all gets committed to the repository and also avoids having to deal with handling a separate "lib" directory in the deployment phase.
This solution does everything I'm looking for, yet I feel real dirty about doing it this way. It just seems horribly broken and wrong... :-)