Jumat, 19 Februari 2016

Using Credentials between your Server and Google Services

Posted by Laurence Moroney, Developer Advocate



This is part 4 of a series on Google Sign-In that began with a blog post on the user experience improvements that launched with Google Play services 8.3. We then discussed the API updates that make the programming model much easier. Most recently, we went into how you can use Google Sign-In to authenticate a user with your backend server.



In this post, we’ll discuss how you can have your users sign in via your app to authorize your service for access to Google APIs, such as Google Drive, on their behalf.



When using Google Sign-In, it is easy to extend your integration with Google by requesting additional scopes for API access after sign-in, like storing the user’s pictures of food in Google Drive. Typically, you should request this access incrementally (not at initial sign-in) -- i.e. in the context of a user’s actions (for example, after an app user’s order has been delivered and they’d like to save a copy of their food photos), following best practices in user experience to make it most likely that the user will grant access, and aligning with the runtime permissions model in Android Marshmallow 6.0.



When you do this kind of integration, you probably want to access data from your server, so that you can continue to have access when the user is offline, or to store user-generated data in your own database. This flow would look like Figure 1. This also has the advantage of working across all platforms.





Figure 1. Accessing Google Services with Credentials.



To do this, follow these steps:



Step 1: As with the scenario in server authentication covered in the previous post, this sample provides canonical code for your Android app. In particular see the ServerAuthCodeActivity.




 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  
.requestScopes(new Scope(Scopes.DRIVE_APPFOLDER))
// The serverClientId is an OAuth 2.0 web client ID
// Details at: https://developers.google.com/identity/sign-in/android/?utm_campaign=android_discussion_server_021116&utm_source=anddev&utm_medium=blogstart step 4
.requestServerAuthCode(serverClientId)

.requestEmail()
.build();


This requires you to get a web client ID for your server. Details on how to obtain this are available here (see Step 4).



In this case, the scope DRIVE_APPFOLDER is requested, meaning that the user will be asked to give the app permission to access their Google Drive. In addition to this, a server auth code will be requested.



If the sign-in is successful, the auth code can be extracted from the account object like this:




 if (result.isSuccess()) {  
GoogleSignInAccount acct = result.getSignInAccount();
String authCode = acct.getServerAuthCode();
}


(Taken from onActivityResult in the sample here)



This auth code should then be sent to your server using HTTPS POST, and, after it is exchanged, will give your server access to the user’s Google Drive. [Important: you should send the code in an authenticated call to your backend to ensure that it is a legitimate request from the active user].



Step 2: On your server, you will then exchange the auth code for tokens using the GoogleAuthorizationCodeTokenRequest class:




 // Set path to the Web application client_secret_*.json file you downloaded from the  
// Google Developers Console: https://console.developers.google.com/project/_/apiui/credential
// You can also find your Web application client ID and client secret from the
// console and specify them directly when you create the GoogleAuthorizationCodeTokenRequest
// object.
String CLIENT_SECRET_FILE = "/path/to/client_secret.json"; // Be careful not to share this!
String REDIRECT_URI = "/path/to/web_app_redirect" // Can be empty if you don’t use web redirects
// Exchange auth code for access token
GoogleClientSecrets clientSecrets =
GoogleClientSecrets.load(
JacksonFactory.getDefaultInstance(), new FileReader(CLIENT_SECRET_FILE));
GoogleTokenResponse tokenResponse =
new GoogleAuthorizationCodeTokenRequest(
new NetHttpTransport(),
JacksonFactory.getDefaultInstance(),
"https://www.googleapis.com/oauth2/v4/token",
clientSecrets.getDetails().getClientId(),
clientSecrets.getDetails().getClientSecret(),
authCode,
REDIRECT_URI)
.execute();
String accessToken = tokenResponse.getAccessToken();
String refreshToken = tokenResponse.getRefreshToken();
Long expiresInSeconds = tokenResponse.getExpiresInSeconds();
// You can also get an ID token from the exchange result if basic profile scopes are requested
// e.g. starting GoogleSignInOptions.Builder from GoogleSignInOptions.DEFAULT_SIGN_IN like the
// sample code as used here: http://goo.gl/0Unpq8
//
// GoogleIdToken googleIdToken = tokenResponse.parseIdToken();


