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'
Related
Why don't we have a file similar to the .xcodeproj (for XCode applications) or an .xds (for Sencha Architect Projects) for our Android Studio Project?
I'm pretty sure a good number of you here have experienced the frustration of trying to import a project you see online in order to piece it apart better and learn how it works. I get that we are supposed to Import Android Projects built using Eclipse and Open Android Projects built using Android Studio.
However, why is it that we have to go through File -> Open -> then pick out the directory of the Android Studio app that we want to open? And the thing is, Android Studio doesn't seem to know it's an Android Studio project until it tries to open and build it. In the screenshot I have below, I have the sample Android Studio projects of ARToolKit, but I've only imported two of them.
As you can see, only those I've imported "can be seen as an Android Studio Project" as indicated that they have the Android Studio logo instead of a Folder.
This can be an issue for those just starting to develop in Android Studio on their own and they try and use existing projects (build from Eclipse or Android Studio) and they hit a snag with just trying to import the projects for reference. They might not know that they should import the folder and not the projectname/src subfolder. It adds to the "steep learning curve" that Android Development has if opening/importing projects aren't streamlined to a degree.
To sum up, my question is:
Why don't we have a single file that we can open that would in turn open Android Studio and import and build the project if it isn't built yet?
Android is not iOS. iOS development is only possible in xcode, hence it makes sense they added a shortcut to open it in xcode directly with a .xcodeproj file. Make life easier for iOS developers.
Android development however can be done outside of android studio as well. Eclipse is just one example, there may be other IDE's that support this. This is possible because android has standalone SDKs and tools that third party applications can use. iOS does not.
Imagine you are working on an android project in android studio. Then your boss tells you someone from 3000km away is going to help you. This guy may be using android studio, but maybe he isn't. When there are multiple options that developers can choose from individually, you do not want to pollute version control with files that you are using, but others may not care about. Each their environment.
This is merely a logical conclusion that you can come to by comparing. The "real" reason why this was done can only be answered by the people that created (adapted intellij) android studio.
This has been very frustrating to me too.
I try to give you a "beta" answer, waiting somebody to confirm it to me.
An Android project is just the composition of many parts that in some cases are concurrent to create the apk file.
It's just like what happens for the whole java projects: you have the main/src/java, the main/src/test, the maver or gradle files, the gradle or maven wrapper, the manifest, the configuration etc.
So you won't have a single project, but a series of folders that can contain many "flavours" or "versions" of the product itself.
The only help it is given to us is the Android studio icon that appears if a folder contains an android project in its subfolders.
I don't know if I have really answered to you, I just have given you my impressions and my thought.
Intellij has the option 'import module from existing resources'.
Android studio seemingly only has 'New module' or 'import module'.
Here is the result of both of these.
I much more prefer the Intellij way as it is way more organized, since it allows you to basically have multiple projects open at once. The Android Studio way does let you have them both open, but they are not treated as separate projects and or libraries, but instead as a different folder.
Is there any way to do this, or at least replicate it?
Right click on the project space and select New->Module and import from existing source. Find the path of your other project. When importing, you may rename the app files to "app2" or something. See if that's what you want.
Remember that Android Studio is built off of IntelliJ Idea, so a lot of the settings are similar. Personally, depending on my projects, I like to have several windows open for different projects since it gets crowded but I can understand why you'd want them in the same project space.
I have an Eclipse workspace which contains 60 projects. 40 of the projects are Android library projects and some library projects uses other library projects. Relations between projects are very complicated however with eclipse's library system it was really easy to manage them. It seems Android Studio has is fairly complicated system when it comes to work with multiple projects.
Here is my main dilemma, should I create one big Android Studio project and port entire Eclipse workspace into it as modules or should I create new Android Studio projects for every single Eclipse Project.
IntelliJ explains that IntelliJ (AS) 'Project' is equivalent of Eclipse workspace, with this logic creating one big Android Studio project seems better option however I have read that doing things in Android Studio's way is to keep projects separated.
As you see I am really confused and I don't want to jump in work before convincing myself about the best solutiın. I have spent 2 days and haven't find a satisfying answer yet. Please share your ideas with me.
Well, it's possible to make a really HUGE project with several modules.
In my last job I had the project with modules like app for Tablet, app for smartphone, another app which takes similar resources and libraries and also has separated tablet and smartphone version.
If I were you I would import to Android Studio every made before in Eclipse library first, then make them ready to implement to your existing projects.
Next, if I had been imported libraries I would try to import every project of my 20 existing apps and add to its build.gradle these libraries.
Yes, it would be a lot of work to import as huge workspace to Android Studio, and might it seems to be easier to create one enourmous project than split it to several apps using existing libraries.
But like I said don't do one project with several modules. It would may cause in slow Gradle building, taking too much computer resources, changing one library may cause problem in some modules It's also harder to write automated tests or unit tests.
Do import libraries first and make them executable and then, finally import your existing apps and connect them with your libraries. I'm sure it would give you a profit in the nearest future
I'm moving from Eclipse to android studio and this is my set up in eclipse:
I have several Android app projects, depending on several library projects (some shared) all within one workspace. In Android studio I first started creating a project per app, but quickly realized that I would have to have the library projects as modules within each project that uses them. This would mean duplicating the library projects and including them in each app, which is highly redundant and would require maintaining multiple copies of the libraries.
So I switched to having all my apps and libraries as modules within the same project. This works for building but creates other problems such as version control issues since each module lives in a separate version control repository.
What is the cleanest way to have this setup? And the real question is, can I have separate projects in AS that share the same external library projects?
NOTE
With the release of Android Studio 0.5.0, this answer is obsolete, but I'll leave it below for reference. For more up-to-date instructions, see How to share a single library source across multiple projects
In Android Studio, it's difficult to have shared library projects, because currently it's a limitation that all modules in a project must live under the same root folder; it seems like you found this out when you tried to solve your problem by making one big project that includes everything. We're working on trying to lift this limitation.
The best answer right now is to make the library modules separate projects and have them publish to a local Maven repository, and have the dependent projects pull them in from that repo. This means that you can't work on your app + library module sources from the context of a single project, unfortunately. A bigger disadvantage is that source attachments for those library modules doesn't work yet, so if you're trying to debug your app, you'll have difficulty stepping into code in the libraries.
I know this isn't a very great answer, but at this stage of Android Studio's evolution, it's probably the best we can do. We know yours is a fairly common use case, and it's a priority for us to support it.
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.