Android 🤖

Project Structure

Typical structure we usually have:

com.nimble.project
├─ other-module
├─ app
│  ├─ libs
│  ├─ src
│  │  ├─ androidTest
│  │  │  └─ java
│  │  │     └─ com/nimble/InstrumentalTest
│  │  │  
│  │  ├─ main
│  │  │  ├─ java
│  │  │  │   └─ com/nimble
│  │  │  │          ├─ model
│  │  │  │          │  └─ Something.java
│  │  │  │          ├─ view
│  │  │  │          ├─ presenter
│  │  │  │          ├─ service
│  │  │  │          ├─ event
│  │  │  │          ├─ util
│  │  │  │          │
│  │  │  │          └─ ApplicationClass.java
│  │  │  ├─ res
│  │  │  │   ├─ anim
│  │  │  │   ├─ color
│  │  │  │   ├─ drawable
│  │  │  │   ├─ layout
│  │  │  │   └─ values
│  │  │  └─ AndroidManifest.xml
│  │  │  
│  │  ├─ test
│  │  │  └─ java
│  │  │     └─ com/nimble/UnitTest
│  │  │  
│  │  └─ staging
│  │     └─ res
│  │        └─ values
│  ├─ build.gradle
│  └─ proguard-rules.pro
│
├─ spec
│  └─ rspec_test.rb
│
├─ .travis.yml
├─ phraseapp.yml
│
├─ build.gradle
├─ keystore.jks
├─ settings.gradle
└─ README.md

Development Environment

Android SDK, IDE

• We use Android Studio as the main official IDE.
• It’s encouraged to use the Developer preview version to access the new feature and adopt the changes in order to improve the productivity.

Emulator

• Use x86 emulator for significant speed up during development.

Gradle configuration

• Gradle should be the default option for build system (for now, you may want to review some other later too such as Bazel, Buck…)
• Although Gradle offers a large degree of flexibility in your project structure, unless you have a compelling reason to do otherwise, you should accept its default structure as this simplify your build scripts.
• Building a Signed Release APK, you can choose either way:
  • AS Menu -> Build -> Generate Signed APK -> Manually adding the keystore directory / passwords -> Build.
  • Gradle config for Signing APK:

// Put this in your app module level gradle:
signingConfigs {
    release {
        try {
            storeFile file("myapp.keystore")
            storePassword KEYSTORE_PASSWORD
            keyAlias "thekey"
            keyPassword KEY_PASSWORD
        }
        catch (ex) {
            throw new InvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.")
        }
    }
}

// And create another `gradle.properties` file to keep the password, don't PUSH this to the repo.
KEYSTORE_PASSWORD=real_keystore_password
KEY_PASSWORD=real_key_passw

• Don’t ever expose the key secrets like this:

// Don't do this
signingConfigs {
    release {
        storeFile file("myapp.keystore")
        storePassword "storepassword"
        keyAlias "thekey"
        keyPassword "nicepassword"
    }
}

Gradle configuration for app flavors

The purpose is to separate the Develop environment (endpoints, library keys…) with the real Production environment. To achieve this:

• First, define the flavor in app level gradle config:

productFlavors {
    production {
        applicationId "com.app.android"
    }

    staging {
        // Staging AppId should be different from the real production.
        applicationId "com.app.staging"
    }
}

sourceSets {
    staging {
        res.srcDirs = ['src/staging/res']
    }
    // production doesn't need to clarify the resource directory as it uses the default main one.
}

• Second, create a proper staging directory for the staging resources (endpoints, different keys…):

│  │  ├─ main
│  │  │  ├─ java
│  │  │  └─ res
│  │  │     ├─ anim
│  │  │     ├─ color
│  │  │     ├─ drawable
│  │  │     ├─ layout
│  │  │     └─ values
│  │  │  
│  │  │  
│  │  └─ staging
│  │     └─ res
│  │        ├─ anim
│  │        ├─ color
│  │        ├─ drawable
│  │        ├─ layout
│  │        └─ values

ABI filter

• The ABI defines, with great precision, how an application’s machine code is supposed to interact with the system at runtime. You must specify an ABI for each CPU architecture you want your app to work with. Applying an incorrect ABI choice on a mismatched CPU architecture won’t make it work. For example: running on x86 emulator requires you to use the proper x86 apk.
• You can read more from here, but in this example, we’re just simply splitting the app into 2 different flavors:
  • production_x86 for x86 chipset.
  • production for armeabi, armeabi-v7a chipset.

// Adding this to your app module level gradle:
production_x86 {
    // Append automatically a different code version to identify the different version when app is published and we observe the tracking info.
    versionCode Integer.parseInt("6" + defaultConfig.versionCode)
    applicationId "com.redplanet.android"
    ndk {
        abiFilters "x86"
    }
}

production {
    applicationId "com.redplanet.android"
    ndk {
        abiFilters "armeabi", "armeabi-v7a"
    }
}

// Don't forget to bring the proper native library files (.so) to the main/jniLibs/

• Some Gradle tips that would be helpful.

Proguard

Proguard is normally used on Android projects to shrink and obfuscate the packaged code. We do this usually for release Apk (it helps saving time of downloading for users, hence increase the app download rates).

buildTypes {
    debug {
        minifyEnabled false
    }
    release {
        signingConfig signingConfigs.release
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

XML Files

• View-based XML files should be prefixed with the type of view that they represent:

Bad:

• login.xml
• main_screen.xml
• rounded_edges_button.xml

Good:

• activity_login.xml
• fragment_main_screen.xml

• button_rounded_edges.xml

• Use Context-Specific XML Files wherever possible XML resource files could be used:
  • Strings => res/values/strings.xml
  • Styles => res/values/styles.xml
  • Colors => res/color/colors.xml
  • Animations => res/anim/
  • Drawable => res/drawable
• XML Attribute Ordering

Where appropriate, XML attributes should appear in the following order:

* `style` attribute (if there is)
* `id` attribute
* `layout_*` attributes
* style attributes such as `gravity` or `textColor`
* value attributes such as `text` or `src`

Within each of these groups, the attributes should be ordered alphabetically.

• Use styles

It helps styling management easier, or at least we should have some common styles clarifications that are being used throughout the app:

In activity_main_layout.xml:

<Button
    style="@style/AppButtonStyle"
    android:id="@+id/image_profile"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:gravity="center"
    android:text="Button Text" />

style.xml:

<style name="AppButtonStyle">
    <item name="android:textSize">@dimen/font_normal</item>
    <item name="android:textColor">@color/basic_black</item>
</style>