Then, create a GoogleCredential object using the tokens from GoogleTokenResponse:




 GoogleCredential credential = new GoogleCredential.Builder()  
.setTransport(new NetHttpTransport())
.setJsonFactory(JacksonFactory.getDefaultInstance())
.setClientSecrets(clientSecrets)
.build();
credential.setAccessToken(accessToken);
credential.setExpiresInSeconds(expiresInSeconds);
credential.setRefreshToken(refreshToken);


If a refresh token is available, you can persist the credentials using StoredCredential for later use if you need ongoing access to the API on behalf of the user.



Step 3: The credential can then be used to access Google services. Now, in our food delivery scenario, you might want to store or retrieve photos or receipts of finished deliveries in Google Drive. For example, it would look something like this:




 Drive drive = new Drive.Builder(new NetHttpTransport(),   
JacksonFactory.getDefaultInstance(),
credential)
.setApplicationName("Auth Code Exchange Demo")
.build();
File file = drive.files().get("appfolder").execute();


This demonstrates the use of Google Sign-In credentials where your server can make Google API calls on behalf of your users. To learn more about this, and all Google Sign In technologies, visit the Google Identity Platform website.



Kamis, 18 Februari 2016

Get the guide to family app success on Google Play and see how BabyFirst increased installs by 50%

Posted by Lily Sheringham, The Google Play Apps & Games team



We recently released the second edition of The Secrets to App Success on Google Play with more best practices for finding success growing an app or game business on Google Play. Today we’re sharing our first companion guide for developers, The Family Playbook, which includes information on developing high-quality apps and games for kids and families, along with advice from other developers.



The guide includes advice to help you optimize your user interface design for children, build interactive features that both educate and entertain, develop a business model, understand legal considerations, and plan age-appropriate marketing.



If you create family apps, opt-in to the Designed for Families developer program to designate your apps and games as family-friendly. Apps that meet the program requirements will be featured through Google Play’s family-friendly search and browse experiences and help parents discover great, age-appropriate content and make more informed choices.



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



Android Developer Story: BabyFirst increases installs by 50% with Google Play



BabyFirst was founded to create good educational content for babies, toddlers and their parents. Their apps now have over 30 million downloads, with 40% more downloads on Google Play than other platforms.



Watch this Android Developer Story to learn how opting-in to Designed for Families on Google Play, implementing Store Listing Experiments, and localizing the store listing into 10 languages helped them increase installs by 50% across their portfolio of apps.







Find out more about the Designed for Families program and download our new Family Playbook to help you find success on Google Play.




Kamis, 11 Februari 2016

ASUS X302UJ-FN018D Laptop Gaming HDD 1GB Dengan Nvidia GeForce GT920M 7 jutaan

Harga ASUS X302UJ-FN018D dan Spesifikasi | Quick Spec: Intel Core i5-6200U, 4GB DDR3L, 1TB HDD, VGA Nvidia GeForce GT920M 2GB, Bluetooth, Wifi, 13.3" HD, Non OS | Harga ASUS X302UJ-FN018D: Rp. 7.625.000,- | Sebenarnya saya sedang mencari laptop i5 dengan hard disk 1TB ketika menemukan ASUS X302UJ-FN018D ini.Selain processor dan GPU yang kuat, saya juga butuh storage atau media penyimpanan yang

Acer Aspire ES1-531 Laptop Murah Hard Disk 1 TB Cuman 3,7 jutaan

