Blogs from Experimentation

Subbu Lakshmanan



### Why

There seems to be confusion around using Dispatchers in Coroutines. Dispatchers are used to mention the thread on which the coroutine should run.

  - `Dispatchers.Main` - Main thread
  - `Dispatchers.IO` - IO thread
  - `Dispatchers.Default` - CPU-intensive thread

While we should mention the dispatcher for the coroutine based on the work a function does, We don't need to do the same for the caller of the suspending function. i.e., The suspend function that does the actual work handles what dispatcher to use, and the caller of the function should not worry about it.

In fact, various libraries explicitly provide suspending APIs for long-running blocking operations. The complexity of moving the appropriate tasks to background threads is already taken care of within the library. When calling the library's suspending API, it does not have to be considered.

**P.S:** `Dispatchers.Unconfined` is not recommended to be used in production code and is not discussed here.

### What to do

- When you write a long-running or CPU intensive task, wrap the code with the appropriate dispatcher so that the caller of the function need not worry about it.
- If the library provides suspending APIs, the library will take care of the dispatchers. (It's a good practice to check the documentation of the library to see if it provides suspending APIs)
- If you are calling an existing suspending function, check if it uses the appropriate dispatcher. If not, wrap it with appropriate dispatcher to avoid mentioning one in the caller of the function.

## How to do

Here's an example:

```kotlin
fun onDoneClicked() {
    viewModelScope.launch(Dispatcher.IO) {
        initiateSeeding()
    }
}

...

suspend fun initiateSeeding() {
    async {
        // Do some work that runs in IO thread
    }
}
```

1. Wrap the long-running IO task with `Dispatcher.IO`

    ```kotlin

    suspend fun initiateSeeding() {
        async(Dispatcher.IO) {
            // Do some work that runs in IO thread
        }
    }
    ```

2. Remove the dispatcher from the caller of the function

    ```kotlin
    fun onDoneClicked() {
        viewModelScope.launch {
            initiateSeeding()
        }
    }
    ```

Another good example is Retrofit. Retrofit provides suspending APIs for network calls. The library takes care of the dispatchers, and the caller of the function need not worry about it.

```kotlin
interface SeedApiService {
    @GET("seeds")
    suspend fun getSeeds(): List<Seed>
}

class SeedRepository(private val seedApiService: SeedApiService) {
    suspend fun getSeeds(): List<Seed> = seedApiService.getSeeds()
}

class SeedViewModel(private val seedRepository: SeedRepository) {
    fun fetchSeeds() {
        viewModelScope.launch {
          try {
            val seeds = seedRepository.getSeeds()
            // Do something with the seeds
          } catch (e: Exception) {
            // Handle error
          }
        }
    }
}
```

The library will handle the dispatchers, and We don't need to mention it in the `viewModelScope.launch` function.

## References

- [Retrofit Suspended Functions](https://amitshekhar.me/blog/retrofit-with-kotlin-coroutines)
- [Do-i-need-to-call-suspend-functions-of-retrofit-and-room-on-a-background-thread](https://www.lukaslechner.com/do-i-need-to-call-suspend-functions-of-retrofit-and-room-on-a-background-thread/)

---


Use best practices to avoid using different dispatchers for suspending functions

Suspending functions should not be called on a different dispatcher


### Why

As we add new functionality to an existing codebase, we tend to add more and more parameters to existing functions. Often, We want to minimize the changes to the current code and wrap the feature/bugfix quickly. While the intention is good, it can lead to many problems in the future. 

Depending on the project, this number can vary. As per sonarlint, this number should be less than 7. Anything more than that indicates that either, 
  1. Function is doing too much
  2. Parameters can be grouped to form a new class

While one can suppress this warning using `@Suppress("LongParameterList"),` it's better to refactor the code to avoid this warning.

### What to do

Depending on the function, there are different ways to refactor the code to avoid this warning.

1. Check the usage of the parameters inside the function and see if you can
   1. Remove parameters that may serve the same purpose
   2. Split the function into multiple functions
2. Group related parameters into a new class and pass the class instance as a parameter

## How to do

```kotlin
 fun showErrorDialog(
  title: String? = null,
  message: String? = null,
  positiveTitle: String? = null,
  negativeTitle: String? = null,
  val positiveButtonTextColor: Int? = null,
  isCancelable: Boolean = true,
  isSingleButtonDialog: Boolean = true,
  val inCompose: Boolean = false
) {
  ...
}
```

One way to fix this is to group the parameters into a new class and create a new overloaded function that takes the new class as a parameter.

```kotlin
data class DialogParams(
  val title: String? = null,
  val message: String? = null,
  val positiveTitle: String? = null,
  val negativeTitle: String? = null,
  val positiveButtonTextColor: Int? = null,
  val isCancelable: Boolean = true,
  val isSingleButtonDialog: Boolean = true,
)

fun showErrorDialog(
  dialogParams: DialogParams, 
  val inCompose: Boolean = false
) {
  ...
}
```

Replace the function call with the new function and pass the parameters as a new class instance.

```kotlin
fun showLoginFailed() {
  showErrorDialog(
    DialogParams(
      title = "Login Failed",
      message = "Please try again",
      positiveTitle = "Retry",
      negativeTitle = "Cancel",
      positiveButtonTextColor = R.color.green,
      isCancelable = false,
      isSingleButtonDialog = true
    )
  )
}
```

You can remove the old function once you replace all the usages with the new function.

**Note**: The code examples are simplified for brevity. Ideally, use string resources instead of hardcoded strings.

---



Use best practices to avoid a lot of parameters in a function

Functions should not have too many parameters


## Why

Sometimes the developer may add a `suspend` keyword to a function that calls another suspending function as that's the first auto-suggestion/warning provided by the IDE. 

![IDE warning](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3valpyh9vlkp5ama2fwu.png)

IDE makes it easy for the developer to auto-fix the warning by adding the `suspend` keyword to the function.

![IDE auto-suggestion](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7zsi6yscw4unrozh84sj.png)

But, this breaks the rule **Classes extending "ViewModel" should not expose suspending functions**. 

Views should not be responsible for directly triggering coroutines. Hence, ViewModel classes should prefer creating coroutines instead of exposing suspending functions to perform some piece of business logic. This approach allows for easier testing of your application, as ViewModel classes can be unit tested, whereas views require instrumentation tests.

## What to do

When you find a function in a ViewModel which breaks this rule, follow these steps to refactor it:

1. Find the need for the `suspend` keyword in the function, i.e., check if the function is calling any other suspending function
   - e.g., `listOfPlants.collectLatest` is a suspending function
2. See if you can wrap the suspending function call in a coroutine & use the appropriate scope & dispatcher
   - e.g., `viewModelScope.launch` can be used to wrap the suspending function call
3. Remove the `suspend` keyword from the function
4. Remove creating coroutines from the caller of the function if it is not needed anymore

## How to do

The example,

```kotlin
// In ViewModel
suspend fun listenForUpdates() {
    listOfPlants.collectLatest { plants ->
        plants.filter { it.isFavorite }.let { favorites ->
            // do something with favorites
        }
    }
}

// In Fragment
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    lifecycleScope.launchWhenStarted {
        viewModel.listenForUpdates()
    }
}
```

could be refactored to,

```kotlin
// In ViewModel
fun listenForUpdates() {
    viewModelScope.launch {
        listOfPlants.collectLatest { plants ->
            plants.filter { it.isFavorite }.let { favorites ->
                // do something with favorites
            }
        }
    }
}

// In Fragment
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    lifecycleScope.launchWhenStarted {
      viewModel.listenForUpdates()
    }
}
```

## References

- [Coroutines: Best practices](https://developer.android.com/kotlin/coroutines/coroutines-best-practices#viewmodel-coroutines)

---


Use best practices to avoid exposing suspend functions from ViewModels

ViewModels should not expose suspending functions


One of the recommendation in designing UI layer from the Android's guide to app architecture is to use '**Uni-Directional Data Flow**'. This is achieved by viewModels exposing UI state via observer pattern and receive events from UI via callbacks. 

One of the best practice in exposing the UI state is to use immutable data types like `LiveData` or `StateFlow`. But, sometimes, we may be tempted to use `MutableStateFlow` or `MutableSharedFlow` to expose the UI state. While they are very convenient for storing and adding updates of some data structures in event-driven paradigm & useful to manage such objects inside some class, it’s not recommended to expose them outside of the class.

## Why

When properties of the types `MutableStateFlow` or `MutableSharedFlow` are accessible from outside of a class, data updates cannot be verified properly anymore.

```kotlin
val isBiometricEnabled = MutableStateFlow(false)
```

In the above example, the value of `isBiometricEnabled` can be changed from outside of the class. It is generally recommended to have only one class responsible for updating these flows, otherwise inconsistency issues and problems with maintainability, as well as bugs may be introduced.

## What to do

To restrict write access, `StateFlow` or `SharedFlow` should be used together with `private MutableStateFlow` or `MutableSharedFlow` fields.

- If the variable is used only for reading, change its type to `StateFlow` or `SharedFlow`
- If the variable is used for writing, change its type to `private MutableStateFlow` or `private MutableSharedFlow` and add a `public` property with `StateFlow` or `SharedFlow` type that exposes the value of the `private` field

## How to do

Here's one way of refactoring the code.

1. Find the usages of the variable in question (i.e., one that has `MutableStateFlow` or `MutableSharedFlow` type)
2. If the variable is used only for reading, change its type to `StateFlow` or `SharedFlow`
3. If the variable is used for reading & writing,
  - Create a new variable with `StateFlow` or `SharedFlow` type that reads from the `MutableStateFlow` or `MutableSharedFlow` variable (use some naming convention to indicate that naming is temporary)

    ```kotlin
    val isBiometricEnabled = MutableStateFlow(false)
    val tempIsBiometricEnabled:StateFlow<Boolean> = isBiometricEnabled.asStateFlow()
    ```

  - Replace 'read' usages with the new variable
  - Change the type of the `MutableStateFlow` or `MutableSharedFlow` variable to `private` & rename it to indicate that it is `private`

    ```kotlin
    private val _isBiometricEnabled = MutableStateFlow(false)
    val tempIsBiometricEnabled:StateFlow<Boolean> = _isBiometricEnabled.asStateFlow()
    ```

  - Fix the naming of the new variable to match the naming convention

    ```kotlin
    private val _isBiometricEnabled = MutableStateFlow(false)
    val isBiometricEnabled:StateFlow<Boolean> = _isBiometricEnabled.asStateFlow()
    ```

  - Check the usages to verify that `isBiometricEnabled` is not used for writing anywhere outside of the class and `_isBiometricEnabled` is not exposed outside of the class

## References

Here are some references to the articles that I found useful

- [coroutines-best-practices-mutable-types](https://developer.android.com/kotlin/coroutines/coroutines-best-practices#mutable-types)

---


Use best practices to avoid exposing mutable flow types

Don't expose Mutable Flow Types


While upgrading my android project to use AGP 8.0.0, I noticed that android build analyzer had a recommendation to use non-transitive R classes to improve build speed. 

![Build Analyzer Recommendation](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2ubmtjopkch8mno0wlzd.png)

I was curious to know what it is and how it works. So, I did some research and here's what I found.

## Why

Non-transitive R classes have been around for a while, but it was not enabled by default. With AGP 8.0.0, it is enabled by default. For the curious minds, I have included a blog that talks about the history of R classes and non-transitive R classes at the end of this article.

Non-transitive R classes enable namespacing of each library’s R class so that its R class includes only the resources declared in the library itself and none from the library’s dependencies, thereby reducing the size of the R class for that library.

For example, if the code uses a default animation `R.anim.nav_default_enter_anim` which comes from the `androidx.navigation:navigation-ui-ktx` dependency. Without using non-transitive R classes, The 'R' class of module has references to its own resources and transitive references to resources of navigation UI library.

  ```kotlin
  import com.learning.compose.R
  ...

    .setStartAnimations(activity, R.anim.nav_default_enter_anim, R.anim.nav_default_exit_anim)

  ```

With non-transitive R classes enabled, this will force us to use the fully qualified R class name to access the resources in the dependency module, thus reducing the references in the 'R' class of 'compose' module. And also by referencing using fully qualified R class name, the Compose module doesn't have to be recompiled and the build speed is improved.


  ```kotlin
  .setStartAnimations(activity, androidx.navigation.ui.R.anim.nav_default_enter_anim, androidx.navigation.ui.R.anim.nav_default_exit_anim)
  ```

Now, if you go to `app/build/intermediates/runtime_symbol_list/internalDebug/R.txt`, you will see that the references to `nav_default_enter_anim` and `nav_default_exit_anim` are removed from the 'R' class of the module.

Since the dependencies become more explicit with non-transitive R classes, the modularity of the code increases. It also decreases  complexity, since resources cannot come from transitive dependencies. It also increases the build speed(both *clean* and *incremental*) as promised by [Android Developers from Android Dev Summit '21](https://youtu.be/S_zZRBJxTQ0?t=69).

## What to do

If you use a resource from another dependency/module,
- If your android project is 100% Kotlin Only, You are in luck. You can `alias` imports of R classes of dependency modules to access resources in that module.
- If your project has some Java code references, You have to use fully qualified R class name to access resources in the dependency module

Also, If you use a resource from another module, but you do not declare a dependency on that module, and you do not want to declare a dependency, you could simply duplicate resources in the app module

## How to do

Use Android Studio's `Refactor -> Migrate to non-transitive R classes` to migrate the project to use non-transitive R classes
  - This will, 
    - Adds the below in gradle.properties

      ```properties
      android.nonTransitiveRClass=true
      ```
  
    - Updates fully qualified R class name wherever it finds the non-transitive R class usage

      ```kotlin
      .setStartAnimations(activity, androidx.navigation.ui.R.anim.nav_default_enter_anim, androidx.navigation.ui.R.anim.nav_default_exit_anim)
      ```

Additionally, If the code base is in Kotlin, You could `alias` the fully qualified package name of the R class to access the resources

  ```kotlin
  import androidx.navigation.ui.R as NavUiR

  ...
    .setStartAnimations(activity, NavUiR.anim.nav_default_enter_anim, NavUiR.anim.nav_default_exit_anim)
    .setExitAnimations(activity, NavUiR.anim.nav_default_pop_enter_anim, NavUiR.anim.nav_default_pop_exit_anim)
  ```

Here are some references to the articles that I found useful

- [Improve Build speed Recommendation](https://developer.android.com/build/optimize-your-build#use-non-transitive-r-classes)
- [History of R classes & non-transitive R classes](https://www.mobileit.cz/Blog/Pages/r-class.aspx)


Improving Build Speed by using non-transitive R classes

Non-Transitive R Classes


Most of the repository providers (Github, Bitbucket) have a size limitation on the repository size and mechanisms to store large files using LFS options. In most cases, a repository may not reach these typical max size limits enforced. However, it can happen over a long period unless certain measures are taken to reduce the file size.

> **Disclaimer:**
> 
1. There are a lot of articles on what to commit to a repository and what to ignore. The assumption is that you have followed the guidelines not to store any runtime/build/temporary files, yet reach the size limit.
2. There are a few commands that can permanently delete the data. The suggested approach to a clean-up is to create a new clone of the repo, execute the clean-up procedure and verify the results. If you are happy with what you have arrived at, then push the changes to your remote.
3. Since the process involves re-writing history, you will need to 'force' push the changes to remote. So make sure to perform these commands with the approval of the team and only when it's required (i.e., The Git repo storage limit is reached).

These are a few commands to identify the biggest files that could be potential files to remove. You can remove these files and commit, but this will not remove the pack files associated with the original commits.

One way to remove the large files and the pack files associated with them is by using the `git filter-branch` along with the `git reflog & git gc` command.

Before beginning, Here are a few commands that we use to identify and remove bigger files.

- To identify the size of the repo

  ```bash
  du -scH
  ```

- To identify the count of files & other info

  ```bash
  git count-objects -vH
  ```

- Identify the top 10 big files

  ```bash
  ls -ld -- **/*(DOL[1,10])
  ```

- Identify the commits with the largest 'n' blobs (Sort ascending and list the last 'n' items)

  ```bash
  git verify-pack -v .git/objects/pack/<pack-name>.idx | sort -k 3 -n | tail -n 2
  ```

- List the files in a commit

  ```bash
  git rev-list --objects --all | grep <commit-id>
  ```

- Remove the file and re-write the history

  ```bash
  git filter-branch --index-filter 'git rm --cached --ignore-unmatch <File-to-be-removed>' --tag-name-filter cat -- --all
  ```

- To prune older reflog entries

  ```bash
  git reflog expire --expire=now --all
  ```

- To perform clean up unnecessary files and optimize the local repository

  ```bash
  git gc --prune=now
  ```

Here's a sequence of actions I performed in one of my repositories to reduce the storage. (I didn't reach the storage limit, I performed these steps to demo the idea)

### Identify

Identify the biggest file in the repo

```bash
▶ du -scH                                                                                                                                      
257M    .
257M    total

▶ git verify-pack -v .git/objects/pack/pack-3c30d356e18bda774eb13dc9e53929012ec06800.idx | sort -k 3 -n | tail -n 2
f5ed007fc5ee61733ee9bec25fdeac3f0119644f blob   12362185 12166055 61415659
de3e5b333ba453655951cabdae20588419ef7fe0 blob   18025235 18030628 35112687

▶ git rev-list --objects --all | grep f5ed007fc5ee61733ee9bec25fdeac3f0119644f
f5ed007fc5ee61733ee9bec25fdeac3f0119644f Side_Projects/MemoryTiles/google-play-screenshots-v1-todoriliev.com.sketch/Data
```

### Removal

```bash
▶ git filter-branch --index-filter 'git rm --cached --ignore-unmatch Side_Projects/MemoryTiles/google-play-screenshots-v1-todoriliev.com.sketch' --tag-name-filter cat -- --all
WARNING: git-filter-branch has a glut of gotchas generating mangled history
         rewrites.  Hit Ctrl-C before proceeding to abort, then use an
         alternative filtering tool such as 'git filter-repo'
         (https://github.com/newren/git-filter-repo/) instead.  See the
         filter-branch manual page for more details; to squelch this warning,
         set FILTER_BRANCH_SQUELCH_WARNING=1.
Proceeding with filter-branch...
...
...
Ref 'refs/heads/main' was rewritten
Ref 'refs/remotes/origin/ESI_Archive' was rewritten
Ref 'refs/remotes/origin/main' was rewritten
WARNING: Ref 'refs/remotes/origin/main' is unchanged
Ref 'refs/stash' was rewritten
```

### Clean-up

The git filter-branch command will create backup refs in `.git/refs/original`. These refs must be deleted in order to remove references to these objects. Also, it's good to perform a garbage collection to do some clean-up.

```bash
▶ git for-each-ref --format="%(refname)" refs/original/ | while read ref; do git update-ref -d $ref; done  

▶ git reflog expire --expire=now --all

▶ git gc --prune=now
Enumerating objects: 7802, done.
Counting objects: 100% (7802/7802), done.
Delta compression using up to 10 threads
Compressing objects: 100% (3950/3950), done.
Writing objects: 100% (7802/7802), done.
Total 7802 (delta 4367), reused 6593 (delta 3732), pack-reused 0

▶ git verify-pack -v .git/objects/pack/pack-358d01cc2715da3d0f49ccea3e5d3352e596e7c0.idx | sort -k 3 -n | tail -n 2 
20ca85599c3decf2a972b0ede24ac0a8231b4cd9 blob   7218535 239853 111309837
b9785b3f3b5cddb633e7b2204d08c4bfd32ca501 blob   7608065 7502636 55950582

▶ git push
To github.com:subbramanil/my-dev-notes.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:subbramanil/my-dev-notes.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Documents/personal/my-dev-notes  main ✔                                                                                                                                          2h3m  ⍉
▶ git push -f
Enumerating objects: 7796, done.
Counting objects: 100% (7796/7796), done.
Delta compression using up to 10 threads
Compressing objects: 100% (3312/3312), done.
Writing objects: 100% (7796/7796), 133.17 MiB | 2.66 MiB/s, done.
Total 7796 (delta 4364), reused 7795 (delta 4364), pack-reused 0
remote: Resolving deltas: 100% (4364/4364), done.
To github.com:subbramanil/my-dev-notes.git
 + 734e92e...71bd9bb main -> main (forced update)

▶ du -scH
212M    .
212M    total
```

Reducing a repo size from 257 MB to 212 MB (45 MB) may not look like a big saving, however, the approach can be applied repeatedly to remove the bigger files to reduce the size of the repo.

---

I found out there there are two alternatives to achieve similar results. I will write a follow-up blog on these two.

- [git filter-repo](https://github.com/newren/git-filter-repo/) (As noticed in the command line logs of `git filter-branch`)
- [BFG](https://rtyley.github.io/bfg-repo-cleaner/)

---

## References:

- [Post-1](https://support.acquia.com/hc/en-us/articles/360004334093-Removing-large-files-from-Git-without-losing-history)
- [Post-2](https://link-intersystems.com/blog/2014/07/17/remove-directories-and-files-permanently-from-git/)
- [StackOverFlow Post](https://stackoverflow.com/questions/11050265/remove-large-pack-file-created-by-git)

---

*[This post is also available on DEV.](https://dev.to/subbramanil/slimming-down-repo-1-3kcd)*


How can we reduce the repo size when it exceeds the size limit imposed by the repoitory hosting site

Slimming Down Repo-1


When you are a nerd, What do you do to show your love?

As I was cleaning up my storage space in my apartment, I found my old cache of IoT related materials. Breadboards, Resistors, Capacitors, LEDs, Different types of sensors, Raspberry PIs & Arduino, and of course, lots of jump-wires. I used to play around with sensors, making a lot of fun with my roommates at college. Seeing that I had a few hours available over the weekend, I thought of setting up at least one sensor and test it out.

I typically use Raspbian for the ease of installation & familiar Debian environment. I downloaded the image, flashed to SDCard. I had no extra monitor at home, so I planned to login via SSH to my Raspberry Pi. I came to It's been a while since I used Raspbian, I didn't realize Raspbian has updated their security & blocked ssh on boot. I found out the correct way to enable SSH on boot & logged in.

I had a bunch of motion sensors, and I was quickly able to put it together and test it out with one of my old programs for motion testing. I showed it to my wife; Having a Bachelor of Engineering in an Electronics, the demo didn't impress her a lot. In any case, I was happy that I didn't lose touch.

I wanted to do something a bit more fun, and I found an LED matrix in the cache, which I didn't remove from the package. (Guess, I planned to do something with it but closed the shop even before trying it out).

I typically prefer *node.js* for working on IoT projects. Looking for an npm package to work with LED matrix, I found several, but none seem promising (Most of them weren't up to date & I lost patience before getting them work). Then I came across the Python library **luma-led-matrix**, which was pretty quick to set up & had a bunch of examples that work.

## Details of implementation

### Hardware Required

- Raspberry PI 2/3/4
- MAX7219 8*8 LED matrix
- Jumper wires

### Software Required

- Raspbian OS
- Luma LED Matrix library

### GPIO pin-outs

| Board Pin | Name | Remarks     | Rpi pin | Rpi function      |
| --------- | ---- | ----------- | ------- | ----------------- |
| 1         | VCC  | +5V Power   | 2       | 5V0               |
| 2         | GND  | Ground      | 6       | GND               |
| 3         | DIN  | Data In     | 19      | GPIO 10 (MOSI)    |
| 4         | CS   | Chip Select | 24      | GPIO 8 (SPI CE0)  |
| 5         | CLK  | Clock       | 23      | GPIO 11 (SPI CLK) |

For more details:
[luma-led-matrix documentation](https://luma-led-matrix.readthedocs.io/en/latest/)

I had to enable SPI, and there are enough tutorials on how to do it. Here's the one I followed: [Sparkfun Tutorial on Enabling SPI on RaspberryPI](https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial# spi-on-pi)

I showed my wife the demo of one of the examples, and she was a bit impressed.

The following day was '*her*' day (meaning she can sleep as much as she wants and get up when she wants). So before I get to work, I changed the program to print, "I love you Mahi" & put it in a loop and left.

I received a text from her around lunchtime that she loved it. Finally **Yeah!!**

I'm sure that I'm not the only nerd who wanted to show off to loved ones.  What's your experience in doing so?

*[This post is also available on DEV.](https://dev.to/subbramanil/show-love-through-tech-1bik)*


When you are a nerd, What do you do to show your love?

Show Love Through Tech


The recipe we follow at my work for automating android app publishing is bitbucket + Teamcity + Fastlane + slack.

Choosing Fastlane for automatic publishing mobile apps to the store is no wonder. It's the most preferred way to publish apps automatically.

We use TeamCity for CICD at our work, We looked at a few of the cloud solutions for CICD, but finally, we opted to use TeamCity Professional Version as our CICD tool. It's free to use and 3 build agents with 100 build configurations which were more than enough for our purposes. And comparatively, We felt it was way easier to set it up and configure than Jenkins.

Of course, Jenkins has been there for a while and may have more community support and plugins than TeamCity, TeamCity felt easy to manage without a dedicated person for support. We did play around several other CICDs but finally settled with TeamCity.

Fastlane is officially supported to run on macOS, and it seems like Windows & Linux Support is coming up.

Since our TeamCity server (& the in-built build agent) was running on Ubuntu 14.04, We needed to install Fastlane in the same machine. The installation instructions for Fastlane on Ubuntu 18.04 is easy to find in [comments of an issue](https://github.com/fastlane/fastlane/issues/11687# issuecomment-489891745).

Here are the installation steps for Ubuntu 18.04 from the comments.

1. Install ruby and ruby-dev headers

```bash
sudo apt install ruby ruby-dev
```

2. Set environment language variables. Add these lines to the top of ~/.profile

```bash
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
```

3. Check that you didn't break the environment and restart. Run ```source ~/.profile``` in the terminal. If no output, you are safe. Otherwise, check for what you broke in the .profile file

4. Install Fastlane

```bash
sudo gem install fastlane
which fastlane  // Verify
```

5. From there do the normal [Fastlane Setup](https://docs.fastlane.tools/getting-started/android/setup/)

I ran into some issues while doing this setup. Some of the Gotchas while doing this.

- Make sure to install Ruby 2.x version

```bash
sudo apt-add-repository ppa:brightbox/ruby-ng
sudo apt-get update
sudo apt-get install ruby2.4
ruby -v // Verify
sudo apt-get install ruby2.4-dev
```

- Depends on your Ubuntu 14.04 environment, Sometimes the following needs to be installed

```bash
sudo apt-get install libc6-dev
sudo apt-get install g++
```

- Fastlane uses the Google API client to communicate with the Google Play Console Services. I noticed this issue, '*Missing Google API Client*' when installing Fastlane.

```bash
gem install google-api-client -v 0.29.1
```

That should be it, Hope that helps.

**P.S:** I wrote the draft of this blog a very long time ago and left it to pickle :D. I just decided to publish it after correcting the grammatical and misspelled words. Some of the errors may have been fixed.


*[This post is also available on DEV.](https://dev.to/subbramanil/fastlane-setup-in-ubuntu-2dfb)*


The recipe for automating android app publishing: bitbucket + Teamcity + Fastlane + slack.

Fastlane Setup in Ubuntu


Yeah, I did it, 2nd time completing Hacktoberfest. It's been extra fun working on Hacktoberfest this year (extra special coz., I had loads of fun working on a puzzle game in android).

First of all, Huge thanks to **DigitalOcean** and **dev.to** for organizing the Hacktoberfest 2019. Of course, the primary objective of my participation is to get the cool T-Shirts & Sticker and a self-gratifying of human behavior of achieving something. But along the way, I felt a bit happy about contributing to somebody's work and giving it back to the community.

It all started with one of our dev.to community buddy 
[Beautus S Gumede's question](https://dev.to/sduduzog/how-to-write-tests-for-an-android-app-3041) regarding how to write test cases a year back.

I was much more active in 'dev.to' than nowadays. What started as answering to a question, led me to [complete Hacktoberfest in 2018.](https://dev.to/subbramanil/hactoberfest-challenge-completed-e49)

I started this year early. So the Hacktoberfest plan for this year is.

```markdown
# Plan

- [x] Identify repos to contribute (Criteria: Android, Java/Kotlin, Easy/Medium difficulty)
- [x] Follow best coding practices & use conventional commits for git commits
- [x] Submit PRs
- [x] Get the HacktoberFest T-Shirt
```

## Learnings

### Lesson 1: You can learn a lot of new things when you review a repo & fix/add things

#### Issue

- [https://github.com/vislyhq/rust-android-example/issues/1](https://github.com/vislyhq/rust-android-example/issues/1)
- [https://github.com/theaiscope/GDD-app/issues/16](https://github.com/theaiscope/GDD-app/issues/16)

Several of my PRs focussed on improving the existing code by addressing lint warnings & suggestions based on my experience. Most of the lint warnings are pretty evident, and the android studio can help in resolving those. The below one was something I didn't come across and was glad to be bumped with the error. It allowed me to learn something new.

While working on the 'MEME' app, I came across the below deprecation as a result of running 'lint.'

```Environment.getExternalStorageDirectory() is deprecated in SDK 29```

From a quick [research](https://commonsware.com/blog/2019/06/07/death-external-storage-end-saga.html), found out **baseContext.getExternalFilesDir("directory_name_to_create")** can be used. And from the logs, able to understand the differences of their implementation as well.

```log
10-15 15:31:05.328 27301-27301/com.example.lenovo.meme D/Test: Directory Path: baseContext.getExternalFilesDir("Meme"): /storage/emulated/0/Android/data/com.example.lenovo.meme/files/Meme
10-15 15:31:05.333 27301-27301/com.example.lenovo.meme D/Test: Environment.getExternalStorageDirectory(): /storage/emulated/0
```

#### Pull Requests

- [https://github.com/theaiscope/GDD-app/pull/20](https://github.com/theaiscope/GDD-app/pull/20)
- [https://github.com/vislyhq/rust-android-example/pull/2](https://github.com/vislyhq/rust-android-example/pull/2)
- [https://github.com/harshsri2208/MEME/pull/11](https://github.com/harshsri2208/MEME/pull/11)


### Lesson 2: Be conscious of the boundaries when proposing the changes & ask first

#### Issue

- [https://github.com/harshsri2208/MEME/issues/6](https://github.com/harshsri2208/MEME/issues/6)

Also, one thing I learned this year was to be conscious of the boundaries & propose the changes. Although the primary goal of an owner/maintainer of a repository to get their bugs fixed, the implementation we provide may not align with what they need/requirements some times.

While working on this 'MEME' app, the question the maintainer was related to the UI/UX change. I had a pretty good idea for the UX flow, so I planned to work on it. However, I noticed that the app was written in Java, and as Google has been promoting Kotlin, I felt it would be better to migrate to 'Kotlin.' So I migrated the app from Java to Kotlin and worked on my idea and submitted PR.

But as I was working, I realized that I didn't check with the maintainer if he wished to migrate to 'Kotlin.' I opened up a discussion with the maintainer, and as I expected, he didn't want to migrate to Kotlin. No hard feelings; of course, the maintainer of a repo retains the right to decide what's best.

In any case, I submitted the PR as I wanted to increase the hacktoberfest count (to be honest). I added the idea & shared a video of the new UX in the comments, in case the maintainer wants to take a look.

I wish I asked the maintainer before starting working on the issue if he wanted to migrate the app from Java to Kotlin. In any case, it was fun to work.

### Lesson 3: Contributing is more fun when you work on a game

#### Issue

- [https://github.com/nikhilbansal97/Memory-Game/issues/1](https://github.com/nikhilbansal97/Memory-Game/issues/1)

The most fun I had was working on this repo: Memory-Game, which was a single screen memory based puzzle game. The repository was already in 'kotlin,' and I got a couple of ideas of extending the concept. I proposed a simple idea of providing 'difficulty' and let the user choose and play. Another idea was to allow the user to start at the beginner level and increase the difficulty as he finishes each level. I submitted PRs for both, and It was enjoyable working on this app.

#### Pull Requests

- [https://github.com/nikhilbansal97/Memory-Game/pull/12](https://github.com/nikhilbansal97/Memory-Game/pull/12)
- [https://github.com/nikhilbansal97/Memory-Game/pull/13](https://github.com/nikhilbansal97/Memory-Game/pull/13)
- [https://github.com/nikhilbansal97/Memory-Game/pull/14](https://github.com/nikhilbansal97/Memory-Game/pull/14)

![Hacktober Completion Status](https://thepracticaldev.s3.amazonaws.com/i/5z9thiaimjwhb9lf9tzt.png)

*[This post is also available on DEV.](https://dev.to/subbramanil/hacktobeferfest-2019-completed-lc1)*


HacktobeferFest:2019 Completed


In the recent Google I/O, Google announced **Kotlin** to be the first choice language for writing Android apps. Since few years before Google announced that, **Kotlin** is preferred language and added kotlin support to the android studio, this news doesn't come as a surprise for me.

When the announcement came a year ago, I registered for many courses, finished a couple of them. I felt good about completing the exercises & sample projects. However, It lasted only for a while. With my personal (got married to a wonderful girl) & work commitments doubled(they let go of a few folks at my work), I took a break from learning kotlin.

When I started again, I struggled a lot and confused as to where to start again, as I was in the middle of several kotlin courses. Although the courses I registered to learn kotlin were pretty good, I realized that I'm more of a reading person. I don't mind reading documentation or several blogs to understand a concept and try out on my own. Watching a video course and following along a tutorial felt too slow for me.

I worked on small projects as I was learning. Although the personal projects were helpful to understand the fundamentals, it had few challenges.

  1. **Focus on scope:** It was up to me to decide the scope of the project. Sometimes I tend to expand on my idea on personal projects, and I spent more time on things that weren't relevant to kotlin.
  2. **Focus on Technology Stack:** Again, it's up to me to decide the architecture and design of the app, the libraries to use. While identifying answers to these technical questions, I lost track of my goal(which is learning Kotlin). For ex., I lost loads of time when I started with the goal of looking for blogs related with data classes and somehow followed blogs on sample apps that are built using the MVVM + RxKotlin + Dagger2. Although it is good to learn about this setup, it wasn't contributing directly to my original goal.

That's when I decided to start learning Kotlin again from scratch, but this time with a better clear plan.

So the mistakes that I did earlier in learning Kotlin were,

1. Trying to learn Kotlin from too many sources
2. Didn't start with what's working out well for myself (Reading vs. Video courses)
3. Didn't have a plan with a defined schedule
4. Didn't have a defined scope on personal projects

I learned from my experience and created a plan.

**Goal:** To Learn & develop an App in Kotlin and publish to the store by Sep 2019

The plan to do that,

1. Buy a book for learning Kotlin: [Kotlin Programming: The Big Nerd Ranch Guide](https://www.amazon.com/Kotlin-Programming-Nerd-Ranch-Guide/dp/0135161630)
2. Work on Personal project with limited scope: An Android App
   1. Outlined the basic idea of the app
   2. Identified the functionality scope of the app
   3. Identified the technology scope of the app
   4. Designed simple UI/UX flow using sketch app

## Learn by Contributing to open source

I have participated in Hactoberfest last year and contributed to [Slim-Launcher](https://github.com/sduduzog/slim-launcher) app by [Beautus S Gumede](https://dev.to/sduduzog). I [completed my Hactoberfest challenge](https://dev.to/subbramanil/hactoberfest-challenge-completed-e49) and got my T-Shirt as well. It felt good to give back to the community.

When looking back,

1. I learned a lot while working on the project. The app uses Kotlin, and It was a good exercise for me to flex my skills.
2. The app was published to store and had a defined technical scope to it. It helped me to focus on one thing and work within the boundary.
3. I thoroughly enjoyed interacting with the project developer Beautus S Gumede and working on the project. While we both were strangers, connected through his blog on dev.to, I enjoyed working on his project and liked the candidness and the appreciative character of Beautus S Gumede.

This exercise made me realize that I could learn a lot more by working on projects with definitive design and functionality. I could look into the code, fix a bug, or add a feature and learn from the project.

This had led me to add one more step to my learning plan,

1. Buy a book for learning Kotlin
2. Work on Personal project: Android App
3. **Contribute to open source projects**

So far, I have contributed to,

- [Slim-Launcher](https://github.com/sduduzog/slim-launcher)
- Fork of [Android-Lock9View](https://github.com/TakWolf/Android-Lock9View)
- [Dev-Android](https://github.com/subbramanil/DEV-Android)

Currently, I'm working on an enhancement request in the projects,

- [Simple ToDo](https://github.com/subbramanil/SimpleToDo)
- [Simple-Android](https://github.com/subbramanil/simple-android)

I typically make notes of my learnings as I work on a project, and I plan to write a series of blogs once the PRs are submitted and merged.

**Note:** I found out about the repositories through Github "Discover Repositories" feature. However, now that we have a listing in 'Dev.to,' I'm going to create a listing for volunteering to work on open source Android/kotlin based projects where I can contribute and learn as well. (Although, I'm going to delay that until I finish my current commitments)

*[This post is also available on DEV.](https://dev.to/subbramanil/learn-by-contributing-to-open-source-4kf)*


Learn Programming by Contributing to Open Source

Learn by contributing to Open Source


- Thanks to DigitalOcean, Github, Twilio for organizing the # HacktoberFest event
- Thanks to *Beautus S Gumede* for [the repo](https://dev.to/embed/github?args=sduduzog%2Fslim-launcher)

- Thanks to Dev.to community, as there was never a day without a post on **# hactoberfest**. It helped as encouragement and sort of reminder.

My original plan was to submit PRs for documentation for some repositories. However, then I moved to repositories related to Android since I can contribute some of my skills. As I was looking for a repo, I came across this [post](https://dev.to/sduduzog/how-to-write-tests-for-an-android-app-3041), and the repo became my choice for HactoberFest Challenge.

### Why I chose the repo

- First, it's an Android App at early stages. It provided an opportunity to add features while exercising my android skills.
- I am working on a feature at work based on the idea from the app. So it's only fair, I give back something.
- The app is written in Kotlin, which helped me to understand and practice writing code in Kotlin. At my work, We are still in the early phases of moving from Java to Kotlin (less than 5% progress).
- Finally, It felt good to answer in a more practical way for the question asked in the post.

### What did I learn from this

- A bit more of Kotlin, how simpler to do few things compared to java.
- Espresso UI Testing: We are planning to add Espresso UI testing at work, and it helped me practice a bit.
- Continuous Integration and how to integrate [CircleCI](https://circleci.com) for Android apps. I have tried **CircleCI** before, so it didn't take much time to do for the second time. However, I paid a bit more close attention to configuration details this time and learned a couple of new tricks.
- I came to know about [Codacy](https://www.codacy.com) through a senior colleague, and find it very useful in analyzing the code quality when practicing with this app.
- Codacy provides code analysis through different static code analysis tools like PMD, CheckStyle. As I was fixing the warnings provided by Codacy, I sometimes need to refer to Java/Kotlin docs to make the fixes. I learned a bit more on Kotlin [reified type params](https://kotlinlang.org/docs/reference/inline-functions.html# reified-type-parameters).
- I have never used, 'git squash' before; I usually create multiple smaller commits, but when I submit the PR, I tried git squash to squash all smaller commits into one.

### List of references as I was working on PRs

- [Testing DB from Android Developer](https://developer.android.com/training/data-storage/room/testing-db)
- [ProAndroidDev Article on Testing Android Architecture Compoennt: Room](https://proandroiddev.com/testing-the-un-testable-and-beyond-with-android-architecture-components-part-1-testing-room-4d97dec0f451)
- [CircleCI Integration](https://circleci.com/docs/2.0/language-android/)
- [ProAndroidDev Article on CircleCI Integration](https://proandroiddev.com/circleci-with-android-continuous-integration-3ecd98f92bd)
- [Espresso UI Testing](https://developer.android.com/training/testing/espresso/)

### HactoberFest Plan

```md
- [x] Submit PRs for slimlauncher and get 'hacktober' t-shirt
  - [x] PR-1: Initialize Testing Framework
  - [x] PR-2: CircleCI integration
  - [x] PR-3: UI Testing using Espresso Framework
  - [x] PR-4: Improve Code Quality using Codacy
  - [x] PR-5: ~~Firebase Test lab~~ Grid Layout for listing apps
  - Bonus: Fix Readme
    - Add Screenshots
    - Add Build status
        [![CircleCI](https://circleci.com/gh/subbramanil/slim-launcher.svg?style=svg)](https://circleci.com/gh/subbramanil/slim-launcher)

- [x] Add comments in [original post](https://dev.to/sduduzog/how-to-write-tests-for-an-android-app-3041)
- [x] Write a post on sharing the HactoberFest experience and Thank the community
```

### What my plan from now on

It was the first time I have contributed to the community through Github. Through the experience, I enjoyed the learning process and the satisfaction when the changes you proposed gets merged.

I am going to watch out to the posts by **Ben** on *Who's looking for open source contributors?* and contribute at least once a month.

*[This post is also available on DEV.](https://dev.to/subbramanil/hactoberfest-challenge-completed-e49)*


Thanks to DigitalOcean, Github, Twilio for organizing the #HacktoberFest

HactoberFest Challenge: Completed


# Be aware of ADB

As I was responding to the questions in this [article](https://dev.to/embed/link?args=https%3A%2F%2Fdev.to%2Fexadra37%2Fandroid-devices-being-shipped-with-tcp-port-5555-enabled-1ig5)
 I realized, I couldn't summarize my answer into comments. So I figured I would write a separate blog.

The intention is to highlight the overlooked point of the original [article](https://doublepulsar.com/root-bridge-how-thousands-of-internet-connected-android-devices-now-have-no-security-and-are-b46a68cb0f20) about the attacks through ADB. Although what the article claims could be true, I felt it is a bit misleading. Researching android devices under a specific region(which is famous for rooted devices/custom android images), the article seems to generalize the issue. It does mention,

> It is also clear some people are insecurely rooting their devices, too.

But doesn't seem to highlight it as the major issue. I completely agree where it's the vendor's fault to ship devices with 'ADB' enabled, the scenario where the device runs a rooted custom android escalates the issue to another level.

Just looking at the title & the fancy technical terms, a novice android user would get scared if not concerned a bit about his privacy. Nowadays, where hacking seems to occur almost every day, I don't blame anyone when they hear the words, "android" & "hack" together, get scared or worried about their privacy. I want the people to know about how 'ADB' tool works so that they can better understand when hearing about issues related to ADB and make an informed decision rather than jumping to conclusions.

**Note**:

1. Please note that I'm not saying Android is secure. It has multiple layers of protection; But like any other systems, it's not immune to attacks.
2. Security in Android is a vast topic, and I'll try to cover as much as I can be based on my experience. Please feel free to add upon more info and correct if there are any mistakes.

As per the original [article](https://www.securityweek.com/many-android-devices-ship-adb-enabled), it claims that the several vendors(specific to a region) ship Android with ADB enabled. Which then enables a hacker to connect over TCP (Wifi/Ethernet), to hack the device and steal user information. It's certainly true that when 'ADB' is enabled on a device, it's quite easy to connect to the device over TCP if you know the IP address of the device. But how much the hacker can do once he gets access to the device depends on if the android was a rooted or non-rooted device.

## Be aware when you root the device

When connecting through ADB on a rooted android device(i.e., device that runs custom android images rather than the factory defaulted image), the user has elevated 'root' permissions. So the hacker has the potential to run commands that compromise the security/privacy of the user. So one should be aware of flashing custom images on your phones. The image may have enabled "USB Debugging" by default and even worse, "enabled USB Debugging over TCP" through 5555 or any other ports. It basically opens the doors for the hacker to use the phone as they wish.

In the case of non-rooted Android devices, "ADB Access" is disabled by default and has to be enabled through a process. Although the process is not complicated, it's not something a common person can stumble upon. I will walk through the steps shortly. One more thing to note here is, *even if you enable ADB connection in a non-rooted Android device when you connect from a PC, you will not have "root" access in the shell*.

### What a normal user familiar with

When you connect an Android device to a PC, it typically connects in MTP(Media Transfer Protocol) mode. You can transfer files/photos/music between the device and the PC. Most of the manufacturer provided software connects through this mode. eg., [Samsung Smart Switch](https://www.samsung.com/us/smart-switch/), [Android File Transfer](https://www.android.com/filetransfer/).

### How ADB works

For our exercises, you need an android device(or an emulated Android device), a micro-USB cable & ADB, the developer tool in question. I'm using an Emulated Nexus 5.

'Android Debug Bridge-ADB' is a tool that helps in communicating between the device and PC, which can be obtained by installing [Platform tools](https://developer.android.com/studio/releases/platform-tools). For more details on 'ADB', you can read this [article](https://developer.android.com/studio/command-line/adb) from [developer.android.com](https://developer.android.com/).

#### Practice-1: Enabling ADB Access

If you want to enable 'ADB', you have to first enable "Developer Settings", Which is actually hidden in Settings.

1. Open Settings in your Android device
2. Find "Build Number" in "About Phone" and tap it "7" times. It will show a notification that "Developer Settings" is now enabled.
3. Press back to return to settings, and you will see "Developer Settings".
4. Open "Developer Settings", scroll down to "USB Debugging" and enable it.

Now you will have ADB access to the device.

**Note**: If you like to enable ADB Connection over Wifi, the same [article](https://developer.android.com/studio/command-line/adb) from developer.android.com covers how to do that as well. For our exercise, it doesn't matter whether you connect over WiFi or micro-USB.

Android adds another level of security. When you connect your device to a PC after enabling ADB, it will ask permissions to "Trust the Computer".

![Screenshot from device](https://www.embarcadero.com/starthere/xe5/mobdevsetup/android/en/300px-AndroidEnableUSBDebuggingDialog.png)

![Screenshot from developer.android.com](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/Info+from+Android+Developer+Website.png)

#### Practice-2: Understanding the android shell & methods to communicate

In simple words, "shell" is just an interface that lets you talk to the underlying OS. Android has a Unix shell that can talk to the underlying kernel.
Based on the toolset available, the list of commands can vary. ADB is just a tool that communicates your commands to the android shell.

Before we start a bit of practical explanation. You can execute the commands in two ways. For ex., 'ls' is a shell command that lists the files & directories in the current path.

1. From your PC, Get into the shell and fire the 'ls' command.

```bash
> adb shell
> $ ls
```

When you fire, 'adb shell', you will get into android's shell. Type, '*exit*' to exit from the android shell to PC.
2. From your PC, Fire the 'ls' command through the shell. You will remain in your PC's shell.

```bash
> adb shell ls
```

**Note**: In this article, I'm currently using 'ADB' to connect to the android shell. 'ADB' has more commands that can let you install, uninstall, query apps and much more.

#### Practice-3: Understanding ADB Users

You will not get "root" access on standard non-rooted android devices. You can only run a limited set of UNIX commands.

- On non-rooted device,

```bash
▶ adb shell
generic_x86:/ $ pwd
/
generic_x86:/ $ ls
ls: ./ueventd.rc: Permission denied
ls: ./ueventd.ranchu.rc: Permission denied
ls: ./init.zygote32.rc: Permission denied
ls: ./init.usb.rc: Permission denied
ls: ./init.usb.configfs.rc: Permission denied
ls: ./init.rc: Permission denied
ls: ./init.ranchu.rc: Permission denied
ls: ./init.environ.rc: Permission denied
ls: ./init: Permission denied
ls: ./fstab.ranchu.early: Permission denied
ls: ./fstab.ranchu: Permission denied
acct bugreports cache charger config d data default.prop dev etc mnt oem proc root sbin sdcard storage sys system var vendor
```

Please note the '$' sign. This implies that you logged in as Normal User. You will have limited permissions to run commands.

- On a rooted device,

```bash
root@xxxx:/ # ls
acct
bin
cache
charger
config
d
data
default.prop
dev
device
etc
file_contexts
fstab.freescale
init
init.environ.rc
init.xxxx.rc
init.xxxx.usb.rc
init.rc
init.trace.rc
init.usb.rc
mnt
proc
property_contexts
res
root
sbin
sdcard
seapp_contexts
sepolicy
storage
sys
system
ueventd.xxxx.rc
ueventd.rc
vendor
```

Please note the '# ' sign. This implies that you logged in as root/admin User. You have elevated permissions.

This is one level of security. Unless you have a rooted android device, you will not gain 'root' permission when connecting over 'ADB' be it over Wifi or Micro-USB. Also based on the toolset([busybox](https://busybox.net/about.html), [toolbox](https://elinux.org/Android_toolbox)) available in your Android device, the list of commands available to a root user will also vary. Of course, once you have a root user, you can install more commands.

To give another example, There's a partition '/data' in Android, where the apps store their data.

- In a typical non-rooted android device,

```bash
generic_x86:/ $ ls /data
ls: /data: Permission denied
```

'/data' partition is disabeld by default

- In a rooted android device

```bash
root@xxxx:/ # ls /data
anr
app
app-asec
app-lib
app-private
backup
bugreports
cron
dalvik-cache
data
dontpanic
drm
local
lost+found
media
mediadrm
misc
network
property
resource-cache
security
ssh
system
tombstones
user
```

#### Practice-4: Understanding App level security

All applications on Android run in an Application Sandbox. By default, an Android application can only access a limited range of system resources. The access to system resources is protected by permissions provided to the app.

So any time when you install an app, review the permissions when you install an app. With the recent Android releases, android started rolling out asking permissions separately each time, when the app tries to access a system resource eg., Camera.

Each app runs on its own sandbox, it can't access 'data' portion of other apps. We saw earlier in a non-rooted device, access to '/data' portion is disabled.

There's one exception. If you install an app through 'ADB', you can access the 'data' portion of that particular app. Note that the app has to be designed for debugging, to be more specific it should be an apk for debugging.

```bash
generic_x86:/ $ run-as com.xxx.androidarchroom ls com.xxx.androidarchroom
ls: com.xxx.androidarchroom: No such file or directory
generic_x86:/ $ run-as com.xxx.androidarchroom ls /data/com.xxx.androidarchroom
ls: /data/com.xxx.androidarchroom: No such file or directory
generic_x86:/ $ run-as com.xxx.androidarchroom ls -ls /data/data/com.xxx.androidarchroom
total 12
4 drwxrws--x 2 u0_a85 u0_a85_cache 4096 2018-09-27 13:02 cache
4 drwxrws--x 2 u0_a85 u0_a85_cache 4096 2018-09-27 13:02 code_cache
4 drwxrwx--x 2 u0_a85 u0_a85       4096 2018-09-27 13:02 databases
```

Note that the app, 'androidarchroom' has user-id as 'u0_a85'. Also note that it can only access it's own data folder.

Another example,

```bash
generic_x86:/ $ run-as com.xxx.voicemails ls -la /data/data/com.xxx.voicemails
total 20
drwx------   4 u0_a79 u0_a79       4096 2018-10-04 04:54 .
drwxrwx--x 103 system system       4096 2018-10-04 04:54 ..
drwxrws--x   2 u0_a79 u0_a79_cache 4096 2018-10-04 04:54 cache
drwxrws--x   2 u0_a79 u0_a79_cache 4096 2018-10-04 04:54 code_cache

generic_x86:/ $ run-as com.esi.androidarchroom ls /data/data/com.esi_estech.voicemails
ls: /data/data/com.esi_estech.voicemails: Permission denied
```

Here, the 'voicemails' app has user-id as 'u0_a79'. And notice how, 'androidarchroom' app can't access the 'data' of 'voicemails' app. Both apps runs on it's own sandbox and the users are different which controls the permissions.

Both of the above two apps are my development apps and I was running a debug apk. The APKs that you get from play store is of 'release' type which can't be debugged. Let's see what happens when I run on an app that's pre-installed/installed from play store.

```bash
generic_x86:/ $ run-as com.google.android.youtube ls /data/data/com.google.android.youtube
run-as: package not debuggable: com.google.android.youtube
```

So I can't access the 'data' of youtube app.

The above examples are true in case of the non-rooted device. In case of a rooted device, you can pretty much access 'data' portion of any app.

**Note**: People who have used Unix machines are familiar with the security concept '[DAC](https://en.wikipedia.org/wiki/Discretionary_access_control)' which is used in Android as well.

## Potentials for a hack

Okay, now after explaining a portion of android's security measures, let's see what's the potential options to hack in a non-rooted Android device over adb.

### Shell commands

If you understand UNIX commands, there's a basic set of commands available through which you can poke around and find information about the device. Even as a normal user, you have access to run basic commands in certain directories. For ex.,

```bash
generic_x86:/ $ ls
ls: ./ueventd.rc: Permission denied
ls: ./ueventd.ranchu.rc: Permission denied
ls: ./init.zygote32.rc: Permission denied
ls: ./init.usb.rc: Permission denied
ls: ./init.usb.configfs.rc: Permission denied
ls: ./init.rc: Permission denied
ls: ./init.ranchu.rc: Permission denied
ls: ./init.environ.rc: Permission denied
ls: ./init: Permission denied
ls: ./fstab.ranchu.early: Permission denied
ls: ./fstab.ranchu: Permission denied
acct bugreports cache charger config d data default.prop dev etc mnt oem proc root sbin sdcard storage sys system var vendor
```

You can poke around with different UNIX commands, although the set of commands will be limited.

## Android Tools

Android adds a set of tools on top of the UNIX shell, which can be used to understand the list of the apps the user has and launch the apps.

For ex., 'pm' [Package Manager](https://developer.android.com/studio/command-line/adb# pm) is a tool that can query packages.

```bash
generic_x86:/ $ pm list packages -f
package:/system/priv-app/CtsShimPrivPrebuilt/CtsShimPrivPrebuilt.apk=com.android.cts.priv.ctsshim
package:/system/app/YouTube/YouTube.apk=com.google.android.youtube
package:/system/priv-app/GoogleExtServices/GoogleExtServices.apk=com.google.android.ext.services
package:/system/priv-app/TelephonyProvider/TelephonyProvider.apk=com.android.providers.telephony
...
```

By understanding the list of packages available, You can further perform a bunch of more actions. For example, clearing data of an app.

```bash
130|generic_x86:/ $ pm clear com.google.android.youtube
Success
```

Launch an app from command line,

```bash
generic_x86:/ $ pm dump com.android.calculator2 | grep -A 1 MAIN
    android.intent.action.MAIN:
      b91fd0a com.android.calculator2/.Calculator filter 84c5cb
        Action: "android.intent.action.MAIN"
        Category: "android.intent.category.LAUNCHER"
generic_x86:/ $ am start -n com.android.calculator2/.Calculator
Starting: Intent { cmp=com.android.calculator2/.Calculator }
```

### Analyzing logs

"Logcat" is a tool that prints the logs of the apps installed including system apps. Although it's a tedious process, one can watch the logs for potential user related info. For eg.,

```bash
generic_x86:/ $ logcat | grep http
10-04 05:30:41.470  7966  7998 W GAv4: AnalyticsReceiver is not registered or is disabled. Register the receiver for reliable dispatching on non-Google Play devices. See http://goo.gl/8Rd3yj for instructions.
10-04 05:30:41.478  7966  7998 W GAv4: CampaignTrackingReceiver is not registered, not exported or is disabled. Installation campaign tracking is not possible. See http://goo.gl/8Rd3yj for instructions.
10-04 05:30:41.479  7966  7998 W GAv4: AnalyticsService not registered in the app manifest. Hits might not be delivered reliably. See http://goo.gl/8Rd3yj for instructions.
```

### App vulnerabilities

Apps released through the play store will not have any 'debug' logs and the logs are limited to 'error'. But it doesn't prevent the developer from printing sensitive information in the error logs. Also, Google does scan the uploaded apps before releasing, there could be potential vulnerabilities in the apps. A malicious user can make use of the app vulnerability to steal user information.

Overall,

> 1. Be wary of the system images that you flash and careful if and when you root your android device.
> 2. Be wary of the apps that you install through non-standard way(downloading from other sites, shared through links).
> 3. Be aware of the permissions that the apps request, when you install the apps from play store.
> 4. Don't enable ADB access, unless you develop. Rather I would put be conscious when you enable ADB access.

In my opinion, ADB and other tools exist to debug, resolve and develop better apps. It's not the fault of the tools if they are used for malicious purpose. Most often it's us the users who open doors for potential attacks.

*[This post is also available on DEV.](https://dev.to/subbramanil/understanding-android-device-bridge-3i2c)*


Being aware of the ADB tool can help in understanding the attacks on Android

Understanding Android Debug Bridge


# Git branching strategy

We use 'git' for our version controlling with Bitbucket as our hosting provider.

Recently I was asked to make as admin for bitbucket for the team, as the person who manages is leaving the company. I was doing some clean-up of branches, and I found out that there were lots of branches which wasn't deleted after merging. Also, it gave me an opportunity to review our branching strategy used by our team.

I would like to share the strategy we use with the hope that it could help somebody. I also would like to get any feedback or suggestions that could help us to improve the strategy.

We use two strategies for branching.

## Feature Development

![Feature Development branching strategy](https://s3-us-west-2.amazonaws.com/my-blogresources/Feature_development_branching_strategy.png)

## Bug Fixing

![Bug Fixing branching strategy](https://s3-us-west-2.amazonaws.com/my-blogresources/Bug_fix_branching_strategy.png)

**Note:** For simplicity, I only added the main commit points made on merging/releasing.

### Master branch

- This is the main branch of the repository from which we make releases to the store or to the release server.
- General Rules:
  - Access is restricted.
  - Changes can be submitted only through Pull Requests. No direct commits are allowed.
  - Should always have the latest release version on store/production release server.
  - Should never have unreleased code(commits made but not yet released).

### Develop branch

- This is the main 'development' branch of the repository from which we make alpha/beta releases. This branch is based on the 'master' branch on creation. It tracks the current development.
- General Rules:
  - Access is restricted.
  - No direct commits are allowed under normal circumstances. If a situation arises, direct commits can be made with the approval of the entire team.
  - Changes can be submitted through Pull Requests.
  - During a feature development, no pull requests should be made from user branches to develop directly. Pull requests are made from feature branches to 'develop'. (user_branch --> feature_branch --> develop)
  - Pull requests should be approved by all the team members.
  - Should always have the latest alpha/beta release version. It shouldn't have unreleased code(Commits made but not released yet).
  - Base branch for user/feature branches.

### Feature branches

- This is the main branch for the feature under development. This branch is based on 'develop' branch on creation. As we work on a new feature, we create a feature branch as 'develop_feature' based on the 'develop' branch. Until the completion of the feature, 'develop_feature' branch will serve as the base branch for development.
- General Rules:
  - Access is restricted.
  - Direct commits are allowed as long as the changes are minor(eg., release version change or signing keys change) or there is only one person working on the feature branch.
  - Changes can be submitted through Pull Requests.
  - Pull requests should be approved by all the team members(Interns are optional if their work schedule doesn't fit).
  - Should always to be merged back to 'develop' after completing the feature. It shouldn't have commits that aren't merged with 'develop' after completion of the feature.
  - Feature branches are eligible for deletion once they are merged into 'develop' branch and tagged appropriately. Feature branches can be deleted once they are released to 'production'.
  - alpha/beta releases can be made from the feature branch if necessary.

### User branches

- User branches are created from 'develop' or 'feature' branches for individual developers. It usually follows the format, 'develop_username' or 'develop_feature_user' depends on the base branch.
- General Rules:
  - More than one branch can be available for the same developer, e.g., develop_username, develop_username_06_05_2017 or develop_feature_username, develop_feature_username_2
  - Direct commits into one user branch aren't allowed by another user.
  - Changes can be submitted through Pull Requests.
  - Pull requests should be approved by the owner of the branch.
  - Releases should never be made from user branch, although intermediate test releases to QA can be done if a situation arises.
  - User branches based on 'feature' branches can be deleted once the feature is merged into develop and released to alpha/beta.

### Bug-fix/Escalation/Test branches

- These branches are temporary branches created to fix a bug or address an escalation or perform some minor testing. The branches can be based on 'develop' or 'feature' branches. It should follow the naming conventions appropriately to indicate the purpose of the branch.```e.g, develop_JIRA-1511, develop_ESC-1008, test_develop_fake_service.```

- The reason for this naming convention is that the Atlassian products are interconnected and they can link these branches to the appropriate bugs automatically if the branches are named appropriately.
- General Rules:
  - Direct commits are allowed.
  - More than one branch can be available for a bug-fix, escalation or testing. To differentiate, the developer can use numbers, username, etc.
  - Changes can be submitted through Pull Requests.
  - When submitting Pull Request, it is recommended to choose 'Close the branch after merge'.
  - These branches can manually be deleted after merging.
  - Obsolete branches are eligible for deletion. It is up to the developer to ensure that the changes are submitted to 'develop' or 'develop_feature' branches through Pull Requests.
  - Releases should never be made from these type of branches.

This strategy has been working out well for us, a small team of 5 developers working on 2 products. We haven't seen any issues so far by using this strategy. But We are always very open to improving, so feel free to throw in any suggestions.

*[This post is also available on DEV.](https://dev.to/subbramanil/git-branching-strategy-3pnp)*


Git branching strategy


Hi All, 

As part of our educational program in my company, we have been reading books related to engineering practices. So far we have finished the following books, 

1. Code Complete 2, 
2. The Pragmatic Programmer, 
3. Learning Agile (O'Reilly), 
4. Adaptive Code (Microsoft Press)

We are small team of developers who works on iOS(moving to Swift), Android(Java, fighting for kotlin introduction), MEAN stack for web apps & services(Javascript duh!). 

Can someone recommend any good books on Functional Programming Paradigm that you read and found useful?. 

A quick search on internet throws bunch of books on Scala/Haskell. Language isn't too much of a challenge, however if there's any book on Javascript that would be great.

*[This post is also available on DEV.](https://dev.to/subbramanil/any-suggestions-for-books-to-learn-functional-programming-paradigm-5gd)*


Need some recommendations to learn functional programming

Any suggestions for books to learn Functional Programming Paradigm


Hi folks,

At my current work, as a part of a program to learn and improve our skills as a developer, we pick a good book related to software engineering, read a chapter each week and discuss with the team on what we learnt, how it can be useful to the team.

Currently we are reading the book, [Adaptive Code: Agile coding with design patterns and SOLID principles](https://www.microsoftpressstore.com/store/adaptive-code-agile-coding-with-design-patterns-and-9781509302581). We have been reading the book for some time, and the challenge we face right now is that none of us use C# at the work. We have mobile, web and systems teams and we primarily use java, swift, javascript and C. Language wise, it was a bad choice to pick this book; However the book is pretty good and well organized.

In Mobile team, we don't have any challenges in following the examples as C# & Java are OOP oriented. But our web team have challenges to grasp the concepts as they write in javascript (angularjs and node.js) which is functional oriented.

This is one good link that I found out,

- [http://aspiringcraftsman.com/2011/12/19/solid-javascript-the-openclosed-principle/](http://aspiringcraftsman.com/2011/12/19/solid-javascript-the-openclosed-principle/)

Have anyone come across any other good examples, references, or books that you can recommend?

Also I would like to understand what SOLID principles means to a web developer who's writing in angularjs & node.js and how they can apply. Can anyone throw some light on this.

*[This post is also available on DEV.](https://dev.to/subbramanil/solid-principle-in-javacript-9eh)*


What SOLID principle means to a Javascript developer

SOLID Principle in Javacript


## Inspiration

The original inspiration to write this blog started with an earlier [post](https://dev.to/jlhcoder/the-power-of-the-todo-list) on dev.to written by [James Hood](https://dev.to/jlhcoder). In that blog, James mentioned that he was using "text files" for to-do list which I thought of 'old school' at that time. I also added a comment on how I use 'evernote' for achieving the similar purpose. Couple of weeks ago, I was given a bit of advice given by one of my senior colleague(who I respect a lot) at my work.

His advice was,
> *Don't be too dependent on apps as you may never know where you will end up working in the future*.

My senior colleage's advice made me to read James Hood's blog again.  As I read through the blog and the comments, I started to re-think about my work flow and also consciously monitor the tools that I use and the way I use them on a daily basis. I use Macbook Pro(late 2013) at my work. As an Android developer, My primary development tools are,

1. Android Studio (obviously),
2. [pidcat](https://github.com/JakeWharton/pidcat) for logging,
3. [Android Tool](https://github.com/mortenjust/androidtool-mac) for taking screenshots

Besides that these are some apps I have installed and used on a daily basis,

1. **Evernote** for making notes and tracking my work
2. **Source tree** for version controlling
3. **Jayson**: A Mac app to view JSON files
4. **Visual Studio code** or **Sublime text** to view text files

Besides my macbook, I also remotely ssh into our build and release server machines running ubuntu 14.04. I don't actively write code on those machines, however I do write scripts on occasions.

## The idea

The idea is to reduce the dependencies of apps by taking a minimalistic approach and solve the problem with simple solution.

I took James Hood's idea of using text files for to-do list, and his comment about using private 'git' repo to back up notes.

So basically, I made two simple changes in my work flow.

- Use text files with **markdown** support instead of Evernote
- Use **git terminal commands** instead of Sourcetree

Earlier I had created a repo for my blogs and the directory structure is as below,

![blog directory structure](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/blogs_dir_structure.png)

I expanded on the idea and created a directory structure as below,

![dev notes directory structure](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/dev_notes_dir_strucutre.png)

Now all my notes, blogs and work logs are in one single place in my private repository. All I need is a machine with git installed and internet to access them.

The reason I chose to use *markdown* instead of plain text files is that markdown makes it easier to review the notes in the future. As you read through the blog you can see what do I mean by that.

## Making notes

Migrating all my notes from Evernote to Git repository at once is a painful task. So I am following this approach.

1. Any new notes will be written in *markdown* and commited to the repo.
2. Whenever I refer any notes from my *evernote*, I copy them to my repo in markdown format. (It's a slow process, however I'm sure it will be done over a period of time)

## Tracking work

Under the *Work Log* directory, I created a master to-do list markdown file, **00 Todo List of Tasks.md** (Name begins with 00 so that it would be on top in the directory stucture when sorting) and also created a sub-directory **resources** to add the additional resource files like screenshots, log files etc.,

As the name implies the idea of master to-do list to serve as common reference point to add/remove/review the tasks and also helps to jot down any new ideas that popped up as I work.

I started creating markdown files (in similar style as writing blogs in some sites) in the format, 'date_day.md'  So after two weeks of my work, it looks like as below.

![Work Log File Structure](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/work_log_complete_structure.png)

I usually plan my day ahead either the night before or early in the morning. The tasks may come from the *master to-do list* or based on the meetings/emails/JIRA tasks assigned. Each Markdown file follows the below format when created.

```markdown

# Plan for the day

- [ ] Task A
- [ ] Task B
- [ ] Task C

---
```

Once I add the plan for the day, I commit my changes.

```git
git add Work Logs/file.md
git commit -m "Adds Plan for the day"
git push
```

As I start the day at work, I prioritize the tasks based on the priority and start working from top priority task. Any new tasks that come up will be added to bottom of the list. At any time only one task(Current taks) will be marked as **bold** (using markdown syntax) in order to keep my focus.

```markdown

# Plan for the day

- [ ] Task A
- [ ] **Task B**
- [ ] Task C
- [ ] Task D

---

## Task B

- Task description/Link
  - Notes related to tasks
  - To do list of actions
```

I follow a strict rule of not jumping to the another task unless it's top priority task or time sensitive. Otherwise I don't start on another task until I complete or reach a checkpoint on the current task. Before jumping to the next task, I update the task with the completion status and if there's anything pending.

```markdown

## Task B

- Task description/Link
  - Notes related to tasks
  - To do list of actions
  - Actions taken
  - **Actions Pending**

```

And I make a commit as below.

```git
git add Work Logs/file.md
git commit -m "Completes Task-D"
git push
```

I repeat these steps until the end of the day. And at the end of the day it will look like this.

```markdown

# Plan for the day

- [x] Task A
- [x] Task B
- [ ] **Task C**
- [x] Task D
- [ ] Task E

---

## Task B

...

---

## Task A

...

---

## Task D

...

---

## Task C

- Task description
  - todo list of actions
  - **Action pending**

```

At the end of the day, I review the tasks completed and tasks that are pending. The final work log can have only the tasks that are completed on that day, which makes easier to review the completed tasks in the future. Based on the progress and priority, all the unfinished tasks goes to either the next day or to the master to-do list. For example, the *Task C* may go to the next day and *Task E* may go to the master to-do list.

When moving the unfinished tasks, I copy the progress made so far for the task. So I don't really need to refer the previous day notes again. Also the unfinished tasks carried over from the previous day helps to prioritize the tasks in the following day.

## Benefits of the approach

The most obvious benefit that I got from this approach was that I no longer needed several apps. I can access my notes from anywhere as long as I have internet connection.

```markdown
# Gradle Notes

## Gradle Wrapper

- Wrapper is a small shell script that can download gradle if itsn't installed and can run tasks.

## Gradle Daemon

- Runs gradle in the background.
- Gradle creates separate JVM to run tasks. 
- Gradle daemon re-uses the JVM created earlier. 

## Tasks

- Self contained piece of work
- Performs operations in isolation
- Can depend on other tasks
- Can have input & output

```

On reviewing my work log, it's plain to see what's completed on that day and what actions that I took.

![Sample work log](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/work_log_sample.png)

Also this opportunity helped me to master the *git* commands by using them on a daily basis.

## Disclaimer

1. You might lose some mobilty in terms of editing the notes from mobile devices. If you use your mobile phone for primary note taking purposes, this approach may not be helpful.
2. There is a learning curve when it comes to **git** version control through commands. For some it may not seem like it increases your productivity. But you can install extensions/plugins to auto-complete the commands.

## Few tips

- I use **Visual Studio Code** with *markdownlint* extension which helps me to avoid markdown formatting mistakes.
- I also make use of **User snippets** feature in Visual Studio code. For example, here's a snippet that I use for inserting code blocks in markdown files.

![User Snippets](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/user+snippets.png)

Please feel free to share your thoughts.

*[This post is also available on DEV.](https://dev.to/subbramanil/minimalistic-developer)*


Minimalistic Developer


I read about Kotlin, the simple, yet powerful language which can be Java alternative years ago when Jetbrains released their initial versions of Kotlin. Having worked on Java for longer time, I called it "blasphemy", and totally ignored it. 

However ever since the *Kotlin* was announced as offical programming language for Android in **Google I/O**, I realized that I have been silly all these time and biased towards Kotlin. I felt stupid for not realizing it sooner and have started spending time in learning Kotlin. 

I'm currently going through the pluralsight course, *[Kotlin Fundamentals](https://www.pluralsight.com/courses/kotlin-fundamentals)* by *Kevin Jones*. As he was explaining "*How Kotlin Improves the Handling of Null Values*", I realized the simple, yet powerful feature of Kotlin in handling the '*null*' and how it can help java developer from *frustrating* null check. 

![Funny Null Pointer](https://www.codeproject.com/KB/bugs/787668/null_pointer_error_message.jpg)

## In Java 

In Java by default any variable declared can be *null*. For example, 

```Java
class Developer {
    String team;
    String role;
    String project;

    void display(String name, String employeeType) {
        if (employeeType.equals("Full-Time")) {
            System.out.println(name + " is a Full-Time " + role + " in " + team + " working in " + project);
        } else {
            System.out.println(name + " is a Intern "+ role + " in " + team + " working in " + project);
        }
    }
}

class LearningKotlinUtil {

    public static void main(String[] args) {
        Developer dev = new Developer();
        dev.project = "ePhone7";
        dev.team = "Mobile Team";
        dev.role = "Android Developer";
        
        dev.display("Subbu", "Full-Time");

        dev.display("Subbu", null);
    }
}

```

In the *Developer* class, *type* can be null. So the second invocation to '*display()*' method will throw a *NullPointerException*. To avoid that, the developer has to do *null-check* as below. 

```Java
class Developer {
    ...
    void display(String name) {
        if (employeeType != null && employeeType.equals("Full-Time")) {
            ...
        } else {
            ...
        }
    }
}
```

or you can write as below, 

```Java
class Developer {
    ...
    void display(String name, String employeeType) {
        if ("Full-time".equals(employeeType)) {
            ...
        } else {
            ...
        }
    }
}
```

To take advantage of IDE features, the developer can annotate the variable *type* with **@NonNull** annotation as below. 

```Java
class Developer {
    ...

    void display(String name, @NonNull String employeeType) {
        if (employeeType != null && employeeType.equals("Full-Time")) {
            ...
        } else {
            ...
        }
    }
}
```
> **@NonNull** annotation is supported through android annotation support library or Java 8 Annotation Support JSR-308. 
> import android.support.annotation.NonNull;


Now the IDE (Intellij/Android Studio) warns the developer as in the below screenshots,
![Assigning Null](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/IDE+Warning-2.png)
![Null-Check](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/IDE+Warning-3.png)

However it doesn't prevent the variable '**type**' being set to 'null' and the developer must listen to the IDE(if using one) warnings. If the developer isn't careful, the null-pointer can only be realized in runtime. 


## Kotlin to Rescue
In **Kotlin**, ~~by default the variables *var* is of **non-null** type~~ the [type system](https://news.realm.io/news/revisiting-types-in-kotlin/) defines whether the variables can hold 'null' or not. For example, here when you declare employeeType as '*employeeType: String*', the Kotlin type system enforces employeeType variable as non-nullable.

```kotlin
class Developer {
    var team: String = ""
    var role: String = ""
    var project: String = ""

    fun display(name: String, employeeType: String){
        if(employeeType == "Full-Time") {
            println("$name is a Full Time $role in $team working in the $project project")
        } else {
            println("$name is a Intern $role in $team working in the $project project")
        }
    }
}

fun main(args: Array<String>) {
    val dev = Developer()
    dev.team = "Mobile Team"
    dev.role = "Android Developer"
    dev.project = "ePhone7"

    dev.display("Subbu", "Full-Time")
}
```

Now the parameter, '*employeeType*' can never be *null* and attempting to do so will result in **compilation error**. 

```kotlin
fun main(args: Array<String>) {
    val dev = Developer()
    dev.team = "Mobile Team"
    dev.role = "Android Developer"
    dev.project = "ePhone7"

    dev.display("Subbu", "Full-Time")
    dev.display("Subbu", null)
}
```

![Compilation Error](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/Kotlin+Compilation+Error-1.png)

~~If you really want to allow employeeType to accept '*null*' values, you must explicitly states so as below using **'?'** operator.~~

If the 'employeeType' variable can have 'null' values, it should be declared as '*String?*' as per the Kotlin Type system. 

```Kotlin
class Developer {
    ...
    fun display(name: String, employeeType: String?){
        ...
    }
}
```

The declaration '*employeeType: String?*' tells that the compiler that employeeType can accept 'null' as value. This is equivalent to **@Nullable** annotation in java. 

~~This is one of the powerful features of Kotlin. Making the variables as 'Non-Null' by default and forcing the developer to explictly declare variables that can be 'null'~~, 
~~1. Indirectly forces the developer to think about the variables usage when declaring one~~
~~2. It prevents the developer attempting to assign/pass 'null' in compilation time itself.~~  

~~I have just kick-started learning Kotlin, and I will keep posting new simple, yet powerful features of Kotlin as I explore them.~~ 

In my humble opinion, a better understanding of Kotlin type system will greatly assist the developer to think about the values that a variable can hold at the declaration and also prevent other developers to pass/assign 'null' values even by mistake. 

I have just kick started learning Kotlin, and I will write further blogs about the features that I liked, once I understood them completely. Please feel free to throw in any comments or suggestions.

*[This post is also available on DEV.](https://dev.to/subbramanil/simple-yet-powerful-features-of-kotlin)*


How Kotlin Improves the Handling of Null Values

Simple, yet powerful features of Kotlin



The first of many questions in an interview for any *Android Developer* position would be about **Life Cycles**. I myself, have asked the same question to several interviewees and got [definitions of life-cycles](https://developer.android.com/guide/components/activities/activity-lifecycle.html) to the teeth. 

For a very long time, I thought that I understood the lifecycles completely (*Until last week*). We work in an app that heavily uses *fragments* with very few *activities*.  Last week, we were noticing some strange issues started popping out. After spending some time, we figured out that the developer who wrote, made some assumptions about the life-cycles and failed to handle the events.

My first instinct as a Developer was to look at the *Android* documentation and read through some blogs to refresh my understanding. However I realized that there would another time in the future I would have to do the same, If I didn't get my hands dirty by working on some hands-on exercises and really understand the android life-cycles. 

I planned to spend some time over the weekend to work on few common scenarios with Android Activities and Fragments and document my understanding.

**My basic Idea** was to try writing a sample app to understand the following cases. 
- Single Activity
- Single Activity with one fragment (Statically attached to activity layout /Dynamically attach using "**SupportFragmentManager**")
- Single Activity with multiple fragments  
- Two Activities  
- Two Activities with one fragment each  

> **Note:** This is going to be a multi-part series in understanding android lifecycles. I am going to create a public repository to share the code. Any suggestions or feedbacks are most welcome. 

> Some Restrictions that I put on myself to focus on understanding the life-cycle and not to derail into other details. 
> 1. Spend minimum effort on typing code. Use templates as much as possible.(Android Studio provides some good samples).
> 2. Keep the UI to the minimum enough to show difference. Do not spend effort in designing or making it aesthatically pleasing. Focus on writing *enough* debug statements to understand what's going on. 
> 3. Try to understand as much as possible from each example. Do not jump from one to another without understanding. This involves making notes from the debug statements, reading *android* documentation and of course reading blogs from the wise on the web.  
> **Additional Technical Restrictions:**  
> Even though the world has moved on to **Android O** with minimum support from API **23** (aka *Lollipop*), our app runs on custom android platform based on Kitkat. 
> 5. So I'm keeping the minimum Android SDK API level to **19** (aka *Kitkat*). 
> 6. I am going to stick with **SupportFragmentManager** rather than **FragmentManager**. Probably I will put up another article later comparing the both. 

### Let's get the hands dirty

I created a new android application project, '**LifeCyclesApp**' (can't name it any other way). 

#### Application Class

```Java
public class LifeCyclesApp extends Application {

    private static final String TAG = LifeCyclesApp.class.getSimpleName();

    //region Life-cycle apps
    @Override
    public void onCreate() {
        Log.d(TAG, "onCreate()");
        super.onCreate();
    }

    @Override
    public void onConfigurationChanged(Configuration newConfig) {
        Log.d(TAG, "onConfigurationChanged()");
        super.onConfigurationChanged(newConfig);
    }

    @Override
    public void onTerminate() {
        Log.d(TAG, "onTerminate()");
        super.onTerminate();
    }
    //endregion
}
```

#### Main Activity class

```Java

public class MainActivity extends AppCompatActivity {

    private static final String TAG = MainActivity.class.getSimpleName();

    //region Life-cycle events
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        Log.d(TAG, "onCreate()");
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    @Override
    protected void onStart() {
        Log.d(TAG, "onStart() ");
        super.onStart();
    }

    @Override
    protected void onResume() {
        Log.d(TAG, "onResume() ");
        super.onResume();
    }

    @Override
    protected void onPause() {
        Log.d(TAG, "onPause() ");
        super.onPause();
    }

    @Override
    protected void onStop() {
        Log.d(TAG, "onStop() ");
        super.onStop();
    }

    @Override
    protected void onDestroy() {
        Log.d(TAG, "onDestroy() ");
        super.onDestroy();
    }
    //endregion
}
```

The UI is very simple. It has nothing. (lol)  

![App Screenshot](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/r2d22.3.11subbu06042017003228.png)

#### Flow of App Run: 
1. Start the app
2. MainActivity is shown.
3. Start 'Settings' app from command line. 
4. Press back to exit from the Settings, back to the Lifecycles app
5. Press back to exit from the app. 

```Bash
          LifeCyclesApp  D  onCreate()
           MainActivity  D  onCreate()
                         D  onStart()
                         D  onResume()
...
                         D  onPause()
    Process com.android.settings created for activity com.android.settings/.Settings
           MainActivity  D  onStop()
...           
                         D  onStart()
                         D  onResume()
...                         
                         D  onPause()
                         D  onStop()
                         D  onDestroy()
```

Yes by looking at the logs it makes  lot of sense. But wait, What happened to **onTerminate()** method of *LifeCyclesApp* class? It didn't appear in the logs. I did exit from the app. May be if I wait for a while, android kills the app after a while. 

Waiting...

Nope.

**onTerminate()** wasn't called yet. 

How about take one more step to ensure that app is stopped? I went to *Settings->Applications* and tried to 'Force Stop' the app. 

Nah!. **onTerminate()** was never called. 

I looked into the *javadoc* documentation of **onTerminate()** method and found out that's true. 

```Java
public class Application extends ContextWrapper ... {
    ...

    /**
     * This method is for use in emulated process environments.  It will
     * never be called on a production Android device, where processes are
     * removed by simply killing them; no user code (including this callback)
     * is executed when doing so.
     */
    @CallSuper
    public void onTerminate() {
    }
    ...
}

```
I verified the above statement as well. 

```Bash
1|root@xxx:/ # ps | grep life                                                 
u0_a46    9368  2243  878808 26364 ffffffff 401de834 S com.chaturaloka.lifecycles
root@xxx:/ # kill 9368
```

```
          LifeCyclesApp  D  onCreate()
           MainActivity  D  onCreate()
                         D  onStart()
                         D  onResume()

        Process com.chaturaloka.lifecycles (PID: 9368) ended
```

Even killing the app process didn't call the **onTerminate()** method. However it was interesting to see **onStop()** and **onDestroy()** methods of *MainActivity* were not invoked as well when killing the app process. However If you pay little more attention to the android [activity life-cycles](https://developer.android.com/guide/components/images/activity_lifecycle.png) diagram, this is the expected behavior of the activity.

> Probably you are thinking, I could have checked the documentation in the first place. Yeah! I agree. However I was happy that I learnt the life-cycles theoratically as well as practically.

Now on to the next adventure of **Single Activity with one Fragment!!**

*[This post is also available on DEV.](https://dev.to/subbramanil/being-aware-of-android-lifecycle-i)*


    


Understanding android lifecycle through hands-on

Being aware of Android Lifecycle-I


I have just started reading the book [Organize your Business - Organize your Life](https://www.amazon.com/Organize-Your-Business-Life/dp/0768411378) by **Rachael Doyle** yesterday night. In the first chapter, **Organize Your Desk** she shared some very good pointers on how to keep your desk clean and organized to increase productivity. 

At the basic, divide your desk into three **zones**. 

**Zone A:** Desk area within reach of your arm while sitting in your chair.

**Zone B:** Area that require you to roll your chair a few feet away from the desk.

**Zone C:** Area where you have to get up out of your chair and walk to get something. 

Make conscious decisions about which item goes to which zone. 

I keep my workspace (reasonably) clean. And this idea of 'Zoning' the area makes lot of sense to me. How about you?

**Q-1:** If you were to follow this idea of '*Zoning*', what will you keep in each Zone?

**Q-2:** What do you guys follow when organizing and keeping your desk clean?

**Note:** 
_Cover Picture credits to [CSS Winner](http://www.csswinner.com/blog/designer-workspace-inspiration)_

*[This post is also available on DEV.](https://dev.to/subbramanil/how-do-you-keep-your-desk-organized)*


    


Discussion on how to keep your desk organized for better productivity?

How do you keep your desk organized?



# MVP

### What is MVP?

**Clue:** It is not ~~``Most Valuable Player.``~~ or [~~``Most Valuable Primate``~~](http://www.imdb.com/title/tt0196106/)

[Model-View-Presenter](https://en.wikipedia.org/wiki/Model–view–presenter) is an architecural design pattern that's been getting lots of traction in android app development community. 

### Why should you use MVP?

Rather than copying and pasting the *awesomeness of MVP* design pattern for android, I will let you to jump into the links that I found most useful. 
> 1. [MVP Understanding](http://engineering.remind.com/android-code-that-scales/  )
> 2. [MVP Guidelines](https://medium.com/@cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf)
> 3. [MVP Part-1](http://www.tinmegali.com/en/model-view-presenter-android-part-1/)
> 4. [MVP Part-2](http://www.tinmegali.com/en/model-view-presenter-mvp-in-android-part-2/)
> 5. [MVP Part-3](http://www.tinmegali.com/en/model-view-presenter-mvp-in-android-part-3/)

### How did I get started?

As I mentioned earlier, there were several articles about MVP in addition to the links that I mentioned above. After reading through several of them, I realized that MVP offers much cleaner implmentation because of the fact that it embraces the **Single Responsibility Principle** by separating the UI from the actual implementation. And also I had been facing hard time writing unit test cases for some functionalities in our app that were tightly coupled with UI. They kept breaking the Unit test cases and I had hard time debugging the test cases. I decided to give it a shot to MVP design pattern and sweet, it provided everything what I was looking for. 

> **Note:** This is only my second implementation in MVP design. There my be some errors or misunderstanding of the concepts. 

In my opinion, the question you should as yourself before implementing in MVP are, 

1. ~~Should I use progress bar or progress wheel?~~
2. ~~What are the colors?~~ 
3. ~~Should I use AsyncTask or Handlers for longer running process?~~
4. ~~Should I do..~~

no. No. NO. **NO!**  
Trust me! I know it is very easy to think about and get carried away into the technical details of implementation. However We have to change the thinking. 

- ``Think only about purpose of the screen.``
- ``Forget every techincal details involved.``

The functionality I chose to refactor in our app was **Login and initial boot up screen**. The responsiblities of the screen were,  

1. Login the user ~~with the Authentication Micro service~~
2. Register the device to ~~Servers~~, 
3. Sync the contacts ~~using Sync Service,~~ 
4. Sync User Voicemails ~~through Voicemail Sync Service~~

### Designing the Model

When you start designing the *Model* interface, do not worry about the technical details and concentrate only on the functionality that you wanna achieve. 

This was the initial sketch of the interface I started with. 

```Java
interface LoginModel {

    void initLogin();

    void completeLogin();

    void initRegistrationProcess();

    void completeRegistrationProcess();

    void initContactsSync();

    void initVoicemailSync();
}
```

As these operations may take longer time to complete and also to reduce the dependency, the *Model* interface defines a *Listener* interface to pass down the results. 

```Java
interface LoginModel {

    interface LoginModelListener {

        void onConfigurationFailure();

        void onLoginSuccess();

        void onLoginFailure();

        void onSyncFailure();
    }

    void initLogin();

    void completeLogin();

    void initRegistrationProcess();

    void completeRegistrationProcess();

    void initContactsSync();

    void initVoicemailSync();
}
```

> **Note:** Ideally you can design the *Listener* interface methods to pass the results as parameters, however we care only about the results of operations here. 

Since the Model class contains only the functionality and doesn't hold any dependency on the User interface, its quite easy to write *Android Unit Test cases* to verify the functionality as below, 

```Java
public class LoginModelImplTest implements LoginModel.LoginModelListener {
    
    private LoginModelImpl mLoginModel;

    @Before
    public void setUp() throws Exception {
        mLoginModel = new LoginModelImpl(this);
    }

    @Test
    public void testLogin() throws Exception {
        // TODO: 5/24/17 Add implementation
    }

    @After
    public void tearDown() throws Exception {
        
    }

    @Override
    public void onLoginSuccess() {
        // TODO: 5/24/17 Add implementation
    }

    @Override
    public void onLoginFailure() {
        fail();
        
    }

    @Override
    public void onSyncFailure() {
        // TODO: 5/24/17 Add implementation
    }
}
```

Now you have the '*Model*' interface to define the functionality and a unit test case class to verify it. 


### Designing the View

When designing the view, think about what information to show, rather than how to show it. For example, here the information interesting to the users are, 
- Results of the each step in the process.
- Errors in case something went wrong. 

This information can be shown with any UI elements. 

```Java
interface LoginView {

    void updateStatus(int step, boolean status);

    void showProgress();

    void hideProgress();

    void showError(String errorCode);
}
```

Notice the methods doesn't actually care about the UI elements that can be used. Based on the requirements, you can have any different types of user interfaces. 
For example, here is the simple implementation of the *LoginView*

![App Screenshot](https://s3-us-west-2.amazonaws.com/my-blogresources/r2d22.3.8subbu05262017002156.png "Login Screenshot")


The simplest implementation took about than 100 lines of code, where as the implementation can use any UI View components.

### Designing the Presenter

The presenter interface acts as the bridge between the View and Model. So it will have methods to invoke functionalities defined by the Model and also methods to handle the data as the lifecycle of the UI changes. 

```Java
interface LoginPresenter {

    // To invoke Model functionalities
    void initLogin();

    void initRegistration();

    void initContactsSync();

    void initVoicemailSync();

    // To track UI lifecycles
    void onCreate();

    void onResume();

    void onPause();

    void onDestroy();
}
```

```Java
class LoginPresenterImpl implements LoginPresenter, LoginModel.LoginModelListener {

    private final LoginView mLoginView;
    private final LoginModel mLoginModel;

    LoginPresenterImpl(LoginView loginView) {
        this.mLoginView = loginView;
        this.mLoginModel = new LoginModelImpl(this);
    }

    ...
}
```

Notice that the '*Presenter*' implementation has, 

1. Reference to the Model: Used to call methods defined in Model
2. Reference to the View: Used to update the UI
3. Implements the Listener interface: Get results back from Model

Now the implementation of '*Presenter*' becomes very simple. 

1. Call the 'Model' methods,
2. Get the results back using the 'Listener',
3. Update the 'View'.

```Java
class LoginPresenterImpl implements LoginPresenter, LoginModel.LoginModelListener {
    ...

    @Override
    public void initLogin() {
        mLoginModel.initLogin();
    }

    @Override
    public void onLoginSuccess() {
        mLoginView.updateStatus(0, true);

        mLoginModel.completeLogin();

        initRegistration();
    }

    @Override
    public void onLoginFailure() {
        mLoginView.updateStatus(0, false);
        mLoginView.showError(ErrorCodes.LOGIN_FAILED);
    }

    @Override
    public void initRegistration() {
        mLoginModel.initRegistrationProcess();
    }

    ...
}
```

Now you can implement the functionalities '*Model*' interface, test with Unit Test cases. Once you verified the functionalities, you can tie up the Presenter and View. The 'View' implementation can be as simple as console outputs or complex UI components. 

The major advantages of this approach that I found are, 

1. When the User interface requirements changes, all you have to do is to change the UI components. 
2. When the functionality is required in another place, it can be achieved by creating a new fragment/activity that implements the View interface.
3. If one of the functionality changes from one to another, for ex., Couchbase to Websockets, only the implementation detail changes; the functionality stays the same. 
4. It is very easy to do Test Driven Development. I will write down another blog about my TDD attempt using MVP design pattern. The simple steps are, 
    1. Start with the 'Model' interface skeleton with methods. 
    2. Write the Unit test cases for the methods. 
    3. Implement the 'Model' interface and implement one method at a time and unit test the functionality.
    4. Once the Model class is complete, hook up the presenter and view.  
    
I plan to use MVP design for developing new features and refactoring existing features and I hope to get a better understanding of the MVP design pattern. I will write another follow-up article if needed. 

> **Known mistakes**: 
> One of the guidelines mentioned in [this](https://medium.com/@cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf) article was, not to create lifecycle methods for *Presenter* interface. However the examples I have seen in several other places used some sort of lifecylce methods and it made sense to use them here.

*[This post is also available on DEV.](https://dev.to/subbramanil/clean-design-using-mvp)*


Clean Design using MVP 



# Singletons
[Singleton Design Pattern](https://en.wikipedia.org/wiki/Singleton_pattern) is by far the most common design pattern and the first one that come across to anyone when think about Design Patterns. It's so commonly used that there are people who can write the pattern in their sleep. 


## Android Studio Default Template
```Java
class Test {
    private static final Test ourInstance = new Test();

    static Test getInstance() {
        return ourInstance;
    }

    private Test() {
    }
}
```

The below is the template that we generally use in our team. 

## Our Template

```Java

class Test {
    private static final Test ourInstance;

    static Test getInstance() {
        if(ourInstance == null){
            ourInstance = new Test();
        }
        return ourInstance;
    }

    private Test() {
    }
}

```

I faced a situation where I was required to create a Singleton per activity, or a Singleton class that holds an instance of Activity context. Usually when you try to declare objects like '*Activity*' or '*Context*' as a static field in any Java class, Android Studio warns about memory leak via static objects. 

```
Do not place Android context classes in static fields; this is a memory leak.
```

To avoid that memory leakage, 
1. Do not store context (That's obvious! isn't it). 

2. Use *WeakReference* to store the context. 

```Java
private final WeakReference<Activity> mActivityContextRef;

public static void newInstance(Activity activity) {
    if (ourInstance == null) {
        ourInstance = new Test(activity);
    }
}

private Test(Activity activity) {
    mActivityContextRef = new WeakReference<>(activity);
}

```

> **Some of the best articles on Weak References:**  
> 1. [Romain Guy's Article](http://www.curious-creature.com/2008/12/18/avoid-memory-leaks-on-android/)  
> 2. [Articles from Google Developers Experts-1](https://medium.com/google-developer-experts/finally-understanding-how-references-work-in-android-and-java-26a0d9c92f83)
>3. [Articles from Google Developers Experts-2](https://medium.com/google-developer-experts/weakreference-in-android-dd1e66b9be9d)


Back to the earlier scenario that I described, I had to create an **Singletons per Activity**. Combining with our singleton template with the concept of *WeakReference*, I came up with this.

```Java
public static void newInstance(Activity activity) {
        if (ourInstance == null) {
            ourInstance = new Test(activity);
        } else {
            if (activity.equals(ourInstance.mActivityContextRef.get())) {
                LogUtils.debug(TAG, "newInstance: Same Activity; No need to create new instance");
            } else {
                LogUtils.debug(TAG, "newInstance: New Activity; Create new instance");
                ourInstance = null;
                ourInstance = new Test(activity);
            }
        }
    }

    private Test(Activity activity) {
        mActivityContextRef = new WeakReference<>(activity);
    }
```

This solution helped us to solve the issue we were facing. 

I don't argue that this is perfect solution and in fact a  **Word of Caution** When I was talking to one of my senior colleagues regarding the above *Singleton per Activity*, he questioned me that **Why would anyone require an *Activity* context in a Singleton POJO class**. That got me thinking and I realized that the class in question was handling [too many responsiblities](https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html) and refactored using **MVP** design pattern. I will write that in another post.

*[This post is also available on DEV.](https://dev.to/subbramanil/singletons-per-activity-context)*


    


Singletons per Activity context


# Android Data Binding

In this series of blogs, I am going to put down my notes from learning the course '[Android Fundamentals: Data binding](https://app.pluralsight.com/library/courses/android-data-binding/)' from **[Pluralsight](https://www.pluralsight.com)** and other resources from web.  

> **Disclaimer:** These are my notes from the 'PluralSight' course and I do not mean to reproduce something copyrighted. 

## Traditional Approach
How many of the android developers are tired of writing the code as below, 

```Java
View view = inflater.inflate(R.layout.network_config_layout, parent, false);
EditText ipEditTxtView = (EditText) view.findViewById(R.id.nw_config_ip_address_value);
ipEditTxtView.setText(nwConfig.getIpAddress());

Button saveNWConfigBtn = (Button) view.findViewById(R.id.save_nw_config);
saveNWConfigBtn.setOnClickListener(this);

```

Basically, the steps of traditional view binding are, 
1. Inflate the XML
2. Find the required element from the XML
3. Assign it to a local/member variable
4. Get the value from data
5. Assign the value or Assign the event listener

There is nothing wrong in the above data binding process, however one gets tired of writing this code over a period of time. 

> If anyone is curious, there is a famous *live template* in **Android Studio** that can write the line to find the element from view. 
> 1. Enter ``fbc`` 
> 2. Press **Command + Space**(Mac) or **Ctrl + Space**(Windows) 
> 3. Android Studio will auto complete the line as ``() findViewById(R.id.);``

## View Binding Libraries

The author provides a bunch of View binding library alternatives. 
1. [RoboBinding](http://robobinding.github.io/RoboBinding/)
2. [ButterKnife](https://github.com/JakeWharton/butterknife)
3. [AndroidAnnotations](https://androidannotations.org)

I have used *ButterKnife* before and I found it pretty easy to use. I do not want to get into implemenation details of these libraries since the intention of this blog is about Google's *Android Data Binding* library. 

## Data Binding Library Process
The steps involved here are, 

1. Creating a binding class from Layout
2. Retrieve the data 
3. Bind the data to the view

The all mighty *gradle plugin* helps with the process of creating the binding class from the view. 

1. Analyze the layout file
2. Creates the binding class file
3. Create binding methods in class file

> **Note:** Use the latest version of Android Studio and make sure to download the Android Support Repository from SDK Manager.  
> As per the time of writing this blog, I was using Android Studio 2.3.1 released on April 1, 2017 and have downloaded all support libraries. 

I re-used one of my old projects from [**Android Nano Degree**](https://www.udacity.com/course/android-developer-nanodegree-by-google--nd801) for this course. The app was a simple weather app that shows the weather forecast for a week for a given location and temperature Unit. I used *recycler view* to show the forecast for a week, *AsyncTask* to make the service request to [OpenWeatherMap API](https://openweathermap.org) and [Picasso](http://square.github.io/picasso/) image loading library to load weather icons. 

You can find a screenshot here: 
![App Screenshot](https://s3-us-west-2.amazonaws.com/my-blogresources/weather_app_screenshot.png "Weather App Screenshot")

> Useful Link: [Android Data Binding](https://developer.android.com/topic/libraries/data-binding/index.html)

Google simplified integrating the data binding support to the Android apps. In the app level *build.gradle* file, I added a block to enable data binding. 

```Groovy
android {
    ...
    ...
    dataBinding {
            enabled = true
    }
}
```

Now the app was ready to have some 'Data Binding'. Next I updated the layout file for weather item in the recycler view as follows. 

1. Enclosed the existing layout with `<layout>` and `</layout>` tags. 
2. Created a `<data>` element with one `<variable>` to hold the Weather data for the row.

```xml
<?xml version="1.0" encoding="utf-8"?>
<layout>

    <data>

        <variable
            name="dataBindingItem"
            type="com.udacity.learning.mysunshineapp.model.WeatherData" />
    </data>

    <android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        android:id="@+id/list_item_card"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_margin="@dimen/margin_5dp"
        android:background="@color/cardview_background"
        android:padding="@dimen/_10dp">

        <TextView
            android:id="@+id/list_item_date_textview"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:minHeight="?android:attr/listPreferredItemHeight"
            android:text="@{dataBindingItem.dt}"
            android:textSize="18sp"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintHorizontal_bias="0.10"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toTopOf="parent"
            app:layout_constraintVertical_bias="0.1" />

        <ImageView
            android:id="@+id/list_item_weather_imageview"
            android:layout_width="100dp"
            android:layout_height="100dp"
            app:imageUrl="@{dataBindingItem.weatherIconURL}"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintHorizontal_bias="0.10"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toTopOf="@id/list_item_date_textview"
            app:layout_constraintVertical_bias="0.90" />

        <TextView
            android:id="@+id/list_item_weather_desc_textview"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@{dataBindingItem.weather.get(0).description}"
            android:textSize="18sp"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintHorizontal_bias="0.40"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toBottomOf="@+id/list_item_date_textview"
            app:layout_constraintTop_toTopOf="parent"
            app:layout_constraintVertical_bias="0.80" />

        <TextView
            android:id="@+id/list_item_max_temp_textview"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@{dataBindingItem.temp.max}"
            android:textSize="18sp"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintHorizontal_bias="0.80"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toTopOf="parent"
            app:layout_constraintVertical_bias="0.40" />

        <TextView
            android:id="@+id/list_item_min_temp_textview"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@{dataBindingItem.temp.min}"
            android:textSize="18sp"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintHorizontal_bias="0.80"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toBottomOf="@+id/list_item_max_temp_textview"
            app:layout_constraintTop_toTopOf="parent"
            app:layout_constraintVertical_bias="0.80" />

    </android.support.constraint.ConstraintLayout>
</layout>
```

The `name` propoerty of the `variable` is used to refer the data as `android:text="@{dataBindingItem.dt}"`. The data binding library looks for, 

1. A public method with name *'getDt()'* that returns a String 
2. A public method with name *'dt()'* that returns a String 
3. A public member variable with name *'dt'* of type String

to associate the data with the text field. 

The type refers to the POJO Data Model Class `WeatherData` as below. 

```Java
public class WeatherData extends BaseObservable implements Parcelable {

    @Bindable
    private String dt;
    @Bindable
    private String pressure;
    @Bindable
    private String humidity;
    @Bindable
    private String speed;
    @Bindable
    private String clouds;
    @Bindable
    private TemperatureData temp;
    @Bindable
    private ArrayList<WeatherDesc> weather;
    @Bindable
    private String weatherIconURL;

    ....
}
```

Notice that the variables are annotated with `@Bindable` annotation. And the `WeatherData` class has public getters and setters for the *private* variables. 

> Note: Look at the power of data binding support in the xml files. For example, in this line `android:text="@{dataBindingItem.weather.get(0).description}"` I was able to access to description of first time of a weather list. 

Next step was to update the *adapter* that I used for the *RecyclerView* as follows. 

1. Update the *ViewHolder* associated

```Java
class ForecastViewHolder extends RecyclerView.ViewHolder {
    private final ViewDataBinding itemBinding;

    ForecastViewHolder(ViewDataBinding binding) {
        super(binding.getRoot());
        this.itemBinding = binding;
    }

    void bind(WeatherData data) {
        itemBinding.setVariable(BR.dataBindingItem, data);
    }
}
```

2. Update the *onCreateViewHolder* and *onBindViewHolder* methods of Recycler Adapter

```Java
public class ForecastDataAdapter extends RecyclerView.Adapter<ForecastDataAdapter.ForecastViewHolder> {

    ...

    @Override
    public ForecastViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        ViewDataBinding mForecastItemBinding = DataBindingUtil.inflate(inflater, R.layout.list_item_forecast_constraint, parent, false);
        return new ForecastViewHolder(mForecastItemBinding);
    }

    @Override
    public void onBindViewHolder(ForecastViewHolder holder, int position) {
        WeatherData data = weatherData.get(position);
        holder.bind(data);
    }

    ...
}
```

There are few things to note here: 

1. The *ViewDataBinding* in `private final ViewDataBinding itemBinding;`  
    
    - ViewDataBinding is the base class for generated data binding classes

2. What is *BR* in `itemBinding.setVariable(BR.dataBindingItem, data);`

    - BR is BindingResource that is generated by Gradle as similar to *R* classes in android.

3. What is *DataBindingUtil* in `ViewDataBinding mForecastItemBinding = DataBindingUtil.inflate(inflater, R.layout.list_item_forecast_constraint, parent, false);`

    - *DataBindingUtil* is a Utility class that data binding support adds to help with inflating the view and create binding class. This line inflates the view and also binds the view.

> **Note:** There are several ways to create a binding class, (Using Activity, Fragments, etc.,). 

When I tried to run the app, I got few compilatoin issues about, `private TemperatureData temp` and `private ArrayList<WeatherDesc> weather` and it didn't create the `BR` file. For a while, I didn't understand the error and trying to clean the project. I was hoping that would fix the issue and create the Binding Resource file. However after reading the error properly and reviewed the error file, I realized that the classes, `TemperatureData` and `WeatherDesc` also needs to be suitable for Data Binding. I modified the classes as below, 

```Java
public class TemperatureData extends BaseObservable {

    @Bindable
    private String day;
    @Bindable
    private String night;
    @Bindable
    private String morn;
    @Bindable
    private String eve;
    @Bindable
    private String max;
    @Bindable
    private String min;

    ...
}

```

After making the above changes, I was able to run the app without any crashes. 

I made few changes after to load the images using `Picasso` following the article from [here](https://android.jlelse.eu/loading-images-with-data-binding-and-picasso-555dad683fdc), that explains way better. I do not want to take credit or duplicate the effort here. 

This was a simple implementation and I'm still learning. I hope to write more, probably like a series of blogs on Data binding as I learn adn try different things.

*[This post is also available on DEV.](https://dev.to/subbramanil/android-data-binding)*


    


Notes from learning Android Data binding from Pluralsight course as well from other resources

Android Data Binding


We have been using *AlertDialogs* to alert the user as any android app does. Alert Dialogs are great and easy way to notify the user about an issue or action that needed to be perform. However there are several times, I find myself looking at lots of duplication of alert dialogs creation and management logic and inconsistent styles across various activities and fragments. To solve the issue, I started a small module using **MVP** design pattern following some good articles from the web. 

On completion the Error Control Module looks like this, 

```
|  
|--- ErrorHandler  
|--- ErrorPresenter   
|--- ErrorPresenterImpl  
|--- ErrorInteractor  
|--- ErrorInteractorImpl  
|--- ErrorCodes  
|--- ErrorResources  
|--- MaterialDialog  
|--- DialogView  
|--- DialogType  
```

*ErrorHandler* is a singleton that handles the management of creating Alert Dialogs. The MVP design pattern is implemented using the *ErrorInteractor*(Model), *DialogView*(View), *ErrorPresenter*(Presenter) interfaces. I am working on creating a android library project based on the **MVP** implementation and I will write another blog about it. 

At the end, the code snippet to create Alert Dialog looks like this, 
```Java
 errorHandlingDialog = errorHandler.createDialog(DialogType.ERROR);
 errorHandlingDialog.setErrorCode(errorCode);        
 errorHandlingDialog.showOkayButton(true, okBtnTxt);
 errorHandlingDialog.setOnConfirmListener(okBtnlistener);        
 errorHandlingDialog.showCancelButton(true, cancelBtnTxt);
 errorHandlingDialog.setOnCancelListener(cancelBtnlistener);
 errorHandlingDialog.show();
```

And the dialog was created as below, 

```Java
 private void createDialog(DialogType dialogType) {
    AlertDialog.Builder builder = new AlertDialog.Builder(mContext, R.style.error_dialog_style);

    View mDialogView = LayoutInflater.from(mContext).inflate(R.layout.material_dialog, null, false);
    mDialogTitleView = (AppCompatTextView) mDialogView.findViewById(R.id.AlertDialogTitle);
    mDialogContentView = (AppCompatTextView) mDialogView.findViewById(R.id.AlertDialogContent);
    mDialogExtraContentView = (AppCompatTextView) mDialogView.findViewById(R.id.AlertDialogExtraContent);

    mDialogCancelBtn = (AppCompatButton) mDialogView.findViewById(R.id.AlertCancelButton);
    mDialogOkayBtn = (AppCompatButton) mDialogView.findViewById(R.id.AlertConfirmButton);

    builder.setView(mDialogView);
    
    switch (dialogType) {
        case ERROR:
            builder.setCancelable(false);
            break;
        case WARNING:
            builder.setCancelable(true);
            break;
        case INFO:
            builder.setCancelable(true);
            break;
    }
    mDialog = builder.create();
    mDialog.getWindow().setLayout(500, WindowManager.LayoutParams.WRAP_CONTENT);
}
```

The layout file looks like this,

```xml
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:background="@color/dialog_bgcolor"
    android:orientation="vertical"
    android:padding="@dimen/_30dp">
     <android.support.v7.widget.AppCompatTextView
        android:id="@+id/AlertDialogTitle"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"/>

    <android.support.v7.widget.AppCompatTextView
        android:id="@+idAlertDialogContent"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"/>

    <android.support.v7.widget.AppCompatTextView
        android:id="@+id/AlertDialogExtraContent"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"/>

    <android.support.v7.widget.AppCompatButton
        android:id="@+id/AlertCancelButton"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/error_handling_cancel_text"/>

    <android.support.v7.widget.AppCompatButton
        android:id="@+id/AlertConfirmButton"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/error_handling_okay_text"/>

</RelativeLayout>
```

To the obvious eyes, the code snippets do make sense and appear to be working. We thought so and it was working. It passed the Unit testing. However when we started integrating the code to the app and used it to replace the *duplicated* 'alert dialog, we started noticing a strange crash occurring. 

```
java.lang.ClassCastException: android.widget.LinearLayout$LayoutParams cannot be cast to com.android.internal.widget.ActionBarOverlayLayout$LayoutParams
```

The stack trace didn't point to any code in the app, rather to android views. We realized that we were messing up somewhere but it didn't occur to us to review the dialog creation code. 

After goofing around the app code and trying to recreate the issue, one of the developer found out the crash didn't happen until, the dialog was shown. i.e., Until ``errorHandlingDialog.show()`` was called. 

Debugging the code for further, we found out that the below line was causing the crash. 

```Java
mDialog.getWindow().setLayout(500, WindowManager.LayoutParams.WRAP_CONTENT);
```

With some help from *google*, I found out that the issue was related to incorrect usage of layout parameters and positioning. 

>  Links that were helpful: 
> 1. [Layout Parameters for Alert Dialog](http://stackoverflow.com/questions/33171114/what-layoutparams-should-be-used-in-an-alertdialog)
> 2. [Specifying Custom Dialog View Size](http://stackoverflow.com/questions/37514116/how-to-specify-correct-dialog-size-in-xml-layout-file-for-android-dialog)

I updated the code as below, 

```Java
mDialog = dialogBuilder.create();
Window window = mDialog.getWindow();
if (window != null) {
    window.setLayout(LinearLayout.LayoutParams.WRAP_CONTENT, LinearLayout.LayoutParams.WRAP_CONTENT);
    window.setGravity(Gravity.CENTER);
}
```

and modified the *layout_width* and *layout_height* from *match_parent* to *wrap_content*

```xml
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content">

</RelativeLayout>
```

Now the code made more sense and I thought that I'm done. However I was presented with another surprising and weird(Since I didn't understand the code first) issue. 

```log
java.lang.IllegalStateException: ActionBarView can only be used with android:layout_width="match_parent" (or fill_parent)
```

And again stack trace didn't point to the app, but this time I was ready for it. 

I realized the issue is somewhere in setting the width of the view. I wasn't using any style for alert dialogs earlier and I decided to make use of it. 

> Link that was helpful:
> [Provide valid parent theme for Alert Dialogs](https://issuetracker.google.com/issues/36931487)

I created a style as below and applied to alert dialogs. 

```xml
<style name="AppTheme.Dialog" parent="android:Theme.Light">
    <item name="android:windowNoTitle">true</item>
    <item name="android:windowFrame">@null</item>
    <item name="android:windowIsFloating">true</item>
    <item name="android:windowContentOverlay">@null</item>
    <item name="android:maxWidth">500dp</item>
    <item name="android:windowAnimationStyle">@android:style/Animation.Dialog</item>
</style>

<style name="error_dialog_style" parent="@style/AppTheme.Dialog">

</style>

```

```Java
AlertDialog.Builder dialogBuilder = new AlertDialog.Builder(mContext, R.style.error_dialog_style);
```

And that finally fixed the Illegal State Exception crash. Finally our app now has beautiful and uniform alert dialogs with additional benefit of reduced duplication of code. **_Hurray!!_**

*[This post is also available on DEV.](https://dev.to/subbramanil/custom-alert-dialogs-with-appcompatview)*


Alert Dialogs with Custom Views


I have been coding for 5 years.

You can find me on GitHub as [subbramanil](https://github.com/subbramanil)

I live in Dallas, Tx. 

I mostly program in these languages: Kotlin, Java, Bash, NodeJs.

I am currently working on Android App Development.

Nice to meet you!

*[This post is also available on DEV.](https://dev.to/subbramanil/hi-im-subbramanian-lakshmanan)*
