Android: Should you sign different Apps with the same Key or not?

Releasing your first App is a great milestone, but with releasing the second one, here comes the question: Should I use the same key to sign my new app, or should I generate a new key for it?!!

Well, it totally depends on your needs, so let’s see different needs:

Why using same key for different apps?

  • When you want to use App modularity features (as recommended by the official documentation):

    Android allows apps signed by the same certificate to run in the same process, if the applications so requests, so that the system treats them as a single application. In this way you can deploy your app in modules, and users can update each of the modules independently.

  • When you want to share Code/Data securely between your apps through permissions (also as recommended by the official documentation):

    Android provides signature-based permissions enforcement, so that an app can expose functionality to another app that is signed with a specified certificate. By signing multiple apps with the same certificate and using signature-based permissions checks, your apps can share code and data in a secure manner.

  • If you want to avoid the hassle of managing different keys for different apps.

Why using different keys for different apps?

  • If you are somehow paranoid about security (and you should), not to put all the eggs in one basket, which is highly recommended in this article.

  • When the apps are completely different & won’t ever use the app-modularity or Code/Data sharing described above.

  • When there is a chance (even a small one) that you will sell one of the apps separately in the future, then that app must have its own key from the beginning.

Some useful numbers:
As per this article, they made a study on August 2014, they found that Google Play has about 246,000 Android apps but only 11,681 certificates were found!
The distribution of the number of apps sharing the same key is shown below. The X-axis is the number of apps sharing the same certificate. The Y-axis is the number of certificates.
The distribution of the number of apps sharing the same key. The X-axis is the number of apps sharing the same certificate. The Y-axis is the number of certificates.

Be aware that once you signed your app and uploaded it to Google Play, you can’t undo this step, you can’t sign it with a different certificate key. so make your decision wisely!

I hope you find here the answer you were searching for, & hope you share your case with us in the comments .. Good Luck 🙂


Android: Loading images Super-Fast like WhatsApp – Part 2

We discussed earlier in Part 1 of this tutorial how Zingoo team wants to deliver the best UX possible to the users, & because WhatsApp is doing a great job with images, so we watched what they are doing, like:

  • Photos are cached, so no need to load them every time you open the app.
  • They first show a very small thumbnail (about 10KB or less) until the real image is loaded, & this is the real pro-tip for their better UX.
  • Photos sizes range around 100KB, which loads the images pretty fast on most common mobile-network speeds.

First 2 points are already discussed in part 1, so question here in part 2 is how could we compress images to be about 100KB to be sent easily over common mobile-networks.

How is it done?
After taking the picture and saving it to a file with path imagePath, we start compressing it to be ready for sending over network:

ImageCompressionAsyncTask imageCompression = new ImageCompressionAsyncTask() {
    protected void onPostExecute(byte[] imageBytes) {
        // image here is compressed & ready to be sent to the server
imageCompression.execute(imagePath);// imagePath as a string

& here is what we do in ImageCompressionAsyncTask:

public abstract class ImageCompressionAsyncTask extends AsyncTask<String, Void, byte[]> {

    protected byte[] doInBackground(String... strings) {
        if(strings.length == 0 || strings[0] == null)
            return null;
        return ImageUtils.compressImage(strings[0]);

    protected abstract void onPostExecute(byte[] imageBytes) ;

It is clear that the real juice exists in ImageUtils.compressImage(). Thanks to Ambalika Saha & her brilliant post that enabled me from using this solution in Zingoo, and even writing this post right here 🙂 . And here is my version of doing it:

public class ImageUtils {
    private static final float maxHeight = 1280.0f;
    private static final float maxWidth = 1280.0f;

    public static byte[] compressImage(String imagePath) {
        Bitmap scaledBitmap = null;

        BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        Bitmap bmp = BitmapFactory.decodeFile(imagePath, options);

        int actualHeight = options.outHeight;
        int actualWidth = options.outWidth;
        float imgRatio = (float) actualWidth / (float) actualHeight;
        float maxRatio = maxWidth / maxHeight;

        if (actualHeight > maxHeight || actualWidth > maxWidth) {
            if (imgRatio < maxRatio) {
                imgRatio = maxHeight / actualHeight;
                actualWidth = (int) (imgRatio * actualWidth);
                actualHeight = (int) maxHeight;
            } else if (imgRatio > maxRatio) {
                imgRatio = maxWidth / actualWidth;
                actualHeight = (int) (imgRatio * actualHeight);
                actualWidth = (int) maxWidth;
            } else {
                actualHeight = (int) maxHeight;
                actualWidth = (int) maxWidth;


        options.inSampleSize = ImageUtils.calculateInSampleSize(options, actualWidth, actualHeight);
        options.inJustDecodeBounds = false;
        options.inDither = false;
        options.inPurgeable = true;
        options.inInputShareable = true;
        options.inTempStorage = new byte[16 * 1024];

        try {
            bmp = BitmapFactory.decodeFile(imagePath, options);
        } catch (OutOfMemoryError exception) {

        try {
            scaledBitmap = Bitmap.createBitmap(actualWidth, actualHeight, Bitmap.Config.ARGB_8888);
        } catch (OutOfMemoryError exception) {

        float ratioX = actualWidth / (float) options.outWidth;
        float ratioY = actualHeight / (float) options.outHeight;
        float middleX = actualWidth / 2.0f;
        float middleY = actualHeight / 2.0f;

        Matrix scaleMatrix = new Matrix();
        scaleMatrix.setScale(ratioX, ratioY, middleX, middleY);

        Canvas canvas = new Canvas(scaledBitmap);
        canvas.drawBitmap(bmp, middleX - bmp.getWidth() / 2, middleY - bmp.getHeight() / 2, new Paint(Paint.FILTER_BITMAP_FLAG));

        ExifInterface exif;
        try {
            exif = new ExifInterface(imagePath);
            int orientation = exif.getAttributeInt(ExifInterface.TAG_ORIENTATION, 0);
            Matrix matrix = new Matrix();
            if (orientation == 6) {
            } else if (orientation == 3) {
            } else if (orientation == 8) {
            scaledBitmap = Bitmap.createBitmap(scaledBitmap, 0, 0, scaledBitmap.getWidth(), scaledBitmap.getHeight(), matrix, true);
        } catch (IOException e) {
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        scaledBitmap.compress(Bitmap.CompressFormat.JPEG, 85, out);
        return out.toByteArray();

    public static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) {
        final int height = options.outHeight;
        final int width = options.outWidth;
        int inSampleSize = 1;

        if (height > reqHeight || width > reqWidth) {
            final int heightRatio = Math.round((float) height / (float) reqHeight);
            final int widthRatio = Math.round((float) width / (float) reqWidth);
            inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
        final float totalPixels = width * height;
        final float totalReqPixelsCap = reqWidth * reqHeight * 2;

        while (totalPixels / (inSampleSize * inSampleSize) > totalReqPixelsCap) {

        return inSampleSize;

I hope you like it.

Android: Loading images Super-Fast like WhatsApp – Part 1

Zingoo is a new promising app that will rock your weekends, outings and any happening that you want to easily enjoy watching its moments over & over again (we are now doing the Android version, then the iOS one). Because we want Zingoo to be born strong, it has to deliver the best possible [UX] to all awesome-moments lovers around the world, which means we have to do our best in loading the images.

Because we (at Begether) do listen to our users, we heard a lot of comments on how WhatsApp is loading images super-fast, so we dug deeper to know what we can do about it, & here is what we find,

What does WhatsApp do?
WhatsApp is doing the following (numbers are approximate):

  • Photos sizes range around 100KB, which loads the images pretty fast on most common mobile-network speeds. (part 2 explains how to achieve this)
  • Photos are cached, so no need to load them every time you open the app (almost no need to mention this 🙂 ).
  • They first show a very small thumbnail (about 10KB or less) until the real image is loaded, & this is the real pro-tip for their better UX.

The last tip has a different variance by calculating the image dimensions & the approximate color of the image that will be shown & applying it to its placeholder, like the coming 3 minutes in this video:

but still, the thumbnail is away more cooler, right? 😉

How is it done?
To achieve the caching there are some good Android libraries out there that are doing a good job, but one of them is doing a way better than the others, which is Picasso. Both caching on disk & on memory are built under the hood, with a very developer-friendly API, I just love what Jake Wharton & his mates did for all of us, thanks guys.
Using Picasso is pretty easy, just like this example one-liner:


you just need first to add Picasso to your gradle files with the urlConnection library (according to this issue), like this:

compile 'com.squareup.picasso:picasso:2.4.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.0'

After solving the caching issue, we need to apply the thumbnail great tip, we need to use Picasso 2 times, one for loading the thumbnail and the other for loading the real image like the comment I made on this issue. Also to avoid the thumbnail’s pixlation effect (due to its small size), it would be better to make a blurring effect on it,
WhatsApp's Thumbnail Loading Effect

and here is how it is done:

Transformation blurTransformation = new Transformation() {
    public Bitmap transform(Bitmap source) {
        Bitmap blurred = Blur.fastblur(LiveImageView.this.context, source, 10);
        return blurred;

    public String key() {
        return "blur()";

    .load(thumbUrl) // thumbnail url goes here
    .resize(imageViewWidth, imageViewHeight)
    .into(imageView, new Callback() {
        public void onSuccess() {
                    .load(url) // image url goes here
                    .resize(imageViewWidth, imageViewHeight)

        public void onError() {

We used the Callback() functionality to start loading the full image after the thumbnail is completely loaded, with using the blurred thumbnail’s drawable as the new placeholder for the real image, & this is how the magic is being done right here :).
Also the blurring made here is Blur.fastblur(), thanks to Michael Evans & his EtsyBlurExample example, you can find this class here.

The only remaining part is how to compress the large images (which could be 2 to 4 MB) to be only about 100 KB, which is discussed in Part 2.

Making the Action-bar Up-button behave smoothly like the Back-button

When hitting Android’s Back-button, current activity will be closed with bringing the previous one back to the top of the stack, but the keyword here is that happens without calling the previous one’s onCreate method.

Unlike when hitting the Up-button, current one will be closed, but the previous one’s onCreate will be called again causing a little delay (depends on what you do in your onCreate of course 🙂 )

So, here is the solution from this brilliant stackOverflow answer:

Intent intent = NavUtils.getParentActivityIntent(this); 
NavUtils.navigateUpTo(this, intent);

& for a full solution you can put the previous code in onOptionsItemSelected like this:

public boolean onOptionsItemSelected(MenuItem item) {
    switch (item.getItemId()) {
        // Respond to the action bar's Up/Home button
            Intent intent = NavUtils.getParentActivityIntent(this);
            NavUtils.navigateUpTo(this, intent);
            return true;
    return super.onOptionsItemSelected(item);