Acer Aspire ES1-531 Harga dan Spesifikasi | Quick Spec: Intel Celeron N3050, 2GB DDR3, 1TB HDD, DVD±RW, WiFi, VGA Intel HD Graphics, Camera, 15.6", Non OS | Harga Acer Aspire ES1-531: Rp. 3.799.000,- | Jujur saja, saya agak terkejut ketika ‘nemu’  laptop dengan hard disk 1 TB murah banget, kurang dari 4 juta. Kalau anda rajin berburu laptop, pasti hafal kalau harga laptop hard disk 1 TB itu

Minggu, 07 Februari 2016

Asus A456UF-WX016D Laptop Gaming Murah Dengan i5-6200U dan GT930M

Asus A456UF-WX016D Harga dan Spesifikasi | Quick Spec: Intel Core i5-6200U, 4GB DDR3, 500GB HDD, DVDRW, Nvidia GeForce GT930M 2GB, Wifi, Bluetooth, 14" HD, Non OS, Non Bag | Harga Asus A456UF-WX016D: Rp 7,399,000,- | Kalau anda tipe orang yang selalu berusaha memakai yang terbaru, bisa jadi sekarang laptop murah dengan processor Skylake sedang menjadi incaran anda. Dan sekarang sudah ada Asus

Jumat, 05 Februari 2016

Asus Pro P450LAV-WO264D Laptop i3 Murah dan Ringan

Asus Pro P450LAV-WO264D Harga dan Spesifikasi | Quick Spec: Intel Core i3-4030U, 2GB DDR3, 500GB HDD, GbE NIC, WiFi, Bluetooth, VGA Intel HD Graphics 4400, Camera, 14" WXGA, Non OS, Garansi: 24 bulan dari Distributor Resmi di Indonesia, harga Asus Pro P450LAV-WO264D: Rp 5,349,000,- | Salah satu pilihan laptop i3 murah tahun ini adalah Asus Pro P450LAV-WO264D ini. Dengan fitur bagus untuk

Android Studio 2.0 - Beta

Posted by Jamal Eason, Product Manager, Android



Android Studio 2.0 is latest release of the official Android IDE focused on build performance and emulator speed to improve the app development experience. With brand new features like Instant Run which enables you to quickly edit and view code changes, or the new & faster Android emulator, Android Studio 2.0 is the upgrade you do not want to miss. In preparation for the final release, you can download Android Studio 2.0 Beta in the Beta release channel. Overall, the Android Studio 2.0 release has a host of new features which include:




  • *Updated for Beta* Instant Run - Enables a faster code edit & app deployment cycle.

  • *Updated for Beta* Android Emulator - Brand new emulator that is faster than most real devices, and includes a brand new user interface.

  • *Updated for Beta* Google App Indexing Integration & Testing - Adding App Indexing into your app helps you re-engage your users. In the first preview of Android Studio 2.0 you could add indexing code stubs into your code. With the beta release you can now test and validate your URL links in your app all within the IDE.

  • Fast ADB - Installing and pushing files is now up to 5x faster using Android Studio 2.0 with an updated Android Debug Bridge (ADB) offered in platform-tools 23.1.0.

  • GPU Profiler Preview - For graphics intensive applications, you can now visually step through your OpenGL ES code to optimize your app or game

  • Integration of IntelliJ 15 - Android Studio is based on the efficient coding platform of Intellij. Check out the new features from IntelliJ here.



Check out the latest installment of Android Studio Tool Time video below to watch the highlights of the features.







New Features in Android Studio 2.0 Beta





Instant Run


We first previewed Instant Run in November; this latest beta release introduces a new capability called Cold Swap



