Google Maps No Longer Requires STORAGE Permission!

For a long time, Google Maps Android SDK requires us to have WRITE_EXTERNAL_STORAGE permission. It was not the case when they first released the SDK.

I didn’t want to have that storage permission first, because In app permission “The permission description says that the application can access files on the devices such as images, videos or audio”. 

I had lots of 1, 2, 3 stars in app ratings because of this. Users say that “Why do you request access for my photos and videos?”. They are right! They are always right. I don’t want to access your photos and I won’t. I am forced to have that permission.

Android Marshmallow brought us run-time permissions. They are great! Users do not see permissions when they install or update the app. Users have more control over the app’s functionality.

for example, a user could choose to give a camera app access to the camera but not to the device location.

But imagine you have an app with Google Maps integration, and imagine you have to request WRITE_EXTERNAL_STORAGE on runtime to show the map. How would you explain that to users? Runtime permissions that are not obvious and require explanation are the worse. This is one of them.

Fortunately, they fixed the issue and removed storage permission. But not for all, just for Android Marshmallow.

If you use Google Maps and you want to target Android Marshmallow, this is what you need to do:

• First you need to use Google Play Services 8.1.0
• Second, you need to add maxSdkVersion property in your permissions as shown below:

They also say in the documentation that they will remove it completely in the next release.

From the next release of the Google Play services SDK, the requirement for the WRITE_EXTERNAL_STORAGE permission will be completely dropped from the Google Maps Android API.

Note: Please do the described changes in your application if you have Google Maps and want to target Android M!

Thanks for reading :) 

Whether this post is helpful?

Have something to add to this post? If you have any other quick thoughts/hints that you think people will find useful? Share it in the comments. feedback are welcome...

Small Note on Parse Vs Firebase

For mobile app developers, picking and choosing a server or cloud solution for things like storage, push notifications, user information and analytics can be a struggle.

We have few servers like parse, firebase and more which helps us in doing all the job of backend without writing a single line of code.

We will compare Parse Vs Firebase in the post.

Heads up: you're comparing apples to oranges. Tools belonging to different groups are often not directly comparable because they usually have different intended purposes, benefits and need.

	Firebase	Parse
Description	Real-time cloud data service	Complete technology stack for building mobile apps
Storage	NoSQL	SQL
Setup	Easy	Easy
Documentation	Great Documentation	Well documented
Hosting	Yes	Yes
Supports	Android/iOS/REST/Web	Android/iOS/REST/Web/PHP/.NET and more
Authentication	Firebase makes authentication easy. It can integrate with your existing login server, or authenticate users with only client-side code. It has built-in functionality for email & password, and third-party providers such as Facebook, Twitter, GitHub, and Google.	Users can be created through traditional username/password signup, through a third-party login system like Facebook or Twitter, or even by using Parse's automatic anonymous users functionality.
Offline/Local Data Storage	Yes	Yes
Analytics	Yes	Yes
Security & Rules	Yes	Yes
File Storage	No	Yes
Push Notification	No	Yes
Realtime Communcation	Yes	No
Crash Reporting	No	Yes

More info: http://stackshare.io/stackups/firebase-vs-parse#more

Thanks for reading :) 

Whether this post is helpful?

Have something to add to this post? If you have any other quick thoughts/hints that you think people will find useful? Share it in the comments. feedback are welcome...

Android and the DEX 64K Methods Limit & Online Tool

Our apps are limited to a 64K method reference limit. If your app reaches this limit, the build process outputs the following error message:

Unable to execute dex: method ID not in [0, 0xffff]: 65536

Tools

This is a drap and drop tool which helps us to find the number of method in apk http://inloop.github.io/apk-method-count/.

Which helps us to be in safe-guard in optimizing things. Know we need some solutions to optimize the problem. Let find them

Solutions

MultiDex

MultiDex allows you to use multiple DEX files contained within one APK. With a few steps, your classes will split automatically into several DEX files (classes.dex,classes2.dex, classes3.dex, etc) in case you reach the method index limit.

ProGuard

ProGuard is a tool that shrinks, optimizes and obfuscates your code by removing unused code and renaming classes, fields and methods with semantically obscure names.

JarJar

Jar Jar Links is a utility that makes it easy to repackage Java libraries and embed them into your own distribution.

Conclusion

At this point, Google Play Services is perhaps the biggest common threat on your methods count. I would love to see this API broken into separate modules. A detailed summary of this problem was published a while ago by Jake Wharton & Android and the dex 64k methods limit by Tom Renzik, so feel free to dive into that as well.

Another interesting blog post was published a while ago by Cyril Mottier, illustrating how to reduce APK size using various different techniques. 

Thanks for reading :) 

Whether this post is helpful?

Have something to add to this post? If you have any other quick thoughts/hints that you think people will find useful? Share it in the comments.