"Instant Run lets developers build and deploy their apps once (both to the emulator or to a physical device) and then as they change their code and deploy it, it’ll only take a second or two before they can see those changes in the running app. This feature will work for all apps that target Ice Cream Sandwich and later. Cuthbertson politely refused to tell us how exactly Instant Run works, but promised that Google will detail the technology behind this feature in the future."
It's definitely possible. JRebel for Android [1] has been available for quite some time now with none of the limitations on what kind of changes are supported. Will they get it stable? Time will tell.
I've had hit and miss results so far, sometimes it's great and then a bunch of times it ends up launching the app twice. Perhaps I'm either doing something wrong or I'm not hitting the right use when this works flawlessly. So far, however, hit and miss with little clear reason.
My hypothesis is that launching the app twice actually means it's crashing the app.
When the app is running, and you do an instant run from Android Studio, it will try doing the hot swap. The app crashes and immediately relaunches (and it's the same build). All the while Android Studio is monitoring the app task and waiting for the hot swap to take place. It keeps checking, times out after a few seconds (realizing it didn't update successfully), and then it deploys and launches the new APK, as a last resort.
My point is to be careful when testing if you're getting the double launches, because the first time it is launched, it's still the old APK.
For some reason, it doesn't work with my radio button text, it doesn't update it, but it works with labels and button texts. Well, maybe it's not stable yet, but it's awesome, and I'm happy that it's there.
It does not seem to be working for me. It does not reflect logic changes and I thought it was only for UI,however that also had no effect.Am I doing something wrong?
I've been playing around with it, but not for a full project. It's very interesting - unlike React Native the JS has full access to all native APIs, so if you want to call one no-one has written a wrapper for yet you just can.
I've actually ended up writing a lot of platform specific code as I found the cross-platform stuff to be kind of janky. But it basically lets me write an iOS app, using iOS APIs (and even iOS sample code, if I apply myself)... in JavaScript. It's not bad at all.
> unlike React Native the JS has full access to all native APIs, so if you want to call one no-one has written a wrapper for yet you just can.
Yup I think I'll stay as far away from that as possible! Sounds like a recipe for a 10 hour debugging binge. I think managed APIs are pretty essential when doing interop.
Depends what you're trying to do. For instance, I was playing around with notifications in iOS. They have the ability for you to download data in the background before a notification is opened, which is a tremendously useful thing to be able to do. Last I checked the multi-platform frameworks don't allow you to do it - so being able to use NativeScript's cross-platform stuff then augment it as you desire is a pretty great thing.
I dev Droid and iOS natively, and am playing with instant run now. iOS simulator still faster than Instant Run on a real sized project. Instant Run just helps to bring more parity, but is still not there yet.
Yup, modified activities but games should be able to take advantage of this as well. In the timestamp below, it shows the presenter making the chess pieces larger and smaller. It is available on the canary build beginning today. Give it a try?
Just tested. It doesn't replace the activities, it replaces parts of the compiled code (classes' dex?) with new versions.
It works well most of the time. Sometimes it can cause some nasty crashes. I guess it's expected since you can't just replace some object instances and expect it to work.
The settings does have an option to also restart the current activity when it does the hot swapping. I guess it's to account for those cases when hot swapping doesn't work as expected.
It crashes? That's pretty bad. VS Edit&Continue and Eclipse JDT, which also do something similar, warn you when a change can't be applied live (or would cause a crash resuming on old state).
I've generally found with this feature in various IDEs that it's good for changing a constant in some drawing code but not really much else, and then it just turns into frustration as you get constant popups reminding you it won't apply some change live. I think the problem is that in the timeframe companies like Google and Microsoft allocate for such a feature, it's extremely difficult to produce something that works 99% of the time. If we could get there (and improve step backwards functionality, as well) we would probably just abandon the divide between programming and debugging mode in IDEs and always have an updated copy running (or mostly, paused) alongside ready to context-switch into.
I think they have to compete with how React Native handles it, to make sure the developer experience developing Native Android apps is at least at par with those developing using React native, Ionic etc.
Good catch. Here's what Google says:
"Since this initial release is a preview, you may want to download and run an additional copy of Android Studio in parallel with your current version."
Do you know what improvements this build has for android NDK? Last time I checked the Gradle build plugin for NDK was still experimental and there were a lot of hacks to build and to package native libs into apk file.
It's not the same as Eclipse, in that you could just setup a ndk build script to run when you saved a file... it's supposed to be much better (since you're supposed to edit C files and have full autocompletion and all).
The only awkward part was building the .so files - as long as you could do that (and you could always do that separately with your make files) you were good to go. Building the final apk is fine as long as you have the jni files in the right locations.
Sorry for off topic but why does every news site mobile layout wants me to click read more/continue reading? Now techcrunch too. I tried to Google the question but didn't get an answer.. Who and why invented this trend?
Is it to measure engagement? Surely there are better ways.. Most of the sites don't lazy load the hidden content, so there's no bandwidth benefit either...
This is just a hypothesis, but maybe for viewability for ads? There's a big controversy among advertisers/publishers over the difference between "was my ad shown" and "was my ad seen." Clicking Read More at least says you're going to look a little down the page. Some evidence for it is that right below the "Read More" button, there's usually an annoying little ad square.
Maybe you could just get bored within the article and they want to show you more content before you leave the page. if you actually want to finish the article a simple button press isn't trememndous. just keep your interest and show you alternatives early.
Could be a performance/turnover-rate thing. If they only have to send a small bite of the article in the beginning, it means a smaller response body, which means the page will load faster. You are less likely to close the page in frustration as it continues to load.
I don't think this is the reason. The amount of text that is contained in the article is usually smaller than the shit ton of superfluous JS and images they're sending. If they're looking to optimize page load, there are lower-hanging fruits.
It won't be there for a while. It should be on http://tools.android.com/recent soon (it should have been already, but I guess they were waiting for the conference to start before putting it there).
Java is the language of the platform for the foreseeable future.
You might want to check out something like Kotlin (great language which compiles to java bytecode) but IMO there is little reason to invest in Dart for Android right now.
It is heralded by the Dart team, entirely independently from the Android team. AFAIK, they are just shopping for a problem to solve with Dart now that they are not going to be able to ship their VM with Chrome.
You might be referring to Flutter, which is a project of Chrome, started independently from Dart, and who's purpose is to make the core of Chrome better for app development, not find a purpose for Dart.
Flutter started with JS as the scripting language. The Dart team is certainly lending a lot of support to Flutter, because of the promise of a compelling mobile story for Dart.
You should check out http://flutter.io/ which is a Dart environment that works on Android and iOS. It's probably closer to web development (without a document or CSS), than traditional Android development.
I have strong suspicion that Google will support Go in the future:
- Go 1.5 introduced support for mobile development (and Android in 1.4): https://blog.golang.org/go1.5
- If Android can become less bound to Java, I see Go becoming the go-to language for Android development.
Does anyone know how this compares to the speed of running apps under something like genymotion? It basically creates an android device in virtualbox. The speed blew me away compared to the old android virtual devices. Granted, I hadn't messed with android development for a couple of years before that, so it's possible everything is that much faster now..
Instant Run is different from Genymotion. With both, you should be able to get < 1s compile + deploy times if you're making a change supported by Instant Run. On my 3 years old Linux laptop and a Nexus 4, Instant Run compiles and deploys within 2 seconds :)
Offtopic: is the experience as good on Windows and Linux as on OSX? I'm planning on selling the MBP (too expensive to keep hardware up-to-date in third-world countries).
Eclipse is Java based and packages all the necessary tools with it but it is extremely debatable whether that means it "works fine" anywhere...
But to address the grandparent post a bit more directly, in my experience Android Studio runs great under both Windows and Linux, I've used it frequently on both with no complaints.
The instant run feature this new canary build has will be welcome since the deploy->run cycle has always been just slow enough to feel like a bottleneck to me, though I never faulted Android Studio for this.
Is it really so hard to understand? I was responding to a specific comment which was:
"Works fine on Linux. The IDE is Java based and it packages all the necessary tools with it so it should work fine anywhere."
Eclipse fits all those criteria (IDE is Java based and it packages all the necessary tools with it). But I would argue Eclipse doesn't "work fine" anywhere, it is a bloated, slow piece of crap (equally, everywhere), thus those criteria are not really that useful in determining if something "works fine" somewhere.
As a ten year (now-cured) Java/J2EE developer, I whole-heartedly agree with you that Eclipse is a bloated, slow piece of crap.
IntelliJ is much better, very quick and responsive. It's actually a great demonstration of how Java apps don't NEED to be slow PsOS. I'm an iOS guy and didn't know about Android Studio, and the prospect of going back to Eclipse has kept me from even thinking about Android dev. Now I might well give it another try.
I've never gotten the Emulator to work in Windows (8.1), and from what I gather after some googling I did at the time it is at best challenging to do. I'm hoping the talk of new emulators as part of the instant run stuff will have Windows sorted out and not be a 3rd (or worse) class citizen again.
I had issues with fonts in Android Studio & IntelliJ on Linux, but other than that it is totally fine. I know there are font work arounds, I've messed around with it a few times and sometimes gotten it working and sometimes not.
In IntelliJ 15 there's a new setting Settings > Appearance and Behavior > Appearance > Antialiasing > Editor. Set that to "Greyscale". Fixed all font issues on 2 different Linux boxes (Fedora 20 and Debian unstable). I use Consolas.
Google is probably very wary of going more into Oracle territory.
Given Android's adoption at this point, if I were Google's management, I'd adopt another JVM language. Sort of Objective-C -> Swift. Kotlin would probably the safest bet from an "easy adoption" point of view.
Kotlin seems to be the way that this is moving, especially with Kotlin being added to IntelliJ IDEA 15 [1]. I would imagine that Kotlin support would be built into Android Studio soon.
JVM- and Android-targeted Kotlin were built in simultaneously, whereas Android-targeted Groovy was added on last year as an afterthought, so the QA aspects of each will likely be very different. Also, the full-time developer working on Groovy's Android codebase was retrenched last year, whereas Jetbrains is still supporting Kotlin's Android codebase.
It's not being disingenuous: by definition, a JVM has to execute Java bytecode, Android's toolchain merely uses Java bytecode as an intermediate representation. Dalvik VM =/= JVM, insisting it is because the source code was written in Java and/or transitioned through Java bytecode is being disingenuous. It would aslo imply Linux a JVM because GCJ[1] can compile Java bytecode to (Linux) executables.
No it doesn't. As long as the language compiles to DEX bytecode the ART compiler and runtime can execute it. The JVM and ART VM are very different and don't even use similar architectures. I should also remind you that Oracle tried to sue Google in regards to VM IP and lost spectacularly so your claim that the old Dalvik VM and JVM are similar and any differences are just trying to split hairs is erroneous.
OK but you're straying into pedantry. They have their own VM which runs bytecode generated by a translation layer. The only language supported by that translation layer is JVM bytecode. Therefore, they effectively have an implementation of the JVM.
You are stripping words of their meaning. There is a precise definition of what JVM means. ART isn't close to that and doesn't try to do that. There's nothing wrong with that, just don't call it a JVM.
You can translate Java into JavaScript and run it on a JavaScript VM. This doesn't make that JavaScript VM a JVM.
Pointing out that a language isn't Java simply because it has curly braces isn't straying into pedantry. Pointing out that something isn't ice simply because it is solid isn't straying into pedantry.
They're not stripping anything of it's meaning; they're taking things to their logical conclusion. And there's really no way that you can claim the language used for Android development is not Java.
> And there's really no way that you can claim the language used for Android development is not Java.
Even if the language used for Android development is were Java that wouldn't make ART a JVM. JVM is a VM specification that is not tied to the source but the byte code. In several cases (eg. method lookup) there a significant differences between Java and JVM semantics.
The language used for Android development is not Java. Again, there is a precise definition of what Java means (the language specification) and a test to verify what you have is Java (the TCK). ART/Android does not pass that test (it's not even close) and has no intention of doing so. For example Java semantics allow on the fly code generation. AFAIK ART/Android does not support this.
Actually ART runs DEX bytecode not JVM bytecode so I'd argue it's not a JVM at all. By your definition anything that can translate Java to an intermediate representation is a JVM. Does that make LLVM a JVM?
No, but ART's sole purpose is to run JVM translated programs. If you had another fm that run Java and other languages, you could argue that it is A JVM, but it is also a fm for what ever the language it runs.
I would argue who is being pedantic. They have a Java SDK so of course they're going to have a JVM bytecode->DEX bytecode translator, but that doesn't mean their VM is even remotely close to a JVM as they don't even share the same architecture.
No, I'm saying the relevance of Java ends at the source level. When the app is converted to DEX bytecode and then compiled to native code there is no dependency on the language or JVM as you seem to think.
No, the reason Google isn't going to update to Java 8 is due to the litigation from Oracle. Google will likely transition to a new language so why invest time and money upgrading to a language they're going to abandon soon.
Swift and Objective-C are Apple's territory if Java is Oracle's territory. Besides they are more like no-languages than programming languages. There is a huge number of Java programmers out there compared to Kotlin or some other "it is so cool" language.
Give Kotlin a try. I have great experiences with the language on both mobile and server development. Don't miss Java 8 a bit when I do server development in Kotlin.
As appealing as Kotlin can be, many of us are only allowed to use platform languages on customer projects.
Hence why Google's silence on the language support is so irritating.
I could do without another Android Studio release, if they provided an open roadmap for Android for whatever language they think on supporting going forward. Instead of pure silence.
As it is, we will be using Java 10 on the desktop, server and IoT devices, when they eventually remember to let us know of a new platform language.
Yes. There are loads of commits in the Jack and ART repositories of AOSP relating to Java 8 features like lambdas, method references, and default methods.
I'd expect them to come with the next release of Android (since they require new VM bytecode instructions), with a possible official back-port tool similar to Retrolambda.
Considering Google's friendly relationship with Jetbrains (Android Studio) I'm more likely to believe that they will just make Kotlin an official language.
I don't think so. In order for that to happen, Google would need to support new bytecodes in their JVM (Dalvik? I forget), which would be a backwards-incompatible change. So unfortunately I don't expect to see Java 8 in Android for quite a while.
Dalvik has been replaced by ART (the Android Run Time) in 5.0 Lollipop. Dalvik was the JIT compiler in 4.4 and below, and with 5.0+, ART is an ahead-of-time compiler.
Instant Run only works from within Android Studio.
We still support command line builds (and will continue to do so). However, as I understand it, there wasn't an easy way for us to deploy an incremental build from the command line, as this takes advantage of an integration with the IDE.
Of course, both Android Studio and the build system are open source, so you're free to take a look at how it's done.
I am torn between this and CodeWorks for Android by NVIDIA. I realize CodeWorks is more for game devs, and carries a lot of GPU support, but it is a one-click install and ties nicely into MS Visual Studio.
I have to admit, I vastly prefer web development right now as waiting at least 30 seconds for your native Android app to compile and run on a device really sucks the fun out of it for me compared to just refreshing a browser. Hopefully the live reload feature improves this!
By my experience (based on the project I'm working on) regular build speed hasn't changed at all. Obviously I'm not saying there's no improvement, only that apparently it's not universal.
Google has the resource to build their own text editor -- so why don't they do it? It seems displeasing to have to work with 3rd party software in order to develop an Android app. And this is not to say IntelliJ is a bad choice, but it would seem that they could rid away with any extraneous portions of the editor. It could also be optimized for Android development, unless that's what this "Android Studio" is.
> Google has the resource to build their own text editor -- so why don't they do it?
Because they realize that reinventing the wheel for the sake of being 100% google-made is a pointless endeavor.
> It seems displeasing to have to work with 3rd party software in order to develop an Android app.
People work with third party apps all the time in the development of applications whether they are mobile, web or something else entirely.
>And this is not to say IntelliJ is a bad choice, but it would seem that they could rid away with any extraneous portions of the editor. It could also be optimized for Android development, unless that's what this "Android Studio" is.
How is it not optimized for android development. What, in your opinion would be an optimized version of the current IDE?
> Google has the resource to build their own text editor -- so why don't they do it?
Because they don't need their own text editor, they need an IDE; and just because they may have the resources to build their own IDE doesn't mean that that's the most cost effective mechanism available: "adopting" an existing IDE and sponsoring an Android-specialized spin, which is what they did with Android Studio, is a lot faster payoff and a lot more cost effective than starting from ground zero.
(Now, if they had a revolutionary idea for how to do a development environment differently, it would make sense to build it out in house. But that's a different issue than getting high-quality but basically conventional tooling available for Android development.)
Because an IDE isn't just a text editor. It takes a nontrivial amount of time and people to get a good IDE running. If you consider that a lot of this time is spent on features that have already been implemented somewhere else, it makes sense to leverage an existing project and then, on top of it, work on hard features that really have an impact on Android development - as is the case with the new Instant Run, for example.
Modern mobile development does not rely on text editors but IDEs and there is an huge difference between the twos.
Google has the resources to build a text editor, but an IDE ? that would take years and would still be unable to compete with XCode / Visual Studio.
So Google chose to take a great IDE, shower it in money and use it as the basis for their own tool.
That way, they automatically get everything Intellij already offers for Java : syntax colouring, smart refactoring, code flow analysis and so on and they can just focus on adapting the existing tools for Android and adding new ones (Lint, SysTrace, ... )
> It could also be optimized for Android development, unless that's what this "Android Studio" is.
That's pretty much what it is, I don't see how you could optimise it more for Android development.
They might care but I doubt they have any legal right to the word "studio". Lots of software has Studio in the name, many of which were released before VS.
> Apple Records didn't have a problem with Apple Computer until Apple Computer started selling music.
Untrue!
> In 1978, Apple Corps, the Beatles-founded holding company and owner of their record label, Apple Records, filed a lawsuit against Apple Computer for trademark infringement. The suit was settled in 1981 with an undisclosed amount being paid to Apple Corps. This amount was estimated to be US$50–250 million, but was later revealed to be $80,000. As a condition of the settlement, Apple Computer agreed not to enter the music business, and Apple Corps agreed not to enter the computer business.
Do any of those actually predate Visual Studio (i.e. 1997)? (Not suggesting Microsoft owns the word "Studio" but you're not actually answering the question.)
When Microsoft starting referring to its developer suite as Visual Studio it was using Studio as a catchall for all the development tools it had branded as "Visual" (starting with "Visual Basic" in the early 90s).
Which is clearly a different trademark despite the fact that they share one word that is key to describing the product's functionality. Might as well compare Burger King and Whataburger.
This reminds me of the Microsoft vs MikeRowSoft case [1], where Microsoft took legal action against a high schooler for a domain that was phonetically similar to their company name.
It's perfectly reasonable to think that if they ever released an Android IDE, either for the mobile OS or for actual androids, it might be called Android Studio.
Neither is really any more or less OK than the other. Whether or not either is OK is a matter for the USPTO, courts, lawyers, and private agreements to determine.
Android Studio as a development tool for building anthropomorphic robots might be OK whether Google liked it or not ;-)
Well, you're right, but Google explicitly has said that "X for Android" is ok because they allow it for apps on Google Play (whereas naming your app "Android X" is forbidden and can get you banned).
This could be awesome, if it works as advertised.