Monday, December 8, 2014

Google releases Android Studio 1.0, the first stable version of its IDE

android_studio_splashscreen

After two years of development, Google today released Android Studio 1.0, the first stable version of its Integrated Development Environment (IDE) aimed at Android developers. You can download it right now for Windows, Mac, and Linux from the Android Developer site.
Google first announced Android Studio, built on the popular IntelliJ IDEA Java IDE, at its I/O Developer conference in May 2013. The company’s pitch was very simple: This is the official Android IDE.
At the time, Google promised Android Studio would make developers “faster and more productive” and called it a replacement for Eclipse. In fact, the company has a list of migration steps just for Eclipse users.

What’s New

Given that Android Studio is only hitting 1.0 now, all the features are “new” to some extent. But Google does have specific features it wants to highlight (for a full overview, check out the Android Studio Basics page).
The First Run Setup Wizard helps you get started.

First off, we have the First Run Setup Wizard, which was amusingly absent from a few of the release candidate builds. This “getting started” wizard now installs the Android SDK you need, sets up your development environment settings, creates an optimized emulator for testing your app, and bundles a set of code templates.

Android Studio now includes new project templates and imports samples.
Speaking of templates, Android Studio includes wizards that let you start with new project templates or import Google code samples. If empty projects scare you or you’re having trouble getting started, you’ll like sample importing and the included templates.
The code editor leverages IntelliJ IDEA.
Android Studio leverages IntelliJ IDEA’s intelligent code editing capabilities. These include advanced code completion, refactoring, and code analysis.
Internationalize your apps with string translations.

Android Studio lets you manage string translations for all of your apps. You can easily extract and analyze all hard-coded strings in any project.


Preview your layouts across various screen sizes and versions.

Android Studio lets you both edit and preview your Android layouts across multiple screen sizes, languages, and even API versions. If you’re developing an app that will run on more than one Android release — and, given the current version landscape, you really should be — this will be very helpful.

Memory Monitor shows memory use of your app to aid performance tweaking.

Android Studio includes a performance analysis tool called Memory Monitor. It shows you the memory usage of your app over time so you can find ways to improve your app’s performance.

Easily add Google Cloud features to your app.


Finally, Android Studio enables an easy way to add Google Cloud Backends and Endpoints to your app, as well as Google Cloud Messaging. The latter is one of the features Google initially promised would come to the IDE. The company’s goal was (and still is) to make Android Studio the single hub in which Android developers can build new apps as well as refresh old ones.
Android Studio uses a Gradle-based build system that Google says “provides a lot of flexibility and extensibility, as well as the ability to build from within and outside of the IDE.” Key features include build variant support to better handle different build types (debug vs. release) or different versions of the same app (paid vs. free), multi-APKs handling through splits, multi-dex support, and dependency management for third-party libraries.
Google today also released version 1.0 of the Gradle plugin with a file format it considers to be stable. Since communication between Android Studio and the Gradle plugin is now stable as well, updating one will not require updating the other.

What’s Next

The current post-1.0 roadmap includes just three notable additions: Native SDK Manager, better refactoring support, and more Gradle support improvements. Google also says it plans to add features ranging from improved app testing and better support for game development. Other than that, Jamal Eason, product manager of Android, told VentureBeat the company has “nothing specific to share at this point” in regard to the future of Android Studio.
With the first stable release now out the door, the company will be using a schedule that is similar to the release channels for Google Chrome, meaning developers can choose how quickly they get the latest features for Android Studio.
Android Studio will receive updates on four different release channels (you can change between them in File => Settings => Updates): Canary, Dev, Beta, and Stable. Here is how they differ:
  • Canary channel: These builds are the bleeding edge, released about weekly. While they do get tested, they are still subject to bugs, as Google wants developers to see what’s new as soon as possible.
  • Dev channel: These builds are hand-picked older Canary builds that survived the test of time. This channel is updated biweekly or monthly.
  • Beta channel: Although Android Studio has been considered preview-quality for much of its existence, it did have a handful of beta releases, starting with 0.8.14 all the way to the most recent release candidates.
  • Stable channel: Version 1.0 was released today, and other stable milestones will follow.
Eason told VentureBeat that Google has “no additional guidance on release channel timing,” meaning you shouldn’t expect beta or stable releases on a specific schedule. “We will continue to use all the channels and have the most frequent release builds on canary channel,” he added.
That being said, we wouldn’t recommended anything but the stable channel if you’re using Android Studio for production. As we wait for the next stable release, Google is asking developers for feedback on how they work and what capabilities they would like to have when developing for Android (a five-minute survey can be taken via Google Docs).
Android Studio is still a far cry from Microsoft’s Visual Studio, but it’s easy to see how Google could build it out into a competitor. Given the name and direction, however, Google seems perfectly happy with keeping the IDE focused on just development for its mobile operating system.

Wednesday, December 3, 2014

Gmail now lets you edit Microsoft Office documents from your inbox

Import attached files to Google's Docs formats

 

Google has today added a new feature to Gmail inboxes that allows users to edit Microsoft Office documents sent as email attachments. Click the new "edit" option on an Office file attachment and Gmail will convert the file to the relevant Google format, saving it in Google Drive to allow for continuous editing and sharing. Google has also increased the amount of Office file types it can import to Docs to make this process easier — the list now includes 15 less-used Office formats including presentation show files .pps and .ppsx.
edit-from-gmail-gif
If you need to edit the Office attachments without changing the file type, but don't have the Microsoft suite on your desktop, Google suggests you use its Office Editing Chrome extension. The extension, last updated at the end of November, allows users to alter Office files and save them in their original format from their Chrome browser.


Tuesday, December 2, 2014

The upcoming Jack & Jill compilers in Android

Android has gone through quite a few changes during its short 6 years of life. The Android that drives most of the world's smartphones of today would be almost unrecognizable to what was launched in late 2008. We've seen massive visual changes, expansion to almost every conceivable form factor, and a completely fleshed-out content ecosystem for multimedia and apps. As the operating system matured, some elements have successfully grown with it, and others have become dead weight. Naturally, progress calls for the replacement of those pieces that haven't scaled well. We've seen an excellent example of this when ART came to replace Dalvik as the standard Android runtime. With the release of Lollipop, a similar project emerged that promises to replace a part of the existing app development toolchain with a pair of new compilers called Jack and Jill.
Presumably named after the nursery rhyme characters, Jack and Jill will ultimately replace the javac and dex compilers used by most app developers today. Google hasn't published its plans for the new project, but it appears to be a big step towards cutting down on compile times, but it may also be angled towards escaping some of the politics surrounding Java and massively improving the entire development experience.

How It Works

In an article on Saikoa's blog (this is the developer of ProGuard and DexGuard), Eric Lafortune explains the roles Jack and Jill will play in the toolchain and the inputs and outputs of each compiler. The current method is effectively a 2-step process that begins with javac converting source code into standard Java bytecode, then the dex compiler is responsible for turning that into Dalvik bytecode so it can be run on Android. If there are additional pre-compiled libraries, they go straight into the dex compiler. In between these steps, tools like ProGuard may also be used to optimize and obfuscate the output.
javac_proguard_dex
Image Credit: Saikoa
The new process is similar, but there are some important distinctions. To begin with, the Jack compiler converts raw code directly to .dex format, removing Java bytecode from the process entirely. In the event that a Java bytecode library is included, the Jill compiler is called to convert it to an intermediate format called jayce that will be passed to the Jack compiler along with the source code for the app. For the most part, Jill will only have to be called once when a library is added or updated, since the output can be cached and reused for future compilations. Additionally, ProGuard support has been baked directly into the Jack compiler, meaning it can operate with the same configuration files and produce the same output without requiring a separate step. There is still room for external tools to step in, but they will have to target the jayce or dex formats instead of Java bytecode.
jack_jill
Image Credit: Saikoa

Where Things Stand

Google hasn't made an official statement or published any documentation about the new project, so we're left with a few mysteries about what it's meant to achieve and how far along it is. The only place we have to look is AOSP where repositories for Jack and Jill have been open sourced. The first code submission for Jill was made on Feb 6, 2014, and Jack followed about 6 weeks later on Mar 19, 2014, but development obviously began much earlier. So far, the project could probably be considered experimental, particularly since the repositories are still organized so that the code resides exclusively in development branches, rather than the master branches where it will eventually end up.
If you're interested in trying out the Jack and Jill compilers, they are already available in version 21.1 of the Android SDK, and the Gradle plugin (as of v0.14.0) supports a new flag called useJack. It's as simple as adding a single line to the build script for your app (not the project's build script). Just add useJack true to the defaultConfig section and recompile. I'm still getting about the same performance (or worse) with Jack than I was with the javac/dex recipe, but that will probably change in the future.
usejack
Since the compiler is distributed with the SDK rather than versions of Android, the updates will roll out on a fairly steady schedule. It's impossible to guess when we'll see Jack and Jill replace javac and dex as the default compilers; but they already seem mostly stable, so we see the switch before too long.

What Is There To Gain

Google's reasons for creating two new compilers are a bit mysterious, but there are a few plausible explanations. The first and most obvious is to combat the slow compile times developers often complain about. Efforts have been made to optimize the current process, but there are only so many things that can be done. Ultimately, almost every time an app is compiled most of the code will go through two fairly complicated procedures before the final output is ready. By removing the conversion to Java bytecode, at least one largely unnecessary step can be eliminated.
Bigger advantages may also come from total ownership over the toolchain. The use of javac means Android developers are essentially reliant on implementations controlled by other groups like Oracle, Eclipse, or the OpenJDK project. Google is free to fork any of these, but at a certain point the design, architecture, and even politics will always stand in the way of rapid iteration. With a brand new compiler focused directly at Android, it's possible to add features, improve output, and directly manage the outcome without worrying about how each change affects the larger ecosystem built around Java. There are certainly increased costs associated with taking over development of the compiler, but it may be worth it in the long run.
Another potentially significant piece of this puzzle may relate to the ongoing feud with Oracle. Despite a few strong legal wins for Google, the decision to use Java as a primary development language has led the two giants down a road of lawsuits that almost rivals the inane bickering between Apple and Samsung. Complaints have been brought up regarding patents, misuse, and even if method names can be copyrighted. (Eyeroll.) A pair of new compilers certainly won't be enough to end the territorial squabbling, but removing Java bytecode almost entirely from the equation would be a good start.
While this may be wishful thinking, Google may have more ambitious goals lined up for this project. One of the most distinct additions to Jack is ANTLR v3.4, a very powerful tool for generating language parsers. This may prove to be the first step towards language-level customizations, support for additional languages, or very advanced language inlining. For example, it may soon be possible write raw SQLite queries in the middle of code, or write an app in C# or Python without the use of special libraries (assuming the runtime supports all of the necessary features).

Conclusion

Much like ART, Google is undertaking a project that could have lasting effects on the future of Android. The potential may be much greater than is immediately obvious. Jack and Jill may turn out to be just a way to reduce compile time for developers and put some distance between Google and Oracle, but as the project matures, it might just lead to an evolution in the way developers build the apps we all rely on.


Source: Saikoa blog

Wednesday, October 15, 2014

Android - 5.0 Lollipop