This question already has answers here:
Which Android IDE is better - Android Studio or Eclipse? [closed]
(5 answers)
Closed 7 years ago.
Google’s Android Studio is a development tool for Android based on the IntelliJ IDEA platform, one that managed to attract a lot of hype when it rolled out in mid-2013.
Eclipse, on the other hand, is the granddaddy of IDEs. although it support native Android support
which is the main differences in the Android Studio vs Eclipse battle?
which one is best for android devlopment
Go through https://www.airpair.com/android/android-studio-vs-eclipse
This might clerify your doubts.
Contents from site:
1 Before switching to Android Studio
I have written this guide to cover the basics of what you need to know before migrating your Eclipse projects over the Android Studio. If you have a large and gnarly project to migrate from Eclipse over to Android Studio, consider saving time by booking an hour or two with an AirPair expert who has done it before. Otherwise, read on!
2 Say Good-bye To Work Spaces And Sub-Projects
In Eclipse, you are probably familiar with the concept of a "Workspace." You likely even have an Android project currently which includes multiple component projects and libraries which are compiled into ".jar" files and included in the final resulting application. In Android Studio, projects are replaced with a new concept called "Modules" and "Library Modules."
3 Hello Modules
Modules are a "discrete unit of functionality that can be run, tested, and debugged independently" and are somewhat similar to an Eclipse project with a few key differences.
Each Module needs to have it's own Gradle build file(generally automatically generated for you when you create a new one, otherwise you can generate them if you are exporting a project from Eclipse). These Gradle files contain important details such as supported Android version ranges, dependencies and other meta-data about your Android project.
Just like in Eclipse, some Modules may be "Library Modules" which are conceptually the same as "Library projects."
4 Hello Improved Interface Designer
Android Studio features a new and improved interface design perspective where you can view the interface you are working on and its related components.Eclipse also has a similar design perspective so it shouldn't be too big of a shock for you. In Eclipse, a "perspective" is used for providing views and visible actions, as well as delivering mechanisms for interaction with resources, multi-tasking and information filtering.
5 Including Jar Dependencies
Like Eclipse, you will often need to link to JAR files created by 3rd parties. However, you will now need to get used to adding these .jar dependencies to your Gradle build file. Just like Eclipse, you will keep these .jar files in a "libs" folder at the root of your module (e.g. project) directory.
Simply "Right-Click" .jar files in your "libs" directory and select "Add As Library" and your selected JAR files will automatically be added as Gradle dependencies in the relevant build.gradle file for your Module. Make sure to always click "Sync Gradle" to ensure the project has been properly notified of the new dependency on these modules.
6 Adding Module Dependencies
Just like in Eclipse, one Module may depend on another Module. Follow these instructions to establish a dependency between two modules and Android Studio will automatically generate the necessary Gradle entries you will need.
7 Manifest Destiny
One major change you will need to get used to with Android Studio is that several common items and settings which once lived in the Android Manifest now are either automatically added (as in the case of the "debuggable=true" flag indicating an Android application may be debugged) or have been moved to build.gradle such as version codes and API min / max specifications. Feature and permission requirements, however, must still be declared in the Manifest as before (e.g. "permission: camera" and so on).
8 Get Help From An Android Expert
One thing that may be helpful is to enlist the help of a seasoned Android Studio expert to walk you through the nuances of the new IDE. Put in a request on AirPair to get paired with an expert - You will likely be surprised by how much ground you can cover in a short period of time talking to a real person.
9 Migrating From Android Studio
Read my guide on how to migrate from Android Studio to Eclipse to get specifics on the mechanics of exporting and importing an existing Eclipse project over to Android Studio. There are a number of potential issues that can occur along the way which I won't go into extensive detail on here.
10 Gradle Basics
The addition of Gradle is going to be your largest hurdle during your transition over to Android Studio.
11 Unit Testing
Android Studio comes complete with support for JUnit unit and Android tests, read more here. Setting up and running Unit Tests involves creating a few test classes and adding them to your project's run configuration. Follow the linked guide for more specifics. Popular testing frameworks such as Roboguice are not quite supported at this time but it wouldn't surprise me if they are in the near future.
12 Importing Remote Dependencies With Maven
Android Studio allows you to import remote library files from Maven Central. Browse Maven Central for remote libraries you might be interested in and follow these instructions to ensure these dependencies are automatically downloaded at compile time.
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'
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.
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
Just a quick question I did not find a good answer on. We are currently working on an APP created with Eclipse ADT Bundle. I recently started exploring Android Studio, and like it. Is it possible to still collaborate with my mates using Eclipse with a shared GitHub repo?
I noticed Android Studio converts the project to its own file structure, so I guess this does not go well with Eclipse, and the repo.
Is there any solutions for this? So I can keep developing in Android Studio, push to GitHub, while the rest of the team use Eclipse?
I think you can do it, you'll just have to explicitly define a sourceSet that matches the Eclipse structure. If you use any other build variants, they can't have any sourceSets because you wouldn't be able to check those files in to source control. However, there are several useful things you can do with build variants just with the build file. I think you can check in the build.gradle and other gradle stuff and it won't mess up your coworkers.
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.