Instant Run in Android Studio 2.0 allows you to quickly make changes to your app code while your app is running on an Android device or Android Emulator. Instead of waiting for your entire app to rebuild and redeploy after each code change, Android Studio 2.0 will try to incrementally build and push only the incremental code or resource change. Depending on the code changes you make, you can see the results of your change in under a second. By simply updating your app to use the latest Gradle plugin ( 'com.android.tools.build:gradle:2.0.0-beta2’ ), you can take advantage of this time saving features with no other modifications to your code. If your project is setup correctly with Instant Run, you will see a lightning bolt next to your Run button on the toolbar:





Instant Run Button



Behind the scenes, Android Studio 2.0 instruments your code during the first compilation and deployment of your app to your device in order to determine where to swap out code and resources. The Instant Run features updates your app on a best-effort basis and automatically uses one of the following swap methods to update your app:




  • Hot Swap - When only method implementations (including constructors) are changed, the changes are hot swapped. Your application keeps running and the new implementation is used the next time the method is called.

  • Warm Swap - When app resources are changed, the changes are warm swapped. This is similar to a hot swap, except that the current Activity is restarted. You will notice a slight flicker on the screen as the Activity restarts.

  • *New for Beta* Cold Swap - This will quickly restart the whole application. Typically for structural code change, including changes to the class hierarchy, method signatures, static initializers, or fields. Cold Swap is available when you deploy to targets with API level 21 or above.



We made major changes to Instant Run since the first preview of Android Studio 2.0, and now the feature works with more code and resources cases. We will continue to add more code change cases to Instant Run in future releases of Android Studio. If you have any suggestions, please feel free to send us a feature request and learn more about Instant Run here.




App Indexing




Supporting app indexing is now even easier with Android Studio 2.0. App Indexing puts your app in front of users who use Google Search. It works by indexing the URL patterns you provide in your app manifest and using API calls from your app to make content within your app available to both existing and new users. Specifically, when you support URLs for your app content, your users can go directly to those links from Google Search results on their device.




  • Code Generation
    Introduced in Android Studio 2.0 Preview, you can right click on AndroidManifest.xml or Activity method (or go to Code → Generate…→ App Indexing API Code) to insert HTTP URL stub codes into your manifest and app code.







  • *New for Beta* URL Testing & Validation
    What is new in Android Studio 2.0 Beta is that you can now validate and check the results of your URLs with the built-in validation tool (Tools → Android → Google App Indexing Test). To learn more about app indexing, click here.


Insert App Indexing API Code into your app



App Indexing Testing





App Indexing Test Results



Android Emulator



*Updated for Beta* The new and faster Android emulator also includes fixes and small enhancements for this beta release. Notably, we updated the rotation controls on the emulator toolbar and added multi-touch support to help test apps that use pinch & zoom gestures. To use the multi-touch feature, hold down the Alt key on your keyboard and right-click your mouse to center the point of reference or click & drag the left mouse button to zoom.





Pinch & Zoom Gesture with Multi-Touch



What's Next



Android Studio 2.0 is a big release, and now is good time to check out the beta release to incorporate the new features into your workflow. The beta release is near stable release quality, and should be relatively bug free. But as with any beta release, bugs may still exist, so, if you do find an issue, let us know so we can work to fix it. If you’re already using Android Studio, you can check for updates on the Beta channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). When you update to beta, you will get access to the new version of Android Studio and Android Emulator.



Connect with us, the Android Studio development team, on Google+.

Kamis, 04 Februari 2016

Project Tango workshops help bring indoor location apps to life

Posted by Eitan Marder-Eppstein, Developer Engineering Lead, Project Tango



GPS helps us find our way outside whether it is turn by turn navigation to the nearest grocery or just getting us oriented in a new city. But once we get indoors, it is not quite as easy - GPS doesn't work, with accuracy dropping and navigation becoming all but impossible. This is one of the reasons why we started Project Tango, which has centimeter-scale accuracy of a device’s location, allowing better navigation and experiences in indoor spaces.




Over the past few weeks, we’ve been collecting amazing ideas from around the world for great apps for Lenovo’s Project Tango-powered phone. (Have an idea? If you can dream it, you can submit it!) As part of this program we're hosting workshops, focused on specific Tango features. And we just wrapped up a session that we hosted with Westfield Labs devoted to indoor location. Here are some of the highlights:







