Once upon a time, I avoided Eclipse for Android development. And life was good.
Along the way, I adopted a convention originally supported by the Android command-line build tools, of having a tests/ subdirectory containing the test code (e.g., MyProject/ being the home of the app, MyProject/tests/ being the home of the test suite). Android does an excellent job of allowing test code to reside in a separate-but-related project, and having it as a subdirectory kept the tests logically co-located with the project proper.
I am now switching to Eclipse, as I need to support it better for my subscribers. The only way for me to do a quality job of supporting it is to use it daily. And, since I have a quad-core with 4GB of RAM, Eclipse actually starts up in less than a minute. :-)
However, preliminary research suggests that Eclipse does not support sub-projects (i.e., one Eclipse project having another Eclipse project in a subdirectory).
So, my questions are:
Am I correct in this assessment, and if I'm wrong, are there any particular steps I should take to ensure that Eclipse is happy? I find that Eclipse can sometimes get a wee bit cranky...
How are Android developers organizing test projects relative to the project being tested? Peer directories (e.g., MyProject/ for the app, MyProjectTests/ for the tests)? Peer subdirectories under some targeted common top (e.g., MyProject/app/ for the Android app, MyProject/tests/ for the test suite?)? Something else?
BTW, I'm running Eclipse 3.5.2, if that matters.
Thanks!
I've been creating test projects with Eclipse 3.6.2 inside my main project just like you describe for command line tools (MyProject and MyProject/test are Android projects that both contain a src folder). You can create this test project using the New Android Test Project by deselecting "Default Location" and setting the path.
None of my projects are very large, but the only problem I've had so far is that you cannot use the MyProject/test folder under the MyProject project. To be able to right click and run as a test case, you have to access files directly from the MyProjectTest project. To prevent you from having problems, you can add a Resource Filter to hide the test folder in Project Properties > Resource > Resource Filters.
However, preliminary research suggests that Eclipse does not support sub-projects (i.e., one Eclipse project having another Eclipse project in a subdirectory).
What problems have you seen?
Depends on your toolset:
ADT >= v12 currently has flaky support for "a project within a project":
Creating an Android Test project in Eclipse
I have tried separate testproject, and separate test directory, but afaik "a project within a project" approach seems to be the way of the future.
This is becuase AndroidManifest.xml merging into the test project AndroidManifest.xml, is in the pipeline for the next ADT releases.
Related
For some reason I can't find a clear cut answer to this. I am currently using Eclipse for my Android projects and as you can see from the screenshot my workspace has multiple APK projects, hundreds to be exact.
The reason for doing this is because it is easy to copy and reuse projects within the same workspace very quickly.
My question is, can this setup be done in Android Studio? I can't tell if it's one APK per Android Studio, or you can work with multiple in the same instance sharing dependencies like Eclipse did.
I am currently using Eclipse for my Android projects and as you can see from the screenshot my workspace has multiple APK projects, hundreds to be exact.
Been there, done that, found it to be unusable, except by keeping most of the projects closed, as it appears that you are doing based on your screenshot.
The reason for doing this is because it is easy to copy and reuse projects within the same workspace very quickly.
In Android Studio, you copy and reuse projects by coping the directory, using your development OS' file manager, the command line, or your favorite other file-management tool.
can this setup be done in Android Studio?
Not really. Android Studio supports a project having multiple modules, where those modules can be apps or libraries. There is certainly nothing stopping you from attempting to create a single Android Studio project consisting of hundreds of modules. However, they would all be the equivalent of open projects in Eclipse (actionbarsherlock and com.exposure.0 in your screenshot). I would expect Android Studio's performance to be worse than Eclipse's with hundreds of open projects, assuming that Android Studio did not flat-out crash due to running out of memory.
I was able to do it just fine without any issues. I was able to set two projects as Android projects in the settings.gradle file and just choose which one I want to launch. Hopefully over 300 of these doesn't start a performance issue. If it does I will just need to remove the modules and add the correct ones when exporting a new APK.
settings.gradle
include ':comexposure0', ':comexposure5', 'exposurelibrary'
I am working on a Java application that will run on an embedded system - a custom android build or modified AOSP. It is built on a linux server.
I would love to use an IDE like Eclipse with all its goodies like code completion, source code checking etc. but it seems very complicated. I looked at Puri's blog here
for one, the build process of our custom android uses Android.mk makefiles.
How can I (Should I?) modify the Eclipse build process to build the custom android build?
You can use either eclipse or studio to maintain a custom, pre-installed application.
In either case, you will not use the IDE to build the actual application image. That will be built as part of the make from the root of the AOSP install(1)
You can, however, create a project whose root is the directory in either /device or /package that contains your app.
Once you've done that, read the Android.mk file to find dependencies. Add them to the project as you would for any other project, for your chosen IDE.
If you go for eclipse, I suggest that you put the build directory somewhere in /out, or outside the AOSP directory altogether. If the root make file finds it, it can be a problem.
When you need to test your app on a device or an emulator, use mm to build only your app.
Better yet, if possible, do most of the development for your app as you would any stand-alone app, so that you can easily install and test it. Only put it in the AOSP directory as part of the release process.
Note, you can use either eclipse or studio to kick off that system
build. In eclipse, use External Tools. Studio provides similar
capabilities
Working under Linux Ubuntu I have made a script which automates the creation and build of new "Hello World" android projects in the workspace of Eclipse and/or Intellij Idea .
The script also inserts my own icons into the different res/drawable directories and adjusts the AndroidManifest.xml to reflect this .
Alas none of these 2 ides recognizes the new project , I still have to import the project (which is already in the workspace ) via "import project " working through a multitude of screens ?
( I'm new to Android and Ides , used to make C-programs all via command-line tools .)
Has anyone a suggestion ?
T.I.A
I can answer your question specifically for IntelliJ IDEA and generally for other IDEs such as Eclipse and NetBeans.
The IDE needs configuration information beyond what's in the project's source code. It needs to know what JDK version to use, where the JDK is, what Android SDK to use, where it is, etc. In the case of IntelliJ IDEA, this is all stored in the either 1) the .idea directory (and its content) and an *.iml file for each module or 2) an *.ipr and *.iws file and an *.iml file for each module. Eclipse and NetBeans likewise use several configuration files. These files are very IDE specific (although IntelliJ IDEA can use and maintain eclipse configuration files.) The specifics of these files frequently change between versions. So even if you spent the hours (or more likely days or weeks) it would take to modify your script to create these configuration files, it would be one more thing to maintain.
My suggestion would be that instead of using your script, use the maven-android-plugin. It has several Archetypes available which can auto generate android projects. You can write your own Archetype that would include your files/icons and manifest modifications. You can run the Archetype from the command line (via mvn) or in IDEA, you can Select File > New Project > Maven Module and then select your Archetype. This would create your project and import it into the IDE in a single step. Plus using maven to manage your projects will make development much easier. Of course, there is an initial learning curve to learning maven, but it is so worth it.
I use two computer for coding. My desktop pc and the notebook. I sync the two computers with dropbox. How can I import/load a project on each of this two computers? The project base folder is different on each computer. When I try to load/import a project which is created on the other computer it loads the project but I got a error with a wrong path.
"Gradle "Test2Project" project refresh failed:
Could not fetch model of type "IdeaProject" using Gradle distribution "http://services.gradle.org/distributions/gradle-1.6.zip".
Project directory "C:\Users\thomas\AndroidStudioProjects\Test2Project" does not exist."
The wrong pfad is the right pfad on the other computer. How can I import Android Studio projects so that it works even on another computer with a different folder structure?
Like the others i agree, that using a VCS would be the best solution. Even though you can try to filter all android studio related files (like *.iml, .idea folder and local.properties). I don't know if you can do this with dropbox or if you need some kind of 3rd software.
After that you should be able to make source code changes on both computers without greater problems. (You may have to declare project dependencies changes for the android studio twice)
Builds depending on the build.gradle files should work to. But again: using a VCS is the better way to go.
Go for git, you can use bitbucket.com as a free remote repository.
This is a problem I have ran into when trying to store Android projects in a Dropbox folder. What happens is that Machine 1's IDE is mapping system resources (like the SDK) as being in that machine's filesystem. When you go to Machine 2, everything will work EXCEPT for what you expect--because the SDK will probably be in a different spot!
One way to get around this is to use your VCS (dropbox, git, whatever) as a repository for JUST your source files, and then have a local project created on each machine that reads from the Dropbox folder. This requires two separate projects that are mapped differently, but that have the same source folder.
I discovered this problem when I tried to load up an Android project on a new install on a Mac machine:
Do you see what's happening there? My Mac Android Studio is saying, "Hey, I don't see where "C:\Android\SDK is, but I do see that you have an Android SDK in a different folder, so I'm going to update your project files to reflect the actual location of the SDK."
In my opinion, the only way around this is to create your project on both machines, and version control your source and assets folder. If you don't create the project separately on each machine and use VCS for just the source and assets, the only way to get around build and filepath errors is to store your SDK in the same folder on each machine. This worked for me when I was building on a Windows desktop and Windows laptop, but no longer works for me since I am using a Macbook Pro.
I know this was questioned about 4 years ago, but this is up to now still an issue. Using a VCS seems like a good solution, but for me it is simply more overhead than i want to have. I also use Dropbox to synchronize my folders and the history they provide is for my private programming needs good enough. So i think, it would be good, if android studio simply uses relative paths.
I know it needs some system paths and it does a good job in looking at the local.properties and setting it to the correct place when the project is loaded.
The main problem with using Dropbox are the build-directories. There are many many references to fully qualified paths in the files within these directories. So my solution was to exclude the build-directories from Dropbox-synchronisation.
When you work at your laptop, build the app, create new files, change files or delete files, the build on your pc will be completely outdated when you switch back to it. but android studio will recognize this and do a fresh build when you start your project for the first time after working on the laptop.
so the biggest problem at this point is the file local.properties and this is handled correctly by android studio. it may be a good idea (or a really bad one, i don't know the drawbacks) when the build system wouldn't write fully qualified paths in the files within the build directory.
But up to now this is my solution for using Dropbox and not using a VCS:
exclude build-paths from Dropbox synchronisation
i hope this helps somebody.
I have been developing an Android app on a Windows machine. Now I would like to continue development on another Ubuntu 10.04 LTS machine. I would like to move between computers maintaining a recent copy of the project files on each computer. I am using SpiderOak to create a synchronization of the workspace directories of Eclipse which I am using for development. When the files were copied from the Windows machine onto the Ubuntu machine and I ran Eclipse, an error was presented that the path to the java sdk could not be validated and the path shown was the path relevant to the Windows machine.
Is there a simple solution to this? I can imagine that some files regarding the workspace specifics should not be transferred. Can I simply omit transferring the .metadata folder contained in each workspace created by Eclipse? I am not interested in synchronizing preferences/plugins/parts not essential to the operation of the app. Will excluding the .metadata from the sync create another problem in not transferring valuable information regarding the Android app being developed?
The correct, simplest, and most robust way to do what you want is to use a version control system like CVS, svn, git, etc. Even when working alone on a project, its a wise idea, not just for having the code on different computers but also because it gives you all the benefits of version management like being able to rollback changes, etc.
There are many free or inexpensive cvs, svn, and git hosting options; I strongly suggest you get an account and check your code in/out on the two machines you work on. If you have a web hosting provider, chances are they provide one of these services with your account.
If you're going to insist on manually moving/syncing code, you need to know that Eclipse workspaces are NOT designed or intended to be shared. Trying to do so always leads to headaches and other pain. Instead, you can export/import the project(s), not the workspace. Keep in mind that in Eclipse, a Project does not have to be located in the workspace directory; when you create a project there's an option to store it in any arbitrary location on your filesystem. Also note that all files under the project (including .project and .classpath) should be shared, except generated stuff like bin/ and gen/. This applies to using cvs, svn, etc or some other manual syncing mechanism.
As long as I have my project source code on hand, I will never consider synchronizing Eclipse workspace directory for cross-platform development. The correct way is maintain your source separately (by separately, I means do not bind your source to any IDE on any OS, use version control system is always recommended if the condition allows), wherever your want to start development by Eclipse or IntelliJ, on Windows, Linux or Mac, get a copy of you source and import it into your IDE.
Generally, the only files that makes your project a Android Project are:
src/
res/
assets/
lib/ (if you import external jar libraries)
AndroidManifest.xml
project.properties (or default.properties, renamed since r14)
proguard.cfg (if you use Proguard)
If you work within a team and use source control like SVN, these are the only required folders/files that need checked in to SVN, all others (.project, .classpath, .settings/, bin/, target/ and etc.) are not necessary. thoese are iteratively generated by IDE when import and build your project.
This applies to all three Android project type (Android Project, Libaray Project and Test Project), If you are familiar with other build tools like Ant or Maven, it may also helps you a lot to maintain cross-platform development.