Hacker Life

I wanted to get the correspondent enum value from a string field. Let’s say I have defined enum Fruit.

enum Fruit {apple, banana}

In the JSON payload of an API call, I’m getting string value of the enum. So I want to convert it to the correct enum value. This is how I did in my flutter application.

Fruit getFruitFromString(String fruit) {
  fruit = 'Fruit.$fruit';
  return Fruit.values.firstWhere((f)=> f.toString() == fruit, orElse: () => null);
}

This is the way that use to exclude some transitive dependency.

compile('com.facebook.android:facebook-android-sdk:4.22.0') {
        exclude group: 'com.android.support', module: 'support-v4'
        exclude group: 'com.android.support', module: 'appcompat-v7'
}

When come to project type dependency this is the way.

compile (project(':library:view_pager_indicator')) {
        exclude group: 'com.android.support', module: 'support-v4'
        exclude group: 'com.android.support', module: 'appcompat-v7'
}

Keep in mind the additional brackets around  project. (project(‘:library:view_pager_indicator’))

If you are an android developer you may already familiar with this issue.

com.android.build.api.transform.TransformException: 
    com.android.builder.packaging.DuplicateFileException: 
    Duplicate files copied in APK *****************

Usually you’re getting this for some text files or license files like META-INF/notice.txt , META-INF/license.txt , META-INF/ASL2.0

In such scenarios we can exclude those files from APK packaging without any hesitation because we definitely know those will not affect our application functionality. We can do so using gradle packagingOptions .

packagingOptions {
        exclude 'META-INF/notice.txt'
        exclude 'META-INF/license.txt'
        exclude 'META-INF/ASL2.0'
        exclude 'META-INF/LICENSE'
        exclude 'META-INF/NOTICE'
    }

What can we do when we get like

com.android.build.api.transform.TransformException: 
    com.android.builder.packaging.DuplicateFileException: 
    Duplicate files copied in APK lib/arm64-v8a/librealm-jni.so

or

com.android.build.api.transform.TransformException: 
    com.android.builder.packaging.DuplicateFileException: 
    Duplicate files copied in APK lib/x86/librealm-jni.so

or

com.android.build.api.transform.TransformException: 
    com.android.builder.packaging.DuplicateFileException: 
    Duplicate files copied in APK lib/armeabi/librealm-jni.so

We cannot exclude those files since they required for app functionality. So we need another way to handle such scenarios.

We can use pickFirst in packagingOptions to avoid duplicate file copying to APK as below.

packagingOptions {
        exclude 'META-INF/notice.txt'
        exclude 'META-INF/license.txt'
        pickFirst 'lib/armeabi/librealm-jni.so'
        pickFirst 'lib/x86/librealm-jni.so'
        pickFirst 'lib/x86_64/librealm-jni.so'
        pickFirst 'lib/arm64-v8a/librealm-jni.so'
        pickFirst 'lib/armeabi-v7a/librealm-jni.so'
        pickFirst 'lib/mips/librealm-jni.so'
    }

Comments are used to describe the code for other users who will reuse or do changes on that code. After few time comments are also very useful even us to realize that what we done in there. So developers used to add comments in everywhere of the code. Is it the best practice?

Add comment isn’t a best practice always. It is better if we can write descriptive code rather than adding comment to describe what we do with the code. If a code can read and get what it done that kind of code says as a descriptive code. Let’s see some example.

// validate normal user exceed mounthly usage
if(user.type.aquals(NORMAL) && user.monthlyUsage > usageLimit)

or we can change the code as

if(user.isNormalUserExceedMounthlyUsage())

Which one is more descriptive? In second one it is easy to understand what it done even without a comments. Also it save the time that we wast for adding comments.

But some comments are important and we couldn’t miss. First one is legal comments that contains details about authorship and copyrights. Legal notes are generally added at the start of each source file.

For a example Oracle added Legal note like this in every sources of its products

/*
 * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights reserved.
 * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 */ 

Also there are some points that we should mention some useful information in comments.

//keep track of the current db connection status.
// (initial value is false to make sure the first SNMP trap is sent when sustem starts)
private boolean isDbConnectionDown = true;

In here we inform the user who refer the code that what do with this property and what can do with change it. At that point comment is very important and it added some value to the code.

Another useful comment is //TODO comments. TODO comment explains what are the features that should implemented but can’t done it now for some reason.

//todo need to check if a cycle has been missed previously and if it has been mist it has to be reloaded.
  public List loadAllUnfinishedCampaigns(String schedulerTypes, JobExecutionContext context) {

Comments can be use to amplify the important of something that can feel another user as useless.

// Important- Calender months are indexed from 0-11.
eventMap.put(monthField, String.valueOf(calendar.get(MONTH) + 1));

Javadocs are very important when you are writing public APIs

Rather than that most of the other comments aren’t added much sense on the user except repeating code content to the user. Let’s lock some example comments that we can eliminate from our codes.is

Try to avoid Separator comments because with modern IDEs no use of those separators.

// Actions ----------------------------------

Don’t use comments to keep in track with version histories and author’s details. Modern version controllers manage this task much better. So don’t pollute the code with those things.

Also don’t remain unwanted commented codes in your sources. New comers will not be remove those commented codes unless you remove it. It any code really unwanted delete it without comment it.

When a code is written in first time developer properly organize the code and properly add comments. There is no problem with the code. Problems began when we had to refactor the code urgently as usually happening. Developers quickly done the refactorings and done it in time but most probably they missed the comments to refactor. So there remains irrelevant comments with the code.

Comments are very important but unwanted comments are headache for developers. So think before adding a comment if it’s really useful and be sure it says that actually done.

Next developer only get that we remains on the code. If we didn’t do nicely it’ll be a huge mess for them.

/**
* Provides the current lib version.
*
* @author PasanLive
*/
public final class Version {
   /**
   * Current lib version.
   */
   public static final String LIB_VERSION = "${version}";
}

Have you noticed the placeholder “${version}” that’ll be replaced with the actual version in the build process. Then new gradle task need to be defined. So we can define a class extending DefaultTask in our build.gradle script.

class GenerateVersionFileTask extends DefaultTask {
    def templateLocation
    def destination

    File getDestination() {
        project.file(destination)
    }

    File getTemplateFile() {
        project.file(templateLocation)
    }

    String getTemplateContent() {
        getTemplateFile().getText('UTF-8').replace("${version}", getVersion())
    }

    String getVersion() {
        project.version
    }

    @TaskAction
    def generate() {
        println 'Generating version file'
        def templateContent = getTemplateContent();
        def file = getDestination()
        file.parentFile.mkdirs()
        file.write(templateContent, 'UTF-8')
        println Version file generated'
    }
}