As you can see, everyone from retail brands to robot startups joined in on the fun—using Project Tango's motion tracking, depth perception, and area learning capabilities to build some amazing location-based apps. Some of our favorites included:




  • Wayfair made it possible to look through your phone and visualize how a piece of furniture would look in your home.

  • Lowe’s Innovation Labs improved in-store navigation by overlaying directions to individual items

  • And Aisle411 created a shop-along experience with some of your favorite celebrities






The next stop in our series is a utilities workshop, where we'll be going deep on getting things done with Project Tango—like taking 3D measurements, or mapping your home or building. In the meantime, keep submitting your ideas to the App Incubator (the deadline is February 15!), and we'll see you soon!

Selasa, 02 Februari 2016

Asus K401LB-FR068D Ultrabook i5 Gaming Paling Murah Spesifikasi Tangguh

Asus K401LB-FR068D Harga dan Spesifikasi | Quick spec: Intel Core i5-5200U, 4GB DDR3L, 1TB HDD, VGA Nvidia GeForce GT940M 2GB, Wifi, Bluetooth, 14" FHD, Non OS, Non Bag, garansi: 12 bulan dari Distributor Resmi di Indonesia. Harga Asus K401LB-FR068D: Rp 7,999,000,- | Jika sekarang anda sedang mencari ultrabook gaming paling murah, maka Asus K401LB ini masih menjadi pilihan pertama.

Di Bhinneka,

Senin, 01 Februari 2016

Marshmallow and User Data



Posted by Joanna Smith, Developer Advocate and Giles Hogben, Google Privacy Team



Marshmallow introduced several changes that were designed to help your app look after user data. The goal was to make it easier for developers to do the right thing. So as Android 6.0, Marshmallow, gains traction, we challenge you to do just that.



This post highlights the key considerations for user trust when it comes to runtime permissions and hardware identifiers, and points you to new best practices documentation to clarify what to aim for in your own app.



Permission Changes


With Marshmallow, permissions have moved from install-time to runtime. This is a mandatory change for SDK 23+, meaning it will affect all developers and all applications targeting Android 6.0. Your app will need to be updated anyway, so your challenge is to do so thoughtfully.



Runtime permissions mean that your app can now request access to sensitive information in the context that it will be used. This gives you a chance to explain the need for the permission, without scaring users with a long list of requests.



Permissions are also now organized into groups, so that users can make an informed decision without needing to understand technical jargon. By allowing your users to make a decision, they may decide not to grant a permission or to revoke a previously-granted permission. So, your app needs to be thoughtful when handling API calls requiring permissions that may have been denied, and about building in graceful failure-handling so that your users can still interact with the rest of your app.



Identifier Changes



The other aspect of user trust is doing the right thing with user data. With Marshmallow, we are turning off access to some kinds of data in order to direct developers down this path.



Most notably, Local WiFi and Bluetooth MAC addresses are no longer available. The getMacAddress() method of a WifiInfo object and the BluetoothAdapter.getDefaultAdapter().getAddress() method will both return 02:00:00:00:00:00 from now on.




However, Google Play Services now provides Instance IDs, which identify an application instance running on a device. Instance IDs provide a reliable alternative to non-resettable, device-scoped hardware IDs, as they will not persist across a factory reset and are scoped to an app instance. See the Google Developer's What is Instance ID? help article for more information.



What’s Next


User trust depends largely on what users see and how they feel. Mishandling permissions and identifiers increases the risk of unwanted/unintended tracking, and can result in users feeling that your app doesn’t actually care about the user. So to help you get it right, we’ve created new documentation that should enable developers to be certain that their app is doing the right thing for their users.







So happy developing! May your apps make users happy, and may your reviews reflect that. :)