Rabu, 30 Desember 2015

Get ready for Javascript “Promises” with Google and Udacity

Sarah Clark, Program Manager, Google Developer Training



Front-end web developers face challenges when using common “asynchronous” requests. These requests, such as fetching a URL or reading a file, often lead to complicated code, especially when performing multiple actions in a row. How can we make this easier for developers?



Javascript Promises are a new tool that simplifies asynchronous code, converting a tangle of callbacks and event handlers into simple, straightforward code such as: fetch(url).then(decodeJSON).then(addToPage)...



Promises are used by many new web standards, including Service Worker, the Fetch API, Quota Management, Font Load Events,Web MIDI, and Streams.






We’ve just opened up a online course on Promises, built in collaboration with Udacity. This brief course, which you can finish in about a day, walks you through building an “Exoplanet Explorer” app that reads and displays live data using Promises. You’ll also learn to use the Fetch API and finally kiss XMLHttpRequest goodbye!



This short course is a prerequisite for most of the Senior Web Developer Nanodegree. Whether you are in the paid Nanodegree program or taking the course for free, won’t you come learn to make your code simpler and more reliable today?

Jumat, 18 Desember 2015

Google Play Services 8.4 SDK is available

Posted by Laurence Moroney, Developer Advocate



We’re delighted to announce the availability of Google Play services 8.4. There’s a lot of new information to share with you about what’s available to you in this release.







Custom Email App Invites



App Invites is a technology that enables your users to share apps with people they know. In Google Play services 8.4 we’ve updated this to make it easier for them to share via email. Before this you could create a custom email that contained user defined text and an image, but now we’re allowing you to add content from the app directly into the message. It allows you to fully define the email body using HTML, and set the email subject line. So, for example, if you have a favorite cooking app that you want to share with your friends, your invite to use the app can include a favorite recipe from the app. They get the immediate benefit of being able to access the desired content, giving them a more informed choice about whether or not they decide to install the app to get richer and more content. Check out the App Invites sample on GitHub here.



Predicting User spend and churn in games



The Play Games Analytics developer experience is designed to enable game developers to better understand, manage, and optimize game experiences throughout the player lifecycle. With this in mind, we’ve extended the Player Stats API to help you better understand your players behavior, and based on this, entice them to stay in your game.




The churn prediction method will return data on the probability that the player will churn, i.e., stop playing the game. You can create content in response to this to entice them to stay in your game.



Additionally, the spend prediction method will return the probability that the player will spend something in the game. It’s up to you how to handle this data, but -- for example -- if there’s a low probability that the player will spend something, you could provide discounted in-app purchases or show ads.



Fused Location Provider Updates



The Fused Location Provider (FLP) in Google Play services provides location to your apps using a number of sensors, including GPS, WiFi and Cell Towers.



When desiring to save battery power, and using coarse updates, the FLP doesn’t use Global Positioning Services (GPS), and instead uses WiFi and Cell tower signals. In Google Play services 8.4, we have greatly improved how the FLP detects location from cell towers. Prior to this, we would get the location information relative to only the primary cell tower. Now, the FLP takes the primary tower and other towers nearby to provide a more accurate location. We’ve also improved location detection from WiFi access points, particularly in areas where GPS is not available -- such as indoors.



Maps API Improvements



Have you ever wished you could easily handle a tap on a suburb without having to add another layer on the map to intercept the taps? We’ve added an onClickListener for polygons, so you can easily add transparent polygons and intercept the taps directly. We’ve also added on click listeners to polylines and ground overlays.



Here’s how you can use a listener to detect a click on a polygon:


 map.setOnPolygonClickListener(new GoogleMap.OnPolygonClickListener() {  
@Override
public void onPolygonClick(Polygon polygon) {
...
}
});


Info windows now also offer an OnInfoWindowCloseListener and an OnInfoWindowLongClickListener. The on close listener is particularly useful if you wish to zoom back out on the map after the user has looked at the detail associated with a particular marker.


 mMap.setOnInfoWindowCloseListener(new GoogleMap.OnInfoWindowCloseListener() {...});  

 mMap.setOnInfoWindowLongClickListener(new GoogleMap.OnInfoWindowLongClickListener() {...});  


For more details, and an example that uses these, see the ApiDemos sample on GitHub and check out the historical changes to this sample, so you can see how the new APIs work. Also see the Release Notes.



Support for Aztec bar codes



In Google Play services 7.8, we launched Vision APIs that supported face and barcode detection. One bar code format we didn’t support was Aztec bar codes, so with Google Play services 8.4 we’ve now added support for these.



Applications using BarcodeDetector in its default configuration (no barcode format restrictions) will automatically start decoding AZTEC codes.



Background Beacon Scanning



With Google Play services 8.4, the Nearby Messages API now supports background scanning for Eddystone, the open beacon format from Google. With this update, your app can be woken up when a BLE beacon is sighted. Back in July, Google Play Services 7.8 introduced the Nearby Messages API with a simple publish-subscribe interface. In the case of beacons, developers publish content by adding attachments to beacon records using Proximity Beacon API. These attachments are served back to your app when Nearby sights a beacon of interest.




New methods that we’ve added include a subscribe method for background beacon subscriptions where BLE scans are triggered at screen-on events; an associated unsubscribe event; and the ability to handle intents that you get when the Nearby API calls back during a background subscription.



Fitness Platform HistoryApi Improvements



