Skip to content

Instantly share code, notes, and snippets.

View AndroidManifest.xml
<manifest>
<application>
<activity
android:name="com.yalantis.ucrop.UCropActivity"
android:screenOrientation="portrait"
android:theme="@style/Theme.AppCompat.Light.NoActionBar" />
<provider
android:name="androidx.core.content.FileProvider"
android:authorities="${applicationId}.provider"
android:exported="false"
@mrsasha
mrsasha / GsonSetup.kt
Last active Feb 10, 2020
date & time formatting & de/serialization with Gson and ThreeTenABP
View GsonSetup.kt
private fun createGson(): Gson = GsonBuilder()
.registerTypeAdapter(OffsetDateTime::class.java, OffsetDateTimeTypeAdapter())
.create()
class OffsetDateTimeTypeAdapter : JsonSerializer<OffsetDateTime>, JsonDeserializer<OffsetDateTime> {
override fun serialize(
src: OffsetDateTime,
typeOfSrc: Type,
context: JsonSerializationContext
@mrsasha
mrsasha / Activity.kt
Last active Feb 18, 2020
viewmodels with channels
View Activity.kt
private fun observeViewModel() {
mainViewModel.observe(lifecycleScope) {
when (it) {
MainScreenState.InProgress -> showProgress()
}
}
}
@mrsasha
mrsasha / Activity.kt
Created Feb 4, 2020
Permission management
View Activity.kt
override fun onStart() {
super.onStart()
permissionManager.requestLocationPermission(this, object : LocationPermissionListener {
override fun permissionGranted() {
Timber.v("location permission granted!")
}
override fun permissionError(error: DexterError) {
Timber.w("location permission error: $error!")
}
@mrsasha
mrsasha / detekt-config.yml
Created Dec 18, 2019
detekt setup for 1.2.2 version
View detekt-config.yml
build:
maxIssues: 0
comments:
active: true
excludes: "**/*Test.kt, **/*Spec.kt"
CommentOverPrivateFunction:
active: false
CommentOverPrivateProperty:
active: false
@mrsasha
mrsasha / build.gradle
Last active Nov 27, 2019
adding Sonarqube reporting for Lint and test coverage to Android Kotlin project (multi-module)
View build.gradle
apply plugin: "org.sonarqube"
buildscript {
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.6.2"
}
}
//ADD ALL THE TASKS (coverage, lint) FOR ALL THE MODULES YOU WANT TO BE REPORTED
project.tasks["sonarqube"].dependsOn ':library-core:testDebugUnitTestCoverage'
@mrsasha
mrsasha / build.gradle
Last active May 23, 2020
adding Sonarqube reporting for Lint and test coverage to Android Kotlin project (single module)
View build.gradle
buildscript {
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.6.2"
}
}
@mrsasha
mrsasha / add_detekt_single_module.md
Created Jul 13, 2018
Adding detekt static code analysis to kotlin projects
View add_detekt_single_module.md

You can add static code analysis to kotlin using detekt. Below is the basic configuration, for more details about configuration and rules go to project page: https://arturbosch.github.io/detekt/.

//add to top-level gradle file
buildscript {
    ext {
        detektVersion = '1.0.0.RC7'
    }

    repositories {
@mrsasha
mrsasha / README.md
Created Jul 13, 2018
Jacoco setup for calculating kotlin test coverage (single module)
View README.md

Jacoco setup for calculating kotlin test coverage (single module)

put the jacoco.gradle file below somewhere in your app repo (like scripts folder), and then add apply from: '../scripts/jacoco.gradle' to your module gradle file.

This will add additional gradle build tasks to your app, in the form of "testFlavourUnitTestCoverage" that you can run manually (e.g. testStagingDebugUnitTestCoverage) to generate the coverage.

You can edit def excludes definition to further exclude classes you don't want to generate the coverage for. If you have source in other folders beyond those specified in def coverageSourceDirs, add them.

This will generate both exec file used by external code quality analyzers (like Sonarqube), in the build/jacoco folder, and XML and HTML reports, in the build/reports/jacoco/flavourName folder.

@mrsasha
mrsasha / code_review_guidelines.md
Last active Aug 30, 2021
Code review guidelines
View code_review_guidelines.md

Some helpful guidelines for pull requests and code reviews

It's been often said that programming is part art, part science - that because lots of times there's no single, simple solution to a problem; or if there is, we might not know about it. There's also an infamous joke that if there are n developers in the room, then there are n+1 opinions on how things should be done. That being said, here are some guidelines that should prevent friction when submitting or reviewing code.

The most important thing

The code has to work. Unless you open a PR as a work in progress, the code should be built and tested on a device or emulator.

If you have touched the gradle build files and changed build setup, it's useful to test the whole build from scratch (clean build) and all of the types and flavours. If you have touched payments (logic or UI), you should test that it still works correctly, both in test and production builds. If you updated external libraries, test the pertaining features (e.g. if you