Android Studio 1.0
android-developers.blogspot.com
android-developers.blogspot.com
I have been super impressed with PyCharm, and have heard great things about some of their other IDEs. Google picked the right partner to build on/with for this.
If they have sufficiently smoothed over some of the annoying workflow/build snags I was running into in the old Eclipse+ADT days, this could be a whole new ballgame for us who don't play with Java or Android for a living.
Gradle: compile 'org.sakaiproject.edu-services.course-management:course-management:10.2'
It's worth the transition.
"com.google.guava:guava:18.0" could have been "guava:18.0".
That's a pretty huge "if" though.
<dependency>
<groupId>net.java.dev</groupId>
<artifactId>jvyaml</artifactId>
<version>0.2.1</version>
</dependency>
For all statements X If X contains "Java" Emit comment Y where disparaging(Y) is true.
<dependency>
<groupId>org.sakaiproject.edu-services.course-management</groupId>
<artifactId>course-management</artifactId>
<version>10.2</version>
</dependency>
dependency{
groupID: "org.sakaiproject.edu-services.course-management"
artifactId: "course-management"
version: "10.2"
}
If you like Gradle fine, but this is a really stupid thing to make that choice over.
Or maybe it's worth formatting a Maven syntax sample in your comment just like an IDE would:
<dependency>
<groupId>org.sakaiproject.edu-services.course-management</groupId>
<artifactId>course-management</artifactId>
<version>10.2</version>
</dependency>The only criticism I have of jetbrains is that their support isn't the best. My experience has been that you can get faster and better answers by scouring the 'net than by using their support system or forum. They need to hire someone to own this and bring it into compliance with what is to be expected when you pay for a software products. I have software products costing around the same as PyCharm that have massively better support.
Again, love PyCharm, will continue to use it and recommend it, I just think they need to do better on this one area.
Although it is ironic that I am using the keyboard scheme from Eclipse. It's just...embedded in my muscle memory.
First, the lack of tutorials/videos on relevant topics that are up to date. For example, the Django with PyCharm video didn't have any audio and, last time I looked has not been replaced. I find video presentations to be particularly efficient as a means to quickly communicate intended usage and workflow.
Second, support becomes invaluable when it comes to non-trivial situations. For example, I still don't have an answer for this:
https://news.ycombinator.com/item?id=8569766
I frankly didn't even try to reach out to support due to my prior experience. And that's the issue. I have no problem with paying for good product. And I want to stress that PyCharm is a damn good product. When I do there's an expectation of quality support.
So I find myself at a strange point. I would unequivocally recommend PyCharm to anyone considering it. It is a very good product. And I have to do this while not being thrilled about their support, which feels really weird.
And at this point I freaking love gradle over Ant. I use to be an Ant fanatic (which isn't saying much), but gradle gives so much more structure to my builds now, and Maven is no longer such a pain in the ass.
Take the time to learn the shortcuts for AS. They might be long and arduous, but learn them. Then you can jump from keyboard to keyboard without having to tell a team member, "Before we begin, let me change your keyboard shortcuts to my preference".
not every team does pair programming
Especially problematic when I get called off to something else. I might forget to set the editor back. Now the person is annoyed until they either figure it out or call me back saying, "Fix it, ass."
Besides, to the point at hand, my rule is no dicking around with how the Romans do it. IntelliJ has its own rules. Eclipse another. The same is true for Emacs and VIM. Trying to make one the other overly complicates the matter for the team. Think how many people get confused by Emacs in Evil Mode.
A team requires that we work in concert. They should argue and defend tool selection. Once decided stick with it until its been played out.
Now can't THAT be fixed without throwing Vim away?? I've never used Vim, but I think its fans hail it as very configurable etc., the best thing since sliced bread (or is it Emacs? I can never remember which one cures cancer) :))
Anyway, these are discrepancies that "leak out" of your machine; like code formatting. That's a showstopper to be sure.
But keyboard shortcuts I see as a "private area", just like being left-handed and configuring one's machine to accommodate for that - sorry, but Ctrl+X and Ctrl+C aren't that convenient for someone who uses their left hand to control mouse (statistically 1 person in 10).
Maybe Android development isn't the best example here, since 1. no offense to those who swear by it, but Eclipse is inferior in compare to Android Studio, I don't think anyone would fiercely insist on sticking to it, 2. both these IDEs are closely integrated with different build systems.
But, say, in PHP? You can (or should be able to) freely switch between PhpStorm, NetBeans, Eclipse or even a regular text editor without affecting other team members as far as code itself is concerned.
To put it that way - personally I wouldn't like to work in an environment where it's prohibited :) That's just fascist, man...
For a time Android Studio was unstable and not feature complete[1], there were valid reasons to stay with Eclipse. These days the only people that aren't happy about it are those that prefer Eclipse to IntelliJ. That certainly is a valid opinion, but there were people that preferred IntelliJ to Eclipse the first time around. You can never please everyone.
[1] Yes, I know NDK support isn't yet in Android Studio, it is coming.
They have enough resources to maintain both ADT and Android Studio, it's a very surprising move.
I think it already did that before, didn't it? The shoe's just on the other foot now.
The best developers I know are debating between Maven+IntelliJ and Gradle+Android Studio. If this turns off a handful of people that are tangentially attached to Android development, so be it. The people pushing the boundaries of writing apps have switched already.
I know some people personally are more familiar with Eclipse than IntelliJ. I was one of those people. There are lots of training resources for people going from Eclipse to IntelliJ, it is a well tread path. Just give it a try.
I know of a platform that forces developers to learn how to use their IDE, their Operating System, their Hardware, and recently their new language, and their adoption hasn't slowed down...
In the case of Apple their closeness is not hurting them, and definitely not decreasing their adoption.
In the case of Microsoft... well, they still need to convince people to take Windows Phone seriously, so their closeness only helps to hurt them.
Also, you're not "forced" into anything - any Gradle compatible Java IDE will load and compile AS projects without a hitch (sadly, Eclipse Gradle support is really bad, hence the switch od IntelliJ platform).
I rather like the approach taken by Netbeans where they refactored the IDE to use build tools as the project format, with known targets mapped to IDE actions.
Same approach taken by Visual Studio as well.
Cannot say much about Android Studio, because lack of C++ editing/linting/refactoring/debugging and NDK support keeps me on Eclipse.
There's ways around it, but it's still pretty broken. :(
I mean, eclipse is a broken hellscape of failed promises on its own, but gdb is.... words fail me. Truly. AND I KNOW HOW TO USE GDB PRETTY WELL.
The development and debugging is done with the desktop version of the game. We avoid using Eclipse & friends unless we manage to break something at the Android side, which fortunately almost never happens.
We found this approach to be the most productive and less frustrating for our team.
You should also check SDL 2.0 if you are starting a new project, they already did all the heavy-lifting for you.
I would advise anybody listening to stay well away from NDK programming. Here there be dragons. Google has done their absolute best to pretend nobody ever needs to get their hands dirty in android. Which would be nice, if it were true.
Native development is a pleasure in iOS and Windows Phone.
On Android it feels like something Android team was forced to provide by upper management and do as little as they can.
Which given their reaction to alternative languages on the Android Team Fireside, might actually be true.
the Java code base only consists in a single Activity object and a ScaleListener.
We also ended up integrating our android build process in visual studio using a mix of python/batch scripts.
The make utility provided by the NDK is notorious for not being able to process absolute windows paths, so we cannot use the all-subdir-makefiles command. A workaround was to use a simple python script to generate a viable Android.mk file, setting the LOCAL_SRC_FILES var with a list of relative paths to our source files.
In the post-build event of a dedicated VS project, we batch the calls to ndk-build, the ant command, and the final little adb dance.
with the proper file hierarchy (src, res, jni and asset directories), the build process is very smooth.
Plus Eclipse has quite good static analyzer, which is something non optional when I code in languages like C and C++.
It was announced quite a while ago that ADT was being abandoned and that Android Studio would replace it when available.
Developers, developers, developers!
It's the only way I can use Xcode and keep my sanity :)
Edit: sorry if I came up like a complete tool, but every time when someone say that XCode is a good IDE small part of me dies :)
It's the first IDE that I've used that doesn't dedicate the entirety of its chrome to 100 different buttons. The developer workflow is nice (Open Files Quickly, Go to Line, Symbol navigation, pragma marks, breadcrumb bar, continuous build cycle, CI integration with OS X server, etc). I can get Vim bindings with Xvim, (this is not an Xcode feature by default but it's worth mentioning because it's the best Vim emulation plugin I've used apart from IntelliJ's). It has Interface Builder, Instruments, etc all integrated and super easy to work with. Most of all, Xcode's simplicity. I started iOS and Mac dev with 0 experience working with Xcode and I didn't need any, since it's so easy to use.
Yes, it's a good IDE. Is it a perfect one? Of course not, there are still hundreds of issues like Xcode complaining that a certificate already exists when I try to code-sign my app but Xcode doesn't use it, first few releases of new versions of Xcode are always crash happy, and Xcode's build settings are the ugliest part of Xcode.
Different people prefer different things I suppose. Maybe people became so used to Eclipse and Netbeans ugly UI and incomprehensible buttons everywhere that Xcode doesn't seem as feature full to them.
> incomprehensible buttons everywhere that Xcode doesn't seem as feature full to them My issues with Xcode isn't the lack of buttons, it's the lack of functionality. I started with Borland IDE's for Pascal and Java, then Jetbrains IDEs for Java, JS/HTML, and now Obj C, and through those, the tool became an extension of my person. I've been using Xcode now since 2009 and I find that it still gets in the way instead of helping me translate thought into code. It's gotten better in letting me know what I might need, but still falls short of actually letting me have it.
I always hear this, but never the specific feature that some other IDE offers. Please share.
* Buttons and toolbars - I don't use any. I have more or less consistent shortcuts between AppCode and XCode, and for less used features I'm using Cmd+Shift+A shortcut. It's an equivalent Cmd+Shift+P in Sublime and more powerful feature search than standard Cmd+? (which search only inside menus).
* Code navigation - put cursor on function, variable, property, whatever, press Alt+F7. You'll get a split panel, on the left are all places where function/variable/property is used (and you can filter it by read or write access), on the right is the preview panel, so you can see the code without changing cursor position in your main editor.
* Code navigation - Cmd + Ctrl + J to easily jump between function definition and declaration
* Refactoring - rename: yes, XCode have Rename, but AppCode rename is much more streamlined: put cursor on method/property name, press Ctrl+Cmd+E, change the name in place, as I'm typing every occurrence of the method/property name changes. I press Enter and the change is done, without modal dialog to review change. And rename works on protocols, too.
* Refactoring - Change Signature: in case I need to reorder function parameters. Put cursor on method name, Cmd+F6, reorder/rename parameters. And AppCode is smart enough to try to preserve natural flow of words - if the function is called saveContent:toFile, when I reorder params it will become saveToFile:content:
* Refactoring - easy promotion from ivar to property. And vice versa.
* Local history - I try to commit as often as possible, but I like an ability to see what I changed on the file in last couple of hours (with diff). And that option saved my ass couple of times.
* AppCode marks methods/properties that aren't used. I like to delete code. Less code is better. Very useful after refactoring.
* Better editor - I can split my editor horizontally/vertically however times I wish.
* Better editor - Shift + Ctrl + 1 - 9 will toggle quick bookmark. Ctrl + Alt + 1 - 9 will jump on the bookmark.
* Better editor - Cmd + Alt + UpArrow will expand selection. First sub-word (up to first "hump" in camel case) will be selected, then the whole word, then the next word, then the whole line... Cmd + Alt + DownArrow will go the other way.
* Better editor - Shift + Alt + Up/Down Arrow (or Shift + Alt + Click) will make multiple cursors, just like Sublime. Handy for changing lots of similar text lines.
* Better editor - select couple lines of code, Alt + Cmd + T will bring "Surround With..." popup. Press the mnemonic on the right to surround text with if, if/else, while, respondsToSelector, #ifdef,@try/@catch, etc, etc, etc. Time saver.
* Better editor - type SomeVeryLongClassNameIReallyHateToTypeTwice* var = alloc, press Tab, and AppCode will change "alloc" with [[SomeVeryLongClassNameIReallyHateToTypeTwice alloc] init]. Time saver.
* Better editor - Cmd+N will bring "Generate" popup where you can choose "Override method" or "Implement method", among other things. When the list of methods to implement/override is shown, you just type to narrow the selection. It's way faster to implement mandatory or optional delegate methods that way than to XCode-like start typing return value, then tableView: (for example) and picking the right method from the list.
Etc, etc - there's many more small things that good IDE ( * ) does to make programming more enjoyable. This list is just from top of my head.
-----
( * ) AppCode is just "good". For "very good" see Visual Studio + Resharper.
Xcode took some getting used to when I first came across it ("Where are all the buttons? How come the big PLAY button at the top runs the app but doesn't CONTINUE like it does in VS? Why are there no floating windows? How come the project and target options are a big list of stuff instead of tabbed pages? (The filter helps!) Why does it crash if I have a large header with many #defines in it? How do I easily switch between Release and Debug targets? Why is there no built-in TODO/FIXME filter?").... but having used it for a few years and having seen the updates to it and daily using it, I really really enjoy using it now. The debug overview of memory use and CPU/Network use and deep Instruments integration ("where am I leaking?!?! Let's just take a look!"), as well as the splitting usage by thread during runtime is really helpful and there isn't much going on screenwise, so I just have to look at code. The recent version is better than the previous one because it has a logical call graph shown for each thread instead of a popup irritating menu like the previous one (click click click click misclick arrgggh)
The navigation bar at the top is also strangely useful, with back and forward buttons! I never thought I'd miss that but I do if I go elsewhere.
A trip back to VS (admittedly an old version, thanks work) makes for unpleasant experiences (argh building is sooooo slow, where are parallel builds???).
The 'callers/callees' list is really helpful when inside a function to see where things are getting called from; admittedly no refactor support for C++ is disappointing but I don't really use refactoring much.
EDIT: One thing I really really really miss from Visual Studio is the Ctrl-Shift-Space shortcut for showing function parameters. You get them as a hint first time in Xcode and it might shove them into the text where you can tab between parameters but with overloaded functions it typically chooses the wrong function. With VS the popup hint dynamically changes as you're typing to show the right overload, and I miss it.
Maybe this is everyone's problem with it?
I've spent about 6 hours a day in Xcode since 4.4, so it may be a bit of Stockholm Syndrome, but I feel very comfortable. In the last year, I've had to do some work in IntelliJ/WebStorm/RubyMine (all the JetBrains IDEs!), and while they're definitely nice, I would say they're harder to use, less predictable, and have wayyyyyy too many buttons. Also you can tell they're not quite native (as someone who cares about aesthetics, even in IDEs).
Xcode forces you to figure out the shortcut keys. I like it that way. And I spend more time hitting tab and enter than I do actual typing, and that's all we really want from an IDE anyway, right?
Xcode, on the other hand, is so nice and Appley and clean. It's a shame it runs so slow and crashes at the slightest breeze. Still, I'd rather use an Xcode that I have to force quit every 30 minutes than a stable Visual Studio any day.
I only have half a line of buttons under the main toolbar. The number of windows I have docked varies from 1-2 while programming to about 5-6 while debugging (with the watch list, call stack etc. all easily viewable).
I would reckon that most programmers spend at least some amount of time customising their development environment; I mean it's what you spend most of your day using. What is important is what features and development-helpers your IDE supports (you don't have to use all features) and how configurable the environment is (while not being overly slow and buggy), in my opinion.
What is it about XCode that you think is bad?
Everyone uses their tools in different ways. I use Visual Studio in my day job, but I prefer to use Emacs for most of my side dev these days. Given that perhaps I don't use everything an IDE has to offer.
Comparing Visual Studio with XCode, the following features are what I use to most.
Autocomplete - XCode wins here. Say I have two variables - clientService and clientMapper. In XCode I can type cl<tab> and it will complete the client part of the variable for me, I then only have to choose between Service and Mapper. Visual Studio doesn't. Pressing <tab> will choose the entire current selected item.
Quick open - XCode wins. Cmd + Shift + O (I think) start typing the file name, hit enter and there you are. Visual Studio (without Resharper) forces you to search through the Solution Explorer, which is slow and searches for methods as well as files.
Syntax/Error/Warning Highlighting. Both IDEs do this just fine.
Debugging - Cant think of anything to differentiate these IDE's. It used to be a real pain to inspect variables in XCode, but that was more GCCs fault rather than XCode. Since moving to LLVM, I haven't had any problems.
Refactoring - I probably don't use these tools as much as I could. But the basics are covered. Extract method, rename variables etc.. can be handled fine by both. I don't use anything else.
Vim keybindings. There is vsVim for Visual Studio and now I see there is XVim for XCode.
* Autocomplete - the XCode way to do autocomplete drives me crazy. Why XCode hides what I'm typing with it's guess? Regarding Visual Studio autocomplete: you start typing variable. The autocomplete narrows your choice. You press up arrow/down arrow, enter/tab, you're there. And the choice is always relevant, instead of "I'll put just everything I can think of" XCode autocomplete
* Quick open - which Visual Studio version you're using? In VS 2013 you can press Ctrl+, and get essentially the same functionality as XCode. Type file name, symbol name, enter, the file is open.
* Syntax/Error/Warning - Visual Studio gives you extra help if something isn't quite right. You typed "Regex" and there's red squiggly line? Place the cursor there and press Ctrl+. What's that? An option to include System.Text.RegularExpressions namespace automatically? Or you typed parameter name that doesn't exists? XCode will curse you, Visual Studio will offer (via Ctrl+.) to make the method for you, and it will infer return value and type of parameters from your code. That's great way to start writing class from scratch, and I miss it in XCode.
* Debugging - again, I can't argue about C++ debugger, but C# debugger is actually much more powerful than XCode debugger. You can inspect variable values in tooltips, there's powerful visualizers, there's an option to pin tooltips with values so they're always visible (even when the program stops, so you can see the last value while fixing the error) and last and not least - very, very powerful Immediate window, sort of REPL for C#. I hope LLDB will have something similar for Swift.
And there's much more that Visual Studio provides. Code Lenses (only in Ultimate version, but still). Code Peek - XCode sorta have something similar in Assistant Editor, but not quite. Find References. Call Hierarchy. And that's just the basic Visual Studio (now free) functionality. With Resharper it's completely different beast.
I never knew about that Ctrl+,. Thanks for pointing it out. I don't think it is as powerful as XCodes, XCode does more fuzzy matching. I think (don't have mac open to check) in XCode if I have a file called ClientsController and I type ClientC it will bring up ClientsController. In VS it seems I have to know I want the plural ClientsController..
You are spot on with your other points though re debugging and syntax fixing. VS is better than XCode in many ways, but I would say not so much that XCode should be despised as satans spawn.
Disclaimer: MS employee, not on VS team though.
If Google does anything, they need to build/buy a simulator (Genymotion for example) instead of the emulator.
As for the idea that Google should start from scratch: that would just put them back a decade. I'm very glad they decided to build on an existing great platform instead.
XCode's autocomplete is a joke compared to Android Studio's -- a strongly typed & non-dynamic language does wonders for how efficiently & accurately an IDE can fill in your dots for you.
seconds is far too long... That you're even trying to argue that autocomplete is more powerful in XCode than AS shows you haven't used AS for more than maybe a minute. I've used both side by side for years (well, Eclipse and IntelliJ before AS), and it's honestly not even close. XCode takes longer and consistently suggests functions not available on my object, or classes I never use. XCode is great at plenty of things, but autocomplete is its #1 weakness.
> I can cntrl+click and see the full docs
And in AS I can Cmd+Click and see the source..
> debugging
debugging live running apps w/o having to launch from the IDE is awesome. And I don't think there's a single debugging feature that XCode has that AS doesn't. Seeing as Obj-C is a dynamic language, the console REPL is pretty nice, but that's a language feature more than an IDE feature.
I use Jetbrains IDEs and Xcode every day. Whenever I have to write any significant amount of code, I switch from Xcode to Appcode.
> I'd kill for having an xCode like realtime autocomplete and documentation
From my experience, this is true for Jetbrains IDEs, and not for Xcode, particularly for autocomplete. Xcode autocomplete is a pain, and sometimes gets in the way instead of being actually helpful.
Jetbrains sure know how to produce an awesome IDE.
Somehow on Core I7, 26GB ram + SSD it still takes me less time to make a cup of coffee than for Eclipse to start up :(
I love Jetbrains tools!
Eclipse (I use Luna which seems to be faster than the previous version) starts in a matter of seconds on my MacBook Air (8GB of RAM + SSD).
Eclipse was great for what it was at one time though.
On the other hand, I want to be using the best and latest tools, and stay up to date with what the broader Android dev community is doing.
Would love to hear from others with similar feelings...
Sixty-six.
I would certainly not call Gradle easy nor fast to learn.
[1] https://www.gradle.org/docs/current/userguide/userguide.html
Not only that, but I suspect Gradle won't use Groovy to parse the build scripts for much longer. Those scripts conform to a rough CSS-style syntax that Gradleware could easily replace with their own custom lightweight parser calling Java 8 lambdas. Given that they replaced virtually all the Groovy in their codebase with Java when they upgraded to Gradle 2.0, the next logical step is to eliminate dependence of the Groovy parser as soon as they can.
The Android specific ones are here:
* http://developer.android.com/tools/building/configuring-grad...
* http://tools.android.com/tech-docs/new-build-system/user-gui...
And then one day, I realized that the web site that I always get back to in order to fix my build files is Stack Overflow, not gradle.org.
The fact that the documentation is so big is an issue, not a feature, because at this size, it's just too big to navigate, contains extreme amounts of redundancies between sections and basically, is not usable in this form.
You know your tool has a problem when the only way to fix problems is to search Stack Overflow.
It's when your app becomes more complicated (product flavor's for example), that you need to read and understand the gradle documentation. If this is the case, then you are not a novice and 66 chapters of docs is a blessing not a curse.
and Again _the Android gradle plug-in only supports a subset of gradle_!
Android Studio is fanciful, I used it for months during the beta. There is one gotcha which leads me to prefer Eclipse. In Eclipse, the compile process is much more integrated with the IDE. The compile step appears to happen inside the IDE app/process tree/whatever. In JetBrains, the compile process is a separate process, much more disconnected from the IDE. Hence JetBrains takes more memory and is slower and running a project build and getting errors back into the IDE. I can appreciate an external build process being flexible for Jetbrains to use their IDE with nearly any language/compiler, but Eclipse worked much faster overall on a 4GB ram setup.
Eclipse has it's own compiler and it uses that to build from within the IDE. Since this is not using Javac, it means that you might and very likely will not have equivalent binaries. Not specific to Android, but this also meant that when a new version of Java is released, IntelliJ can immediately take advantage, but you will be stuck waiting on Eclipse (and NetBeans).
Personally, I prefer the IntrlliJ approach since the IDE, javac on my workstation, and javac on the build server can output identical binaries, I trust the results even more so.
Also, if I am not mistaken, IDEA has its own compiler, as well. It just doesn't emit bytecode.
Gradle covers the 80% use case really well. Everyone new to Android should use Studio + Gradle, no question. Dependencies are a breeze, the integration between Gradle & Studio is wonderful, the syntax is super simple, and the plugin handles most things by default pretty well. There are several things like build variants & package name interpolation that were impossible with Ant, difficult with Maven, and are trivial with Gradle.
The intermediate level stuff is more of a mixed bag. Some tests work well with Gradle, others (like Robolectric) are more of a pain. The NDK support isn't worked out yet. Some of the more fringe plugins like code coverage and formatting aren't plugged in yet. Here you will probably have to understand a bit about Gradle, but the tools team is making progress fixing the issues. What was a problem 2 months ago just works out of the box today with no Gradle specific knowledge.
For advanced things like writing your own plugins, then you have to know the respective build system. I don't know Maven well enough to write my own plugins. I have written a couple Gradle plugins. I have one that uploads APKs at the end of the build to various distribution APIs, one for secure signing, and one for bumping the versions whenever I want to. It was pretty straightforward to figure out.
I'd concede that Studio/Gradle is the future, and that Gradle is more powerful than Maven; my "issues" are purely emotional :) With all that there is to learn and explore in this world, I don't want to have to spend time on another Java build tool when I already know 2 good ones (Ant and Maven).
Anyway, having installed the JDK 8 u25 on Mac OSX, Android Studio wouldn't run. You need to export:
export STUDIO_JDK=/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk
Modify .bash_profile in your home directory to get that to stick.
http://tools.android.com/recent/androidstudio1rc3_releasecan...
Much better than the BASH profile thingy (which doesn't work without opening a terminal, obviously).
This brings me to my most wanted feature in Android Studio - smooth native scrolling! Right now it scrolls lines-at-a-time rather than pixels-at-a-time, which is slightly annoying. Eclipse on Windows was very nice in this respect.
It's also alarming to me that nobody else here on Hacker News seems to be concerned about this.
I know Google isn't a free-software business like Red Hat, but they've benefited enormously from the work of the free software community, in particular in building Android, and they touted Android as being open. It was inspiring to see a really open phone platform birthed, but every month it seems like Android is less and less open. Supporting only a proprietary development toolchain is one more step toward the dark side.
Android Studio is open source:
https://android.googlesource.com/platform/tools/adt/idea/
There is certainly a commercial version which is not, but you don't have to use that and Google isn't shipping that version at last check.
I'm happy that the truth is much brighter than what I thought.
I can't remember what it is called, but you will be able to find it on jet brains homepage.
Apparently Google is waiting that JetBrains eventually releases CLion.
It is anyone's guess when it will achieve parity with CDT.
To my gradle file. I've set up a pretty simplistic JNI directory structure though. I can provide more info if this isn't enough as it's been awhile since I've set up a project from scratch.
I want native code debugging, refactoring, static code analysis (Codan like), code navigation.
JetBrains et al really built an impressive IDE platform. I'm glad there are open source alternatives to Eclipse.
The Community Edition of IntelliJ is open source. Android Studio, which is a fork of Community Edition, is also open source.
The current NDK integration is a dead end, we don't recommend using it, as we are working on a new version that use the native support in Gradle.
There is absolutely nothing stopping you from using NDK code with AS and Gradle.
Glad to hear though, I'll try it for my next android project.
Also, not to belittle your investment in Eclipse, but counting university is laughable and unless you're a maestro and use some random plugins that make you a 10x developer you're probably better off switching.
As others have mentioned you can change your keymap to Eclipse, or just learn new ones. Hell, I only know 4 keystrokes: autocomplete, find class by name/click, rename variable/method, and reformat code. Yet somehow I am successful -- I doubt it's my IDE. It's just effortless and I don't have to deal with stupid build crap while writing code. Granted, I don't know much about modern Eclipse, I haven't used it for two years.
If it weren't too much effort I'd be writing java in vim where I have almost 8 years experience, but I haven't gotten around to bothering because my environment is not the bottleneck to writing good code. It's probably more the crappy Android APIs and unexpected behaviors of standard libs that will unlikely be timely fixed.
I'm having trouble getting my point across but basically what I'm saying is that most of my time is spent thinking. The coding part is small and as long as the IDE is not batshit crazy I kind be just as productive in any IDE.
I will admit that there is one IDE that I like the best but I wouldn't argue that I'm able to finish projects twice as fast with it than with any other reasonable IDE's.
And yes, XCode, Eclipse, Android Studio are more or less the same.
I've been using Eclipse for my day job for the past 4 years and I have no issue switching between that and Android Studio.
Why?
Because I got burned by Eclipse so many times I got used to developing solely with vim and ant - then I started using NetBeans+NBAndroid and found it comfortable enough.
Still, now that it's 1.0 I'll eventually migrate.
As for advantages over Eclipse, they've been minor. No real big improvements except the automatic dependency management of Gradle.
The reason for the giant effort to switch the entire ecosystem over is a bit mysterious to me.
Likewise, under Compiler there's a "Java Compiler" panel in the hierarchy. You can switch it to using the Eclipse compiler which I think allows you to launch with errors in your project.
For me, IntelliJ's auto-complete is a lot nicer than Eclipse's and that makes me more productive.
However, i've found that i do not notice that so much and get much more benefit from gradle then ant. Also, the project structure has ended up being alot cleaner and easier to navigate for me. Plus, I like all the slick IntelliJ style features.
As for the giant effort to switch? I'd say gradle is a big one.
It was also educational just how big a performance difference at code or xml editing existed between ADT and the same Eclipse installation on a vanilla Java project: the latter is like using a machine a decade newer.
The tools people have always had a casual disregard for NDK users too, who make a disproportionately large amount of the Play Store revenue. The whole thing has never seemed like it was dog fooded at all, just developed for amusement.
If you want the latest and greatest IntelliJ features, use IntelliJ + Android Plugin. If you want the latest and greatest Android specific features, use Android Studio.
If you have a paid license of IntelliJ, you are probably better off with IntelliJ + Android plugin.
ADT plugin is being abandoned.
Why do they make it SO HARD to even delete a project?
http://stackoverflow.com/questions/16710290/how-to-delete-a-...
You will be prompted if you really want to delete the project. Click Yes.
Tools team promised that compatibility breaking changes will stop after 1.0 until other major revisions. Let's hope that holds up :)
Eclipse + Java has always been a non-intuitive headache for me - will this IDE support Python? Has Google made Python a first-class language yet in their stack?
Inquisitive minds would like to know.
If you people think the target market for this is just Eclipse and Android developers then you have not been paying attention to the larger picture of cross-platform stacks.
It even has the word Studio in the name for crying out loud.
You're being downvoted because your comment reads as being off-topic and/or uninformed (especially with the Python mention). If by Visual Studio and C# you were referring to Xamarin or Mono for Android it would have been clearer if you mentioned that. It would be helpful if you also mentioned why you feel Android Studio targets developers who use those technology instead of the larger pool of Android developers in general. I don't think there's a bias against those technologies here, only against poor comments.
If you use the android emulator with the x86 android image (on a HAXM capable CPU), then it runs fine. iOS has always used a simulator.
https://developer.android.com/sdk/index.html
https://developer.android.com/training/index.html
Things are looking good for Android development, especially with regards to Firebase being acquired.
You can use MIT's AppInventor via the website, so presumably you could use an Android based web browser if you really wanted to. Seems like it would be pretty painful trying to do that from a small screen device however.