We now support consistent step counts across the Google Fit app, other fitness apps and Android Wear watch faces with the HistoryApi.readDailyTotal() method. Please see the following documentation for more detail:
https://developers.google.com/fit/android/history#read_daily_total_data?utm_campaign=play services_series_launch_121815&utm_source=anddev&utm_medium=blog



We also have a new HistoryApi.updateData() method. This method allows you to update data in one API call without having to delete and insert with two calls.



Place Picker Autocomplete Widget



Today we are announcing the mobile autocomplete widget, the latest addition to our existing set of programmatic autocomplete features on Android and iOS, as well as the addition of Autocomplete to our place picker widget. Autocomplete functionality assists users by automatically completing the name and address of a place as they type. Widgets make it even easier for developers to add autocomplete functionality to their application with just a small amount of code. Learn more about this at this blog post.



















Kamis, 17 Desember 2015

The Learning Continues! New lessons for Advanced Android course

Posted by Joanna Smith, Developer Advocate



Magic moments happen when your app does something very useful with minimal effort from your users -- like figuring out their location for them automatically. The new Places lesson in the Advanced Android App Development course teaches you how to add a Place Picker to your app so that users can pick a nearby location without having to type anything.



The Advanced Android App Development course, built by Udacity in conjunction with Google, is a follow-up course to Developing Android apps. The advanced course is for Android Developers who are ready to learn how to polish, productionize and publish their app, and even distribute it through Google Play.







Updates to the course also include an explanation of the new GCM Receiver, as well as an entirely new lesson on publishing your app, which explains how to build and sign an APK so you you can distribute your app on Google Play.




After all, why build an app if you can’t get it to your users?


Get started now, because it's going to be awesome!

Rabu, 16 Desember 2015

Invitation: Your Ultimate 31-Course Holiday Banquet

Posted by Shanea King-Roberson, Program Manager



The Holidays. Food for the body. Food for the mind. Google and Udacity offer you 31 courses that will make your mouth water and your mind dance. Savor one or several of our 31 self-paced online training courses to indulge your curiosity, expand your knowledge, and hone new skills. Choose from Android, Web, Entrepreneurship, or Cloud and Backend tracks. Are you ready?





Android



More and more people around the world are embracing mobile at an increasing pace, whether on their phones, in their cars, at home, and around their wrists. Learn to build apps for them!






Web



Refine your web development skills for mobile. Create fast, fluid user experiences. Deploy for all desktop and mobile devices. Streamline checkout and payment. Learn how to build beautiful, performant, responsive applications for the world's largest platform.






Cloud and Backend



Does your app need to support more users? (Congratulations!) Do you want to move data handling for an existing app from the device to the cloud? Learn how to take advantage of public cloud infrastructure to support millions of users and terabytes of data.






Entrepreneurship



Start the year with a new start up. That says it all. Take these courses to learn how to do it successfully.





And that’s it. 31 courses that will catapult your skills and make 2016 your best year yet!
Happy Holidays!


Senin, 14 Desember 2015

Leveraging product flavors in Android Studio for hermetic testing

Posted by Jose Alcérreca, Developer Programs Engineer and Wojtek Kaliciński, Developer Advocate







During our recent talk at Android Dev Summit, we discuss the state of testing on Android on the example of a simple Notes application that we created as part of our testing codelab. In one section of the talk, we discuss the problem of test flakiness and introduce a simple solution for setting up a hermetic testing environment.



Combatting flaky tests



UI tests with frameworks like Espresso or UI Automator can easily get flaky if the application has external dependencies that can sometimes fail or take long to respond. In short, flaky tests are tests that are not reliable (they can pass or fail randomly) which defeats the whole purpose of having tests in the first place.



A common solution to this problem is hermetic testing or, in other words, making sure that your tests are isolated from dependencies. Using fake implementations or fake servers that just return predefined data is a common way of dealing with this problem. Here are some good examples:




  • Network calls can be made via a fake API client or fake server that immediately returns data from files stored on disk instead of hitting the network. This bypasses the network's latency and flakiness as well as any errors originating on the real server.

  • Interactions with low-level framework APIs (especially those for accessing hardware, like camera or storage) can be passed through an intermediate interface. A fake implementation of this interface could return immediately, providing a reference to preloaded data, such as an image, without relying on the hardware.

  • Any sensors can be replaced with fakes too: GPS, microphone, accelerometer etc., giving you a chance to test on data that would be difficult to provide for the test in real life, like a preset location or a set of inputs simulating a gesture.



Dependency Injection (DI) is a software design pattern that facilitates testing, reusing modules and making them interchangeable. DI frameworks can help you deal with the boilerplate associated with this pattern but it can take a considerable amount of time to set them up and understand how they work. Before you are ready to commit to one of those frameworks for your app, you might want to explore an easier way, especially if your project requirements are simple.



Managing dependencies with product flavors



Product flavors is a powerful feature of Android Studio and our Android Gradle plugin that lets you swap Java classes at compile time and doesn't require additional libraries. Some typical examples of flavor dimensions are:





  • free/paid flavors to generate two different APKs that will be released on your distribution channels

  • stable/experimental to keep experiments in a different source set and generate beta versions quickly



We can leverage the same mechanism to create two separate versions of our app to help with hermetic testing:



  • prod - uses real implementation of services and components, using real data and resources

  • mock - for a version that contains fake implementations of dependencies that are hard to test



The procedure is very simple:



  1. Create the flavors in your app/build.gradle file.
     android {  
    productFlavors {
    mock {
    applicationIdSuffix = ".mock"
    }
    prod
    }
    }

  2. Create two directories: app/src/prod and app/src/mock

  3. Create the class that you want to use for production code in the prod/java folder or move it from main/java. Make sure the main/java folder does not contain this class.
  4. Create the same class (with the exact same class and file name) in the mock/java folder, but providing a different (fake) implementation that will be used for tests.
  5. In the Build Variants window in Android Studio, choose the variant that you want to install or run tests against. A variant is the combination of a flavor and a build type.


Note: In gradle, the task names change when you add flavors. Instead of installDebug, you will now have to choose installProdDebug or installMockDebug.



Running your tests



With the prod and mock flavors configured and your mock implementation in place, you can now use the following gradle tasks to choose how your tests should run:




  • connectedMockDebugAndroidTest will merge the androidTest and androidTestMock directories and run every test found in the resulting source set. As these tests are run in a hermetic way, they will be faster and less flaky. This is ideal for a pre-submit check.

  • connectedProdDebugAndroidTest will use the real APIs and sensors so they might fail from time to time. If you have a Continuous Integration system, this task could be executed every night or used manually as a acceptance end-to-end test. Note that this task will run the tests in androidTest even if androidTestProd doesn't exist.



You can refer to our Android Testing Codelab to see how we used this method to provide different Injection class implementations, the one in prod providing real data and the other (mock) serving fake dependencies that use fake data for isolated test execution.



When you’re happy with your hermetic setup, you might want to give more flexibility to your build process and add even more dimensions to be able to interchange different components in your app. While the method discussed above is suitable for simple projects, for more complex situations it would be much better to invest some time to learn about and add a Dependency Injection framework to your project.






Jumat, 11 Desember 2015

One tap sign-up and automatic sign-in without password entry using Smart Lock

Posted Steven Soneff, Product Manager, Google Identity



More than 30 percent of users signing in to the Netflix app on Android no longer have to enter a password thanks to Google’s Smart Lock for Passwords. Learn more



It’s been six months since the launch of Smart Lock for Passwords and we are thrilled with the impact it has made in getting users signed back in to many of their favorite apps. Million of users have been seamlessly signed in using saved accounts for over 40 major apps when going from one Android device to another or from Chrome to Android and vice versa. This first wave of developers have realized that removing the friction of sign-in increases user re-engagement, monetization opportunities, and cross-device analytics, improving the value and experience of their users.



The New York Times has seen 80 percent of their new sign-in events assisted by Smart Lock. Meanwhile, the Netflix customer support team found over a 20 percent reduction in support cases related to account recovery for their Android user base. Users strongly choose to stay signed in across their devices with over 60 percent opt-in to save sign-in info for major Smart Lock-enabled apps. And many of these developers were able to realize these gains with less than a day’s work by making only client-side changes to their app. To learn more about Smart Lock for Passwords, visit our developer site.



What’s New




With the latest release of Google Play services, we’ve made some enhancements to the Smart Lock for Passwords API to help you sign up new users or sign existing users in more quickly. Using the new method to retreive sign-in "hints", your users will see a dialog with a list of email addresses that they can select in a single tap:








This new experience is particularly important with Android Marshmallow’s runtime permissions model. To simplify and improve the user experience, this dialog doesn’t require device permissions and includes any email addresses that the user has saved with Smart Lock, not just the accounts on the device. This means that you can improve your sign-in and sign-up flows so that most of your users never need to type their email address. Apps using this dialog have seen nearly three-quarters of users select an entry shown, improving sign-up rates.



Next, after the user has tapped and shared their email address, with some server-side support, a sophisticated app can fully tailor the sign-in flow. By using the email address, you can check your database to see if a user has already registered for an account. You can then intelligently render either the sign-in or sign-up screens with the user’s email address, name and profile photo pre-filled.



Skipping the Password Altogether



It’s possible to do even better: if the user chooses a Google account from the dialog, an OpenID Connect ID Token is provided. This can save your app from having to verify email addresses for new accounts or skip the password altogether for returning users. ID tokens are also used by Google Sign-In to authenticate in place of a password, and are a strong assertion from Google that the owner of the given email address is present. If users on your site recover their passwords by email, then an ID token from Google is giving you the same assertion that the user owns the email address and is signed in to this device with that email address. You can also consider presence of ID token in addition to the password a signal to prevent password cracking and abuse.



We’ve found that the majority of users on Android use the email address that’s signed in on their device as their account for third-party apps, so this means seamlessly signing in most of your returning users, or creating a new account with one tap!



Code Samples and User Flow



Here’s a recap of how to streamline your app’s sign-in flow:






When your app starts, request stored Smart Lock credentials, and go straight to the user’s content when possible. Create a request for password or Google credentials, then listen for a callback with the results. Sign in immediately if stored user credentials (username / password, ID token, etc.) is available.


 CredentialRequest request = new CredentialRequest.Builder()  
.setSupportsPasswordLogin(true)
.setAccountTypes(IdentityProviders.GOOGLE) // you can add other identity providers, too
.build();
Auth.CredentialsApi.request(mCredentialsApiClient, request).setResultCallback(
new ResultCallback<CredentialRequestResult>() {
public void onResult(CredentialRequestResult result) {
if (result.getStatus().isSuccess()) {
handleCredential(result.getCredential()) // sign in automatically!


When the user wants or needs to sign in with their email address, show the picker to help them input it. Create a request for hints, pass control to the system to display UI, and handle the result when the user selects an entry.


 HintRequest hintRequest = new HintRequest.Builder()  
.setEmailAddressIdentifierSupported(true)
.setAccountTypes(IdentityProviders.GOOGLE)
.build();
PendingIntent intent = Auth.CredentialsApi.getHintPickerIntent(mCredentialsApiClient,
hintRequest);
startIntentSenderForResult(intent.getIntentSender(), RC_HINT, null, 0, 0, 0);
...
onActivityResult(int requestCode, int resultCode, Intent data) {
switch (requestCode) {
case RC_HINT:
if (resultCode == RESULT_OK) {
Credential hint = data.getParcelableExtra(Credential.EXTRA_KEY);
handleCredential(hint);



The result from the hint request will contain the user’s selected identifier and an ID token if it is a Google account on the device. If you use the ID token, you must send and verify it on your server for security. Note that this token will also include a claim if the email address is verified, so you can skip any email verification step. If no token is present, or you can’t do server-side validation, just pre-fill the email field for the user.


 handleCredential(Credential credential) {  
if (!credential.getIdTokens().isEmpty()) {
credential.getIdTokens().get(0).getIdToken(); // send the ID token string to your server
} else {
// otherwise, try fill the sign-in form fields and submit if password is available
mEmailField.setText(credential.getId());
mPasswordField.setText(credential.getPassword());


On your server, after validating the ID token, use it to create an account or sign the user in without need for their password. Google provides libraries to do token validation, or you can use an open-source implementation. The ID token contains the user’s email address, and you can look it up in your database to determine whether an account needs to be created.


 GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)  
.setIssuer("https://accounts.google.com")
.setAudience(Arrays.asList(String.format("android://%s@%s",
SHA512_HASH, PACKAGE_NAME)))
.build();
...
GoogleIdToken idToken = verifier.verify(idTokenString);
if (idToken == null) {
Log.w(TAG, "ID Token Verification Failed, check the README for instructions.");
return;
}
GoogleIdToken.Payload payload = idToken.getPayload();
Log.d(TAG, "IdToken:Email:" + payload.getEmail());
Log.d(TAG, "IdToken:EmailVerified:" + payload.getEmailVerified());
// based on the email address, determine whether you need to create account
// or just sign user in


Then save the user’s email address credential “hint” in Smart Lock for automatic sign-in next time. Simply call the Credentials API save method with the hint and either set the user-entered password, or set the account type if you logged the user in with an ID token.


 Credential credential = new Credential.Builder(hint)  
// if you signed in with ID token,
// set account type to the URL for your app (instead of a password field)
//.setAccountType("https://yourdomain.com")
.setPassword(password)
.build();
Auth.CredentialsApi.save(mCredentialsApiClient, credential).setResultCallback(
new ResolvingResultCallbacks<Status>(this, RC_SAVE) {


Learn More



To learn more about the basics of a Smart Lock API integration, check out our code lab for a step-by-step guide. We’re excited to make authentication without passwords possible via Smart Lock and are looking forward to a world where not only credentials can be managed more effectively, but apps can get their users signed in and up quickly and securely without the friction of typing usernames and passwords. We’d love to hear your feedback or questions!




Kamis, 10 Desember 2015

Android Studio 2.0 Preview: Android Emulator


Posted by, Jamal Eason, Product Manager, Android




An early preview of the new Android Emulator is now available to try out. As a part of Android Studio 2.0, the latest version of the Android Emulator can help you test your app on a wide range of screens size and configurations beyond the physical Android hardware you use to test.Moreover, using the official Android emulator enables you to test with latest Android versions. Building on this foundation, the top two benefits of new Android emulator are:





  • Speed & Performance: When emulating the latest Android 6.0 release (Marshmallow), we now support Symmetric Multi-Processing and have made significant I/O improvements in both the emulator and ADB. This means you will have faster performance when you are testing your app.




  • Usability & User Interface: The new Android Emulator includes a brand new user interface to make the emulator easy to use. You no longer have to rely on command-line parameters to use the Android emulator. Common tasks and emulator features are now just a mouse click or a keyboard shortcut away.


We previewed the user interface at the Android Dev Summit. You can try it out today along with the new version of ADB for faster APK installation and file transfers to the emulator. Check out the video for a demonstration of the new Android Emulator.







Android Dev Summit 2015: Emulator Demo


We are seeking early feedback to continue to deliver the experience and features that will make you more productive.



Performance Improvements


CPU Performance



Android Studio now uses CPU acceleration on x86 emulator system images by default. Combined with new Symmetric Multi-Processor (SMP) support in Android 6.0 Marshmallow system images, the Android emulators can perform even faster than many physical Android devices. Multi-core support not only makes your apps and the emulator run faster but it provides the added advantage of speeding up common developer tasks such as installing APKs. Also, with SMP you can test apps that specifically target multi-processor Android devices.



Faster ADB



In addition to faster CPU speeds in the emulator, there are a number of under-the-hood improvements that will make the experience faster. One of the bottlenecks in the development process that we worked on is the speed of pushing data between Android Studio and your device using ADB (Android Debug Bridge). When you use Android 6.0 Marshmallow and higher system images with the new Android Emulator, you can now push files across ADB up to five times faster than a real device. This will help you if you push large APK or files during your app development cycle.




User Interface



Toolbar



The new interface exposes some of the most common emulator actions in a new toolbar and control panel instead of solely relying on command line options. For the preview, the Android Emulator toolbar enables actions, such as volume control, screen rotation, and screen-shots of the emulator window.





Window Zooming & Scaling


Now you can resize your window simply by dragging a corner. You can also zoom and scroll to get a closer look at a portion of your screen.












Left: Zooming
Right: Window Scaling



Drag & Drop


With the new emulator, you can not only drag and drop APKs for quick installation, but you can also drag and drop any file to your emulator’s internal SD card to help in testing.






Drag and Drop Files


Extended UI Controls


In the extended controls window, additional options help you validate and test features in your app. As shown below, you can initiate a range of emulator actions such as making a virtual call, sending a virtual SMS, or controlling the power level of the emulator. You can additionally send a single GPS location point to the emulator or play back a custom set of KML or GPX points as well.






Phone Controls




Battery Controls

We are continuing to add more functionality and we will keep you up to date as we add more features.



What's Next & Setup


This is just the beginning of developments on the Android Emulator, so expect more features such as support more APIs levels, and adding more sensors with future versions of Android Studio. The new emulator along with Android Studio are available today on the Android Studio canary channel and tools preview channel.



Click here for details on how to setup the preview of the new Android Emulator.


We appreciate your feedback. Connect with us, the Android Studio development team, on Google+.



Rabu, 09 Desember 2015

Android Developer Story: SGN game ‘Cookie Jam’ increases user conversions with Store Listing Experiments

Posted by Lily Sheringham, Google Play team



Founded in 2010, SGN is a Los Angeles based mobile game developer with hit titles including Cookie Jam, Panda Pop, Juice Jam and Book of Life: Sugar Smash. They now have more than 200 employees and are one of the fastest growing cross-platform gaming developers.



SGN used Store Listing experiments to test multiple variants across their portfolio of games. For Cookie Jam, they saw an 8 percent increase in conversions simply by changing the background color of their app icon. They also saw increased installs following tests with the Panda Pop app icon and by changing the character in their Book of Life: Sugar Smash app icon.



Watch Josh Yguado, Co-founder and President of SGN, and Matthew Casertano, SVP of Game Operations, talk about how using Store Listing Experiments helped SGN improve their ROI, conversion rates and gamer retention.







Find out more about how to run tests on your Store Listing to increase installs and achieve success with the new guide to ‘Secrets to App Success on Google Play’.





Rabu, 02 Desember 2015

API Updates for Sign-In with Google

Posted by Laurence Moroney



With the release of Google Play services 8.3, we’ve made a lot of improvements to Sign-In with Google. In the first blog post of this ongoing series, we discussed the user interface improvements. Today, we will look further into the changes to the API to make building apps that Sign-In with Google easier than ever before.



Changes to basic sign in flow


When building apps that sign in with Google, you’ll notice that there are a lot of changes to make your code easier to understand and maintain.



Prior to this release, if you built an app that used Sign-In with Google, you would build one that attempted to connect to a GoogleApiClient. At this point the user was presented with an account picker and/or a permissions dialog, both of which would trigger a connection failure. You would have to handle these connection failures in order to sign in. Once the GoogleApiClient connected, then the user was considered to be signed in and the permissions could be granted. The process is documented in a CodeLab here.



Now, your code can be greatly simplified.



The process of signing in and connecting the GoogleApiClient are handled separately. Signing in is achieved with a GoogleSignInOptions object, on which you specify the parameters of the sign in, such as scopes that you desire. Here’s a code example:



 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  
.requestEmail()
.build();


Once you have a GoogleSignInOptions object, you can use it to configure the GoogleApiClient:



Here’s where your code will diverge greatly in the new API. Now, if you want to connect with a Google Account, instead of handling errors on the GoogleApiClient, you’ll instead use an intent that is initialized using the client.



Intent signInIntent = Auth.GoogleSignInApi.getSignInIntent(mGoogleApiClient);
startActivityForResult(signInIntent, RC_SIGN_IN);


Starting the intent will give you the account picker, and the scopes permission dialog if your GoogleSignInOptions requested anything other than basic scope. Once the user has finished interacting with the dialogs, an OnActivityResult callback will fire, and it will contain the requisite sign-in information.




 @Override  
public void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
// Result returned from launching the Intent from GoogleSignInApi.getSignInIntent(...);
if (requestCode == RC_SIGN_IN) {
GoogleSignInResult result = Auth.GoogleSignInApi.getSignInResultFromIntent(data);
handleSignInResult(result);
}
}



You can learn more about this code in the Integrating Google Sign-In quickstart, or by looking at the sample code.



Silent Sign-In


To further reduce friction for users in a multi-device world, the API supports silent sign in. In this case, if your user has given authorization to the app on a different device, the details will follow their account, and they don’t need to re-give them on future devices that they sign into, unless they deauthorize. An existing sign-in is also cached and available synchronously on the current device is available.



Using it is as simple as calling the silentSignIn method on the API.



OptionalPendingResult opr = 
Auth.GoogleSignInApi.silentSignIn(mGoogleApiClient);


Then, you can check the isDone() method on the pending result -- and if it returns true, the user is signed in, and you can get their status from the PendingResult. If it isn’t then you have to wait for a callback with the SignInResult




 if (pendingResult.isDone()) {  
doStuffWith(pendingResult.get());
} else {
// There's no immediate result ready, displays some progress indicator and waits for the
// async callback.
showProgressIndicator();
pendingResult.setResultCallback(new ResultCallback<GoogleSignInResult>() {
@Override
public void onResult(@NonNull GoogleSignInResult result) {
updateButtonsAndStatusFromSignInResult(result);
hideProgressIndicator();
}
});
}


Customizing the Sign-In Button


When building apps that Sign-In with Google, we provide a SignInButton object that has the Google branding, and which looks like this:






You can customize this button with a number of properties and constants that are documented in the API here.



The branding guidelines are available here, and they include versions of the buttons in PNG, SVG, EPS and other formats in many resolutions, including all the different states of the button. These files may be used for localization of the button, and if you need to match the style of the button to your app, guidelines are provided.



This only deals with the Android side of your app. You’ll likely have a server back end, and you may want to use the credentials on that securely.



In the next blog post, we’ll discuss how to use Sign-In with Google in server-side scenarios, including how to securely pass your credentials to your own server, and how to use Google back-end services, such as Google Drive, with the permission and credentials from users.

Senin, 23 November 2015

Android Studio 2.0 Preview

Posted by, Jamal Eason, Product Manager, Android



One the most requested features we receive is to make app builds and deployment faster in Android Studio. Today at the Android Developer Summit, we’re announcing a preview of Android Studio 2.0 featuring Instant Run that will dramatically improve your development workflow. With Android Studio 2.0, we are also including a preview of a new GPU Profiler.



All these updates are available now in the canary release channel, so we can get your feedback. 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.






New Features in Android Studio 2.0



Instant Run: Faster Build & Deploy


Android Studio’s instant run feature allows you to to quickly see your changes running on your device or emulator.




Getting started is easy. If you create a new project with Android Studio 2.0 then your projects are already setup. If you have a pre-existing app open Settings/Preferences, the go to Build, Execution, Deployment → Instant Run. Click on Enable Instant Run... This will ensure you have the correct gradle plugin for your project to work with Instant Run.



Enable Instant Run for Android Studio projects



Select Run as normal and Android Studio will perform normal compilation, packaging and install steps and run your app on your device or emulator. After you make edits to your source code or resources, pressing Run again will deploy your changes directly into the running app.



New Run & Stop Actions in Android Studio for Instant Run


For a more detailed guide setup and try Instant Run, click here.


GPU Profiler


Profiling your OpenGL ES Android code is now even easier with the GPU Profiler in Android Studio. The tool is in early preview, but is very powerful and not only shows details about the GL State and Commands, you can record entire sessions and walk through the GL Framebuffer and Textures as your app is running OpenGL ES Code.



Android Studio GPU Profiler


To get started, first download the GPU Debugging Tools package from the Android Studio SDK Manager.
Click here for more details about the GPU Profiler tool and how to set up your Android app project for profiling.


What's Next


This is just a taste of some of the bigger updates in this latest release of Android Studio. We'll be going through the full release in more detail at the Android Developer Summit (livestreamed on Monday and Tuesday). Over the next few weeks, we'll be showing how to take advantage of even more features in Android Studio 2.0, so be sure to check back in.


If you're interested in more Android deep technical content, we will be streaming over 16 hours of content from the inaugural Android Developer Summit over the next two days, and together with Codelabs, all of this content will be available online after the Summit concludes.


Android Studio 2.0 is available today on the Android Studio canary channel. Let us know what you think of these new features by connecting with the Android Studio development team on Google+.


Kamis, 19 November 2015

Android Studio 1.5








Posted by, Jamal Eason, Product Manager, Android



Android Studio 1.5 is now available in the stable release channel. The latest release is focused on delivering more stability, with most of the enhancements being made under the hood (along with addressing several bugs).











Some of the specific bug fixes, include the ability to use short names when code-completing custom views.





In addition to the stability improvements and bug fixes, we’ve added a new feature to the memory profiler. It can now assist you in detecting some of the most commonly known causes of leaked activities.





There are also several new lint checks. Here's one below which warns you if you are attempting to override resources referenced from the manifest.





If you’re already using Android Studio, you can check for updates from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). For new users, you can learn more about Android Studio, or download the stable version from the Android Studio site.



As always, we welcome your feedback on how we can help you. You can also connect with the Android developer tools team via Google+. And don’t worry about what’s in the box from the video. It’s nothing. Really. Forget I mentioned it.


Android Developer Story: Gifted Mom reaches more mothers across Africa with Android

Posted by Lily Sheringham, Google Play team


Gifted Mom is an app developed in Cameroon which provides users with basic, yet critical information about pregnancy, breastfeeding and child vaccinations. The widespread use of Android smartphones in Africa has meant that Gifted Mom has been able to reach more people at scale and improve lives.



Watch the creators of Gifted Mom, developer Alain Nteff and doctor Conrad Tankou, explain how they built their business and launched Gifted Mom on Google Play. They also talk about their plans to grow and help people in other developing countries across the continent in the next three years, in order to ultimately tackle maternal and infant mortality.





Find out more about building apps for Android and how to find success on Google Play.

Rabu, 18 November 2015

Hungering for Game Utilities?

Posted by Alex Ames, Fun Propulsion Labs*



Originally posted to the Google Developers blog





At Fun Propulsion Labs we spend some of our time building sample games to help demonstrate how to make easy-to-build, performant, cross-platform games. With the growth of Google Cardboard, we got to work and over many long evenings, feeding our animal hunger on sushi, we came up with Zooshi. Zooshi is an open source, cross-platform game written in C++ which supports:



  • Android, Android TV, Windows, OSX, and Linux

  • Google Cardboard

  • Google Play Games Services sign-in and leaderboards on Android

  • Level customization


Zooshi serves as a demonstration of how to build Android games using a suite of newly released and updated open source game technologies from Google:



  • Motive drives our Animation system, giving life and movement to the characters and environment.

  • CORGI, the Component Oriented Reusable Game Interface, is an Entity-Component system designed to allow users to define complicated game objects as collections of modular, custom-defined behaviors.

  • FlatUI is a straightforward immediate mode GUI system with a light footprint that makes building up user interfaces a breeze.

  • Scene Lab allows designers to design levels and edit entities from right in the game without needing to use an external editor.

  • Breadboard provides an easy to use node based scripting system for editing entity behaviors that's accessible to designers without deep knowledge of programming.

  • FPLBase is a cross-platform API layer, for abstracting low-level tasks like reading input and creation of graphical contexts.


As in our previous release, Pie Noon, we also made extensive use of Flatbuffers, Mathfu, fplutil, and WebP.



You can download the game in the Play Store and the latest open source release from our GitHub page. We invite you to learn from the code to see how you can apply these libraries and utilities in your own Android games. Take advantage of our discussion list if you have any questions, and don’t forget to toss some sushi around while you’re at it!



* Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.

API 23 SDK now available for Android Wear

Posted by Wayne Piekarski, Developer Advocate



The new LG Watch Urbane 2nd Edition LTE is the first watch to run Android 6.0 Marshmallow (API 23) for Android Wear. Currently, all other Android Wear watches implement API 22, and in the coming months, these will receive an OTA update for API 23 as well.



So what does this mean for you as an Android Wear developer? You will need to ensure that your apps are compatible with both API 23 and API 22 watches. While you can start implementing the new features in this post, you still need to maintain backwards compatibility until all watches are upgraded.



New permissions model and samples


API 23 introduces a new runtime permissions model for both phones and watches. The new permissions model allows users to pick and choose which permissions to grant apps at the time of use. In addition, new permissions settings allow users to turn on and off app permissions at any time.



To use the new permissions model on Wear, read Permissions on Android Wear. This training guide provides an in-depth discussion of Wear-specific scenarios, such as when your Wear app relies on a phone-side permission. In addition, all of the Android Wear samples have been updated to use the new permissions model, and a new RuntimePermissionsWear sample shows how to handle permission requests across devices.



When you are ready, you can update your application on both the phone and watch side to use compileSdkVersion 23 and targetSdkVersion 23. Make sure that you check and request the permissions needed by your app at runtime, on both the phone and the watch. It is important that you do not change targetSdkVersion to 23 until you have implemented the permission checks properly, since it changes how the system installs and runs the app. For example, an API call that might have previously returned a result could now fail, causing the app to behave in unexpected ways.






-round and -notround resource qualifiers


API 23 makes it easier to build apps for both round and square Android Wear watches. We listened to your feedback and added new resource qualifiers for -round and -notround, so you can use the resource system to load the appropriate images, layouts, and strings based on the type of watch you are working with. You can also combine this with existing resource qualifiers -hdpi, -tvdpi, -280dpi, and -360dpi for the various Android Wear watches that are currently available. All of the existing classes in the wearable UI library, such as WatchViewStub, BoxInsetLayout, and WearableFrameLayout will continue to work as well, so you do not need to change your code. The -round and -notround resource qualifiers will not work on API 22 devices, so you cannot assume they will be available until all devices are on API 23.



Watches with speakers


The LG Watch Urbane 2nd Edition LTE is the first watch to include speaker support, so you can now add sounds to your Wear app. You can play audio files using the same APIs that are available on Android phones, such as AudioTrack, MediaPlayer, and ExoPlayer. Check out the sample and documentation to learn how to detect when the speaker is available on a Wear device and play sounds through it.



Intel x86 support


The new TAG Heuer Connected, along with other upcoming Android Wear watches, is based on Intel x86 processors. If you are working only with Java code, your apps will automatically work on any architecture. However, if you’re using the NDK, you’ll need to provide both armeabi-v7a and x86 shared libraries in your wearable APK. Since only one wearable app can be bundled in a phone app, it is not possible to deliver different APKs to different watches based on architecture. If your wearable APK is missing an x86 library, it will fail to install on x86 watches with INSTALL_FAILED_NO_MATCHING_ABIS and code -113.



If you are using Android Studio, you will need to adjust your build.gradle file to include:


ndk {
abiFilters = ['armeabi-v7a','x86']
}

If you are using the NDK directly, you will need to modify your Application.mk file to use:


APP_ABI := armeabi-v7a x86


These changes should only be made for the wearable APK, and you can continue to support other ABIs on the phone side. You can test your application by checking if it works on the x86 emulator provided by the SDK Manager.



Updated emulator


New Android Wear emulator images for API 23 and x86 watches are available to download from the SDK Manager in Android Studio. We have also added profiles that represent every available Android Wear watch, so you can easily test on any device you want. It is also important that you understand and test all the combinations of phones (API <= 22, API = 23) and wearables (API 22, API 23), so that your app works for all users.



Updates to existing watches


The new emulator images allow you to get started immediately with testing and deploying updated apps for users with API 23 watches. The schedule for updating existing Android Wear watches via OTA updates has not been announced yet. We will announce the update schedule on the Android Wear Developers Google+ community. We’ll also let you know when the rollout is complete, and API 22 support for Android Wear is no longer needed.


Selasa, 17 November 2015

An updated app guide and new video tips to help you find success on Google Play

Posted by Dom Elliott, The Google Play Apps & Games team



Last year, we introduced our first playbook for developers, “The Secrets to App Success on Google Play”, to help you grow your app or game business, which has been downloaded more than 200,000 times.. Many new features have since been announced on the platform – from Store Listing Experiments and beta testing improvements to App Invites and Smart Lock for Passwords.



Get the second edition of “The Secrets to App Success on Google Play”



Hot off the press, you can now download the second edition to learn about all the new tools and best practices for improving the quality of your app, growing a valuable audience, increasing engagement and retention, and earning more revenue.







Get the book on Google Play in English now or you can sign-up to be notified when the booklet is released in the following languages: Bahasa Indonesia, Deutsch, español (Latinoamérica), le français, português do Brasil, tiếng Việt, русский язы́к, ไทย, 한국어, 中文 (简体), 中文 (繁體), 日本語. Based on your feedback, the guide was updated to work seamlessly in the Google Play Books app. If you prefer, you can also download a PDF version from the Android Developers website.



New videos with tips to find success on Google Play



To accompany the guide, watch the first two episodes in a new ten-part video series of actionable tips you can start using today to achieve your business objectives. Subscribe to the Android Developers channel on YouTube and follow +Android Developers to watch the new videos as they’re released weekly.





Two new videos will be released each week in the ten-part series


on the Android Developer YouTube channel.



Let us know your feedback



Once you’ve checked out the guide and the videos, we’d again love to hear your feedback so we can continue to improve our developer support, please let us know what you think.

Minimum purchase price for apps and in-app products reduced on Google Play

Posted by Alistair Pott, Product Manager, Google Play



Available in more than 190 countries, Google Play is a global platform for developers to build high quality apps and successful businesses. But every market has its own unique challenges and opportunities. Purchasing behavior, in particular, varies significantly between markets. So to provide developers with more flexibility, we've worked to adapt Google Play pricing options to better suit local consumers and make content more accessible.



Following a successful pilot in India earlier this year, today, developers have the option to reduce the price of their premium titles and in-app products in 17 more countries to these new minimum thresholds:



Countries affected:


  • Brazil: R$ 0.99 (was R$2.00)

  • Chile: CLP $200.00 (was CLP $500.00)

  • Colombia: COP$ 800.00 (was COP$ 2000.00)

  • Egypt: E£2 Previous (was E£7)

  • Hungary: Ft 125.00 (was Ft 225.00)

  • Indonesia: Rp 3,000.00 (was Rp 12,000.00)

  • Malaysia: RM 1.00 (was RM 3.50)

  • Mexico: MXN$ 5.00 (was MXN$ 9.90)

  • Nigeria: ₦40 (was ₦195)

  • Peru: S/. 0.99 (was S/. 3.00)

  • Philippines: ₱15.00 (was ₱43.00)

  • Poland: zł1.79 (was zł2.99)

  • Russia: руб 15.00 (was руб 30.00)

  • Saudi Arabia:﷼ 0.99 (was 4.00﷼)

  • South Africa: R3.99 (was R10.00)

  • Thailand: ฿10.00 (was ฿32.00)

  • Turkey: ₺0.59 (was ₺2.00)

  • Ukraine: ₴5.00 (was ₴8.00)

  • Vietnam: ₫6,000 (was ₫21,000.00)


You can lower the price of your apps and games right away by visiting the Google Play Developer Console and clicking on “Pricing & Distribution” or “In-app Products” for your apps.



We hope this change allows you to reach more people around the world so that you can continue to grow your business on Google Play.



Kamis, 12 November 2015

Improvements to Sign-In with Google Play services 8.3

Posted by Laurence Moroney, Developer Advocate



With Google Play services 8.3, we’ve been hard at work to provide a greatly improved sign-in experience for developers that want to build apps that sign their users in with Google. To help you better understand some of these changes, this is the first in a series of blog posts about what’s available to you as a developer. In this post, we’ll discuss the changes to the user experience, and how you can use them in your app, as well as updates to the API to make coding Sign-In with Google more straightforward. On Android Marshmallow, this new Sign-In API has removed any requirement for device permissions, so there is no need to request runtime access to the accounts on the device, as was the case with the old API.



User Experience Improvements


We’ve gotten lots of feedback from developers about the user experience of using Google’s social sign-in button. Many of you noted that it took too many steps and was confusing for users. Typically, the experience is that the user touches a sign in button, and they are asked to choose an account. If that account doesn’t have a Google+ profile, they need to create one, and after that they have to give permissions based on the type of information that the app is asking for. Finally, they get to sign in to the app.



With the new API, the default set of permissions that the app requests has been reduced to basic profile information and optionally email address as demonstrated here. This introduces opportunities for much streamlined user experience: the first improvement here is in the presentation of the button itself. We had received feedback that the Google+ branding on the Sign-In button made it feel like the user would need to share Google+ data, which most apps don’t use. As such, the SignInButton has been rebranded with the reduced scopes -- it now reads ‘Sign In with Google’, and follows the standard Google branding for use with basic profile information.





After this, the user flow is also more straightforward. Instead of subsequent screens where a Google account is picked based on the email addresses registered on the device, followed by a potential ‘Create Google+ Profile’ dialog, followed by a permissions consent dialog, like this:










The user experience has changed to a single step, where the user chooses their account and gives consent. If they don’t have a Google+ profile, they don’t need to create one, eliminating that step. Additional consent dialogs come later, and are best requested in context so that the user understand why you might ask for access to their calendar or contact, and they are only prompted at the time that this data is needed.












We hope that a streamlined, one-tap, non-social sign-in option with additional OAuth permissions requested in context will help improve your sign-in rates and make it a breeze to sign-in with Google.



Check out some live apps that use the new API, including Instacart, NPR One, and Bring!











In the next post we’ll build on this by looking at some of the changes in the API to make coding apps that use Sign-In with Google even easier.