DEV Community: Kshitij Aggarwal

2026 New Year Keyboard Upgrade

Kshitij Aggarwal — Tue, 27 Jan 2026 08:20:59 +0000

To kick off 2026, I finally did two things I had been postponing: some long overdue switch maintenance and a small but meaningful keycap upgrade.

The keyboard is a Pteron36 designed by Harshit Goel. It is a minimalist split build intended to work well with compact layouts like Miryoku, where layers + home row modifiers let ~36 keys cover the operations usually spread across an 87–112 key keyboard.

I also do not type on QWERTY — I use the Workman layout. I will do a separate post on why and how I transitioned. Workman Layout

Maintenance: Why and What?

After ~5 years of heavy use and dust + grime built up, the switches started feeling scratchy. The ideal fix is usually to open each switch and lube the stem + springs—but my switches are soldered to the PCB, and I did not have the bandwidth or the motivation to desolder and fully disassemble everything.

So I went with lazy lubing: pressed the stem down and apply lube to the inside walls of the housing and the exposed sides of the stem. It does not reach the springs, but it can still reduce friction and smooth out the keypress.

For lube, I used Krytox GPL 205g0, a common choice in the keyboard hobby.

The Upgrade: Keycaps That Fake a Key Well

I had originally planned a bigger upgrade: moving to a Dactyl Manuform style board with a concave "key well," since that curvature can make finger travel feel more natural.

But after talking to a few folks in the ergonomic keyboard community, I pivoted to a lighter change: trying KLP Lamé keycaps. These are sculpted, curved keycaps designed to reduce vertical finger travel and create a pseudo key-well effect on flatter boards.

I found a 3D printing service that could print them in resin. The shape makes the rows feel "guided", especially when reaching above/below the home row.

Result

After lubing, the board feels noticeably smoother and the scratchiness is largely gone. The keycaps are still an adjustment, but it is a good one—my fingers feel like they "land" sooner than they used to, especially on vertical reaches.

Beyond the Visuals: Why Audio UX is Critical in Android XR

Kshitij Aggarwal — Sat, 27 Dec 2025 13:27:22 +0000

Lessons learned from my first Android XR sample app.

Audio UX is often treated as an afterthought in application development, but in Android XR and smart glass experiences, it has to be a priority.

I recently built my first Android XR sample app. Drawing from my years of experience building software for smart glasses an Envision AI, one truth remains constant: robust Audio feedback is the difference between a novelty demo and a successful daily-driver product.

The Why: It’s Not Just About the Screen

Why should developers prioritize audio in a visual medium?

The "Real World" Distraction

Unlike VR, where the user is fully enclosed, XR and Augmented Reality allow the user to see the real world. There is a high probability the user is focused on their environment, not your "Heads Up Display." Audio cues grab attention without forcing the user to refocus their eyes.
Display Constraints

In some smart glass form factors, the display may be off or missing altogether, or the user may be in bright sunlight where optics are washed out. In these scenarios, voice becomes the primary interface.
Accessibility is Mandatory

For Blind and Low Vision users, a visual-only AR interface is unusable. Voice output is not just a feature; it is the only bridge to understanding what is happening in the application.

What constitutes a Good Audio UX

To build a cohesive Audio UX, your application needs to cover these bases:

Welcome Greeting and Exit salutation:

Always let user know when the app starts and stops to ensure they are aware if the app is working.
Touch bar feedback:

All Touch area interactions should have an immediate audio feedback so that users know if there action was registered
Interaction updates:

Give verbal updates of the current status of the user requested action. For eg. Loading, Success or Error state
User requested status updates:

User may not always be paying attention to what's happening in the app and forget what the current state of the app. A single tap by the user should be able to tell the user about the current status of the app or the result of their last interaction.

Verbal vs. Non-Verbal

While chimes and beeps (Earcons) are great for clicks, they have a steep learning curve for complex status updates. Don't force users to memorize what "Beep-Boop-Boop" means.

Rule of Thumb: Use sounds for actions (clicks, swipes), and use Text-to-Speech (TTS) for information. It is always clearer to speak the output in the user's language than to rely on abstract sounds.

Conclusion

With the advent of Android XR, we are going to see a flood of applications targeting head-worn devices. While current marketing hype focuses heavily on the visual fidelity of VR and AR, the most successful applications will be the ones that master the invisible interface: Audio.

Moving Away from Gitflow and Feature Branches

Kshitij Aggarwal — Thu, 17 Jul 2025 04:45:19 +0000

Intro

As the title suggests, this post is a case study on how Gitflow and traditional feature branching have been hindering our current development process. I'll share the attempts I'm making to resolve some of the key issues we're facing as an Android development team.

Current Setup & Issues

The Setup

We are a small, fully-remote team of developers who have been using Gitflow as our Git branching model, coupled with a standard Merge Request (MR) and Code Review process.

Code Repository & Planning: We use GitLab as our code repository, leveraging its issues feature for planning and tracking our development work.
Workflow: All planned work first moves into our Kanban board, gets assigned, and is then picked up based on priority. Tickets are broadly defined, with one issue per feature or significant piece of work, regardless of its size.
Development Process: Once a developer picks up a task:
- They create a Gitflow-style feature branch in the format feature/<issue-id>-<issue-title> from our dev branch.
- We maintain Gitflow-style branches for our active development, beta, and production channels, using release tags to mark each public beta and production release.
- Developers work in isolation within their feature branches until the assigned work is completely done, tested, and verified. Although we might switch between branches for urgent bugs or enhancements, the core feature work remains siloed.
- Consequently, a feature—regardless of whether it takes a day, a week, or two weeks—is never merged back into dev until its Merge Request is created, and the code is thoroughly tested, reviewed, and approved by other team members.

Issues Faced

Delayed Shipping: Features face multiple bottlenecks, remaining unshipped until development, testing, review, merging, and re-testing are all complete.
Review Process Overheads: The process is further complicated by potential issues raised during reviews and inevitable merge conflicts.
Code Review Quality: Reviewing becomes challenging and less effective when Merge Requests contain hundreds of new or modified lines.
Availability Challenges: Other team members are not always consistently available to review such large code changes in one go.
Merge Conflict Headaches: We often face the painstaking task of fixing merge conflicts, trying not to mess up the original developer's work.
Ineffective dev Merges: While we try to regularly merge dev into active feature branches, this doesn't guarantee a conflict-free merge when integrating other people's work.
Release Delays: Ultimately, our feature releases end up getting delayed because they're waiting on multiple rounds of merges and approvals.

Search for a Solution

Problem Identification: After being repeatedly impacted by our current process, I wanted to find possible ways to fix this problem.
Belief in Solved Problem: I was sure this must be a solved problem, as we couldn't be the only small team facing this issue.
Inspiration from Dave Farley: Luckily, around this time, I came across a video by Dave Farley discussing a similar topic and how feature branching often goes against the philosophy of Continuous Integration (CI).
Deep Dive: This led me down a rabbit hole in search of alternative solutions to make our development process faster, without duplicated work or additional delays.

Learnings

Here are some key learnings from my deep dive:

Code reviews don't primarily check for stability. Their main purpose is to ensure the code adheres to team-defined standards.
Delaying releases for code reviews doesn't ensure stable output. Only thorough testing guarantees stability.
Merge Requests were primarily introduced for open-source projects where contributors were not given direct access to push code to stable branches.
Merge Requests and code reviews are often considered "process gates." These can slow down the overall development process without adding significant benefits to the quality of the deliverable or its underlying implementation.

Shortlisted Ideas

After reviewing a bunch of reference material and having multiple discussions with other people in this field, I found the following three solutions that, when integrated, might work for our team:

Vertical Slicing

No more single, monolithic tickets per feature.
Each feature is meticulously broken down into smaller tasks, ensuring only small chunks of work are completed and committed.
Each major feature or change is considered an epic, and then sub-tasks are created to slice out smaller, logical chunks.

Trunk-Based Development (TBD)

The team develops off of the same main branch without creating dedicated feature branches.
Developers push their changes directly to this main branch, and these changes are immediately available to everyone else when they pull.
This approach ensures the codebase is always merged and conflict-free at all times.
Combined with vertical slicing, commits become small, easy to merge, and straightforward to review.
It removes much of the ceremony around code merging and code reviews, as these now happen continuously, often multiple times a day.

Feature Flags

To hide unfinished and unstable work, feature flags are used to safely ship releases containing completed work from the main development branch.
Developers can toggle features on/off at any time to test work developed by others and themselves.
To ship a feature to users, once it's fully tested, its respective feature flag can either be entirely removed or migrated to a remote configuration flag to control public availability.
This practice is also known as "Dark Releases."

Some other solutions I researched but decided not to pursue for now:

Pair Programming: Being a very small team, pair programming was never a viable option for us due to limited resource allocation. While it's a great concept popularized by Extreme Programming, it doesn't fit our current constraints.

Updated Process (as of July 2025)

Based on the shortlisted solutions above, I plan to introduce the following changes to our current development process:

GitLab Vertical Slicing

We will continue to create issues for features and tasks, but now, within each GitLab issue, we will create sub-tasks to define smaller, more manageable slices of work.
In GitLab, each sub-task gets its own unique ID. We will use this ID in our commit messages to connect the sub-task with the commit.
If a sub-task proves too large or lacks detail during development, we will create additional sub-tasks within the same ticket. The objective is always to ensure each sub-task represents a limited amount of work, resulting in minimal commits and changes.
One slicing strategy will be based on architectural layers. Every feature can be broken into a minimum of four sub-tasks, one for each:
- Data Layer
- Domain Layer
- UI Layer
- Integration of all three layers

dev-Based Development (Trunk-Based)

All development will happen directly on the dev branch. We will no longer use Gitflow-based feature branching.
Feature branches will only be used for rare, truly experimental work.
Developers are expected to self-test and self-review all code thoroughly before pushing to the origin.
Code reviews will happen continuously: every time new changes are pulled from the origin. There will be no more explicit code review flow; everyone is expected to review the changes being pulled.
Any code review comments will be communicated via the GitLab commit screen.
Commits should contain the sub-task ID in the commit message. If relevant, create a new sub-task if one is missing.
Commits should be pushed to the origin at least once a day.

Dark Releases with Feature Flags

Implementing this process requires some project-level setup. This is critical to ensure unfinished features and changes are never accidentally shipped to the public.

Feature Flags will live in their own independent data store (e.g., a dedicated feature flag service or a specific database table).
Feature Flags can be toggled on/off from a developer-only menu within the app.
Every new feature development will begin with the creation of its unique feature flag.
All Feature Flags will automatically be disabled for release builds to prevent accidental feature releases to the public.
Once a feature is completed and tested internally, its feature flag will either be fully removed or migrated to a remote configuration flag for controlled public availability.

Conclusion

Moving away from our old Gitflow process is a big step for our Android team. By using Vertical Slicing, Trunk-Based Development, and Feature Flags, we aim to make our work smoother, remove roadblocks, and get new features out faster.
We believe these changes will help us work together better, integrate code more often, and lead to better quality, fewer problems, and quicker releases. This is all about making our development process work best for our small, remote team, so we can deliver great features more easily and with more confidence. We also understand that this process is new, and we're open to making more changes as our team gets used to it and grows.

References

Gitflow Cheatsheet
Continuous Integration vs Feature Branch Workflow - YouTube
Why Pull Requests Are A BAD IDEA - YouTube
I’ve Found Something BETTER Than Pull Requests... - YouTube

Android Logging Performance Improvements in Production

Kshitij Aggarwal — Thu, 20 Jun 2024 06:59:38 +0000

When logging in production using timber, you can easily exclude certain log levels to prevent sensitive debug data from transmitting online.

private inner class CrashReportingTree : Timber.Tree() {
        override fun log(priority: Int, tag: String?, logMessage: String, throwable: Throwable?) {
            if (priority == Log.ERROR || priority == Log.INFO) {
                FirebaseCrashlytics.getInstance().log(logMessage)
                if (throwable != null) {
                    FirebaseCrashlytics.getInstance().recordException(throwable)
                }
            } else return
        }
    }

What this doesnt do is ignore the said logs. If timber comes across a debug log in the above case, it will still be processed completely until the time comes to actually log it, for e.g. operations like formatting and splitting. This can create a performance overhead in production if the logging is being done generously and with potentially large data like network request results.

There is a way where you can tell Timber if it should ignore certain log types completely and not process the log message at all.

private class CrashReportingTree : Timber.Tree() {  
    override fun log(priority: Int, tag: String?, logMessage: String, throwable: Throwable?) {  
        if (!isLoggable(tag, priority)) {  
            return // Skip logging if not loggable  
        } else {  
            FirebaseCrashlytics.getInstance().log(logMessage)  
            if (throwable != null) {  
                FirebaseCrashlytics.getInstance().recordException(throwable)  
            }  
        }  
    }  

    // Overridden to stop processing of all logs less then info level within Timber  
    override fun isLoggable(tag: String?, priority: Int): Boolean {  
        return priority >= Log.INFO  
    }  
}

Overriding isLoggable tells the Timber api to match and process only allowed log types internally before it does any processing
timber/timber/src/main/java/timber/log/Timber.kt

Hope this brings some finer performance boost to your apps

Exploring CameraX API Beta (Part -2): Image Analysis

Kshitij Aggarwal — Sat, 13 Jun 2020 14:02:05 +0000

Update since the previous post:

Exploring CameraX Beta (Part - 1): Basic Setup

Kshitij Aggarwal ・ May 18 '20

#android #kotlin #camerax

Google has release a new beta update (1.0.0-beta4) to the CameraX api and one breaking change is that when setting the createSurfaceProvider() on the viewFinder we dont need to add the cameraInfo parameter. A very small and simple change that makes things a little more simpler.

preview?.setSurfaceProvider(viewFinder.createSurfaceProvider(camera?.cameraInfo))
// changes to 
preview?.setSurfaceProvider(viewFinder.createSurfaceProvider())

In our previous post we looked at how to setup CameraX api and create a simple camera preview screen within a fragment. In this post we will talk about how to setup an 'Analysis' use-case which will use the MLKit on-device text detection to read text. There are many samples available online which show this exact same thing but what I wanted to share is how to start and stop the analysis on-demand. Every sample that I have seen till now starts the analysis on camera start and does not show how you can stop it when required.

Text Detection Implementation Steps

Include the following dependency in the module level build.gradle

  implementation 'com.google.android.gms:play-services-mlkit-text-recognition:16.0.0'

Add the following meta data to the AndroidManifest.xml

  <application ...>
    ...
    <meta-data
        android:name="com.google.mlkit.vision.DEPENDENCIES"
        android:value="ocr" />
    <!-- To use multiple models: android:value="ocr,model2,model3" -->
  </application>

Create a new TextAnalyzer class and extend ImageAnalysis.Analyzer

  class TextAnalyzer(private val result: (String) -> Unit) : ImageAnalysis.Analyzer {
    ...
  }

We will also take a callback function parameter to send result back to the calling class

Override the analyze method

  override fun analyze(imageProxy: ImageProxy) {
  }

Get the TextRecognizer instance

val recognizer = TextRecognition.getClient()

Get the image from the imageProxy param
```
val mediaImage = imageProxy.image
```
If the mediaImage is not null then execute the following code. Here we create the InputImage from the mediaImage and the rotationDegrees value from the imageProxy. We then send this inputImage to the recognizer for processing. In case of both success and failure we ensure that the imageProxy.close() is always called so CameraX api knows that the current frame processing is complete and it can move onto capturing the next frame.

    val image = InputImage.fromMediaImage(mediaImage, imageProxy.imageInfo.rotationDegrees)
    recognizer.process(image)
        .addOnSuccessListener { text ->
            Log.d(TAG, "Text ${text.text}")
            result.invoke(text.text)
            imageProxy.close()
        }
        .addOnFailureListener { e ->
            Log.e(TAG, "Mlkit processing Failed", e)
            imageProxy.close()
        }

In our camera fragment (MainFragment) we now create the analysis use case and attach to the camera object. Please note that for now we are just attaching the use case and not the analyzer itself which we just created.

  imageAnalysis = ImageAnalysis.Builder()                              
      .setTargetResolution(Size(1280, 720))                            
      .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST)
      .build()

Camera binding now changes to

  camera =
      cameraProvider.bindToLifecycle(
          this as LifecycleOwner,
          cameraSelector,
          preview,
          imageAnalysis
      )

We now add a button to the UI to enable and disable the text analysis on demand

  btn_analyze.setOnClickListener { 
      if (!featureOn) {
          featureOn = true
          imageAnalysis.setAnalyzer(cameraExecutor, TextAnalyzer() { 
              tv_result.text = it
          })
      } else {
          featureOn = false
          imageAnalysis.clearAnalyzer()
      }
  }

So now, when we have to turn on the text analysis we create a new instance of the TextAnalyzer class and set it to the imageAnalysis use-case. And on it callback result we show the text on the screen to show the detected text.
When we turn off the the text analysis, we just clear the imageAnalysis use-case from all the attached analyzers.

And that's it. Just by attaching and clearing the use-cases we can create on-demand analysis features using the CameraX api. You can find the complete source code for this post on the commit here

funkyidol / CameraXSample

Quick sample and accompanying source code on how to integrate the new CameraX API

Exploring CameraX Beta (Part - 1): Basic Setup

Kshitij Aggarwal — Mon, 18 May 2020 05:34:29 +0000

CameraX is probably one of the most requested API's that most developers dealing with the Android camera API setup are looking forward to. What the team developing the CameraX API is doing is no easy feat and this also shows in the development path of the API with pretty massive changes happening throughout the Alpha development stage. (Release notes & history)

This blog post is first of the series on CameraX where I try and explore the API (1.0.0-beta03 at the time of writing this article) in a more in-depth manner at an implementation level with a real-use setup (read 'fragments') since most of the CameraX explorations I have found have been prior to the 1.0.0-alpha7 release, which by now have been changed significantly.

Implementation Steps

The following are the implementation steps I followed to get a simple camera preview using CameraX

Include the following gradle dependencies in your project level build.gradle

   dependencies {
       // CameraX core library
       def camerax_version = '1.0.0-beta03'
       implementation "androidx.camera:camera-core:$camerax_version"

       // CameraX Camera2 extensions
       implementation "androidx.camera:camera-camera2:$camerax_version"

       // CameraX Lifecycle library
       implementation "androidx.camera:camera-lifecycle:$camerax_version"

       // CameraX View class
       implementation 'androidx.camera:camera-view:1.0.0-alpha10'
       implementation 'androidx.fragment:fragment:1.2.4'
   }

Add the PreviewView component in the fragment layout XML

   <androidx.camera.view.PreviewView
       android:id="@+id/view_finder"
       android:layout_width="match_parent"
       android:layout_height="match_parent" />

Add the Camera permissions to the AndroidManifest.xml and implement the permissions provider in your fragment

   <uses-permission android:name="android.permission.CAMERA" />

Add the following method to add the camera preview use-case to the fragment

   private fun bindCameraUseCases() {

           // Get screen metrics used to setup camera for full screen resolution
           val metrics = DisplayMetrics().also { viewFinder.display.getRealMetrics(it) }
           Log.d(TAG, "Screen metrics: ${metrics.widthPixels} x ${metrics.heightPixels}")

           val screenAspectRatio = aspectRatio(metrics.widthPixels, metrics.heightPixels)
           Log.d(TAG, "Preview aspect ratio: $screenAspectRatio")

           val rotation = viewFinder.display.rotation

           // Bind the CameraProvider to the LifeCycleOwner
           val cameraSelector = CameraSelector.Builder().requireLensFacing(lensFacing).build()
           val cameraProviderFuture = ProcessCameraProvider.getInstance(requireContext())
           cameraProviderFuture.addListener(Runnable {

               // CameraProvider
               val cameraProvider: ProcessCameraProvider = cameraProviderFuture.get()

               // Preview
               preview = Preview.Builder()
                   // We request aspect ratio but no resolution
                   .setTargetAspectRatio(screenAspectRatio)
                   // Set initial target rotation
                   .setTargetRotation(rotation)
                   .build()

               // Must unbind the use-cases before rebinding them
               cameraProvider.unbindAll()

               try {
                   // A variable number of use-cases can be passed here -
                   // camera provides access to CameraControl & CameraInfo
                   camera = cameraProvider.bindToLifecycle(this, cameraSelector, preview)

                   // Attach the viewfinder's surface provider to preview use case
                   preview?.setSurfaceProvider(viewFinder.createSurfaceProvider(camera?.cameraInfo))
               } catch (exc: Exception) {
                   Log.e(TAG, "Use case binding failed", exc)
               }

           }, ContextCompat.getMainExecutor(requireContext()))
       }

Add the following helper method to find the correct aspect ratio of the device and set it to CameraX

   private fun aspectRatio(width: Int, height: Int): Int {
       val previewRatio = max(width, height).toDouble() / min(width, height)
       if (abs(previewRatio - RATIO_4_3_VALUE) <= abs(previewRatio - RATIO_16_9_VALUE)) {
           return AspectRatio.RATIO_4_3
       }
       return AspectRatio.RATIO_16_9
   }

Start the camera

   private fun startCamera() {
       viewFinder.post {
           bindCameraUseCases()
       }
   }

That's all folks. You just need to handle the camera permissions in the usual manner and the above code will give you the basic camera preview setup. Now lets dig a little deeper and see what are we actually doing here.

Explanation

Find the device aspect ratio and rotation values We will use the DisplayMetrics API to find these values and use them later in both setting up CameraX as well as in future scenarios send this to MLKit.

   val metrics = DisplayMetrics().also { viewFinder.display.getRealMetrics(it) }
   val screenAspectRatio = aspectRatio(metrics.widthPixels, metrics.heightPixels)
   val rotation = viewFinder.display.rotation

Select which camera to use and create a ListenableFuture of the ProcessCameraProvider

   val cameraSelector = CameraSelector.Builder().requireLensFacing(lensFacing).build()
   val cameraProviderFuture = ProcessCameraProvider.getInstance(requireContext())

A ListenableFuture in short allows you to register callbacks to be executed once the asynchronous computation is complete, or if the computation is already complete, immediately. You can find more details in the official documentation
Callback for this cameraProviderFuture contains the logic for when the ProcessCameraProvider is available to prepare it to be initialized by binding it to the lifecycle and required use cases

Prepare the camera preview use case Here we prepare the camera preview use case using the aspect ratio and rotation values calculated earlier.

   preview = Preview.Builder()
       // We request aspect ratio but no resolution
       .setTargetAspectRatio(screenAspectRatio)
       // Set initial target rotation
       .setTargetRotation(rotation)
       .build()

Use-cases provide a very clear abstraction between the three main things we generally use camera for - preview the camera feed, capture from the camera feed and analyse the captured frames. CameraX provide these three use-cases as separate classes which we can extend as per our requirement. You can find more details about the use-cases in the official documentation and we will explore them further in future articles in this series.

Bind the ProcessCameraProvider to the lifecycle along with the use-cases First we have to unbind all the existing use-cases from the camera provider. If not it will throw runtime exception

   cameraProvider.unbindAll()

Binding the ProcessCameraProvider to the lifecycle is a must as this allows the CameraX API to automatically manage the camera resources bases on the provided lifecycle, reducing a lot of boilerplate code needed earlier with Camera2 API. We also attach our use-case here, Preview use-case in our sample, for the CameraX API to show the camera preview. We now take this post-binding camera instance and set it to the PreviewView object from the layout xml. This is where the preview will be rendered on the UI

   try {
       // A variable number of use-cases can be passed here -
       // camera provides access to CameraControl & CameraInfo
       camera = cameraProvider.bindToLifecycle(this, cameraSelector, preview)

       // Attach the viewfinder's surface provider to preview use case
       preview?.setSurfaceProvider(viewFinder.createSurfaceProvider(camera?.cameraInfo))
   } catch (exc: Exception) {
       Log.e(TAG, "Use case binding failed", exc)
   }

Start the camera Calling the 'bind' code in post on the viewFinder ensures that the code is called on the UI thread, which is mandatory for initiating the CameraX API. Not doing this will give a run-time exception.

   viewFinder.post {
       bindCameraUseCases()
   }

And now we have a fully functional camera preview app using CameraX. You can find the complete source code here: https://github.com/funkyidol/CameraXSample.

Hope this helps & give me a follow to receive notifications for future articles in this series.

Regolith Linux - My descent into Mouse-less navigation

Kshitij Aggarwal — Mon, 20 Apr 2020 07:12:19 +0000

What got me interested?

I like to keep things simple and stick to the defaults as much as possible (as much as I would love to customize the hell out of things, sadly I don't have that kind of time nowadays) and after distro-hopping for a while, I was happy to use stock Ubuntu.

I stuck to the non-LTS release starting from 19.04 and then upgraded to 19.10, but all this while one thing that bothered me a lot was the amount of RAM being consumed by the Gnome Window Manager. It's always fine after a fresh start or reboot at the beginning of the day with around 500-600 MB of usage but by sunset, my usage generally climbs upwards of 1.1 GB. On a 16 GB that's a huge amount especially when my Android IDE, Emulator, Browser and 5 other things are all fighting each other for the already vanishing sweet piece of RAM pie. And also there is this nagging feeling as a developer that there has to be some sort of a memory leak somewhere, because of which this process keeps increasing in size every few hours. At one point I was considering buying more RAM for my laptop just because this was becoming a daily nuisance for me.

I then started to look for a lightweight Window Managers (WM's) to replace Gnome with something more stable and easy on the memory. There are a lot of excellent options like XFCE and some others, but all of them seemed very outdated in terms of their underlying technology for 2020 (though being more stable at the same time, from what people shared on forums).

A good friend of mine (and a huge Linux advocate) had suggested me to try out i3wm (a Tiling WM - more on that later) some time back and I quickly dismissed that option at that time because I wasn't convinced about having a keyboard-driven WM. But this time around I gave it a more serious look as I was pretty pissed at Gnome and couldn't wait for the Ubuntu 20.04 update to land.

And I discovered Regolith Linux

While giving i3wm a more dedicated research time I found Regolith Linux, which instead of creating a new DE (Desktop Environment) chose to create a collection of open source components bundled in a way to make transition and usage of i3wm easier. Looking at there Github Page, its just a meta package which just holds the issue tracker and release files. It very thoughtfully combines various independent components like i3-gaps WM, Rofi application launcher and notification system, i3bar etc. to create an easy to adopt package, which otherwise takes a lot of time to setup when starting with i3wm.

Tiling Window Manager

All this combined makes up for a fairly easy to use Tiling Window Manager. A Tiling WM is a very unconventional kind of a WM where multiple applications or windows when opened together do not float or overlap each other. They only open beside each other, oriented either vertically or horizontally. No more floating windows, no hidden windows behind one another, no need for a mouse to move windows around. Everything is laid out like Tetris tiles alongside each other. And what do you do when you have too many things open at the same time or you want one of the windows to be full screen, you simply move it to a different 'workspace'. In the following sections, I will talk in more detail about how to get more comfortable with this fundamental shift in the way we use our desktop environment all the while using just the keyboard.

Installation

Regolith is available as both a pre-bundled ISO and a standalone installable PPA. I chose to install it over my current setup as a PPA.

Use the following commands to install Regolith via PPA.

$ sudo add-apt-repository ppa:regolith-linux/release
$ sudo apt install regolith-desktop

And once installed, restart and Regolith will appear as a desktop session on the login screen.

When you login, you are welcome to this screen with the quick list of keyboard shortcuts to help you start your journey on adopting Regolith. This helper overlay is what makes it so easy to start using the i3wm.

Getting Familiar

Super key is your best friend in this desktop environment. Everything that you wish to do all starts with the Super key. To show or hide this keymap overlay just press Super + Shift + ?
To launch an application, just press Super + Space to start the launcher app

I won't list all the keyboard shortcuts here which are readily available in the help menu. Rather I would talk about some common usage patterns and how to quickly get into the habit of using those patterns.

But before that, let's get a little more familiar with the environment itself.

Workspaces

On the bottom left is our workspace indicators. The workspaces are how we spread our windows around in this system instead of stacking them over each other. You start with only one workspace when you login but as you move windows around to the workspaces, they become active. The workspaces might be numbered but it's not required to use them in sequential order. You can use whichever workspaces at any given point as per your comfort. The highlighted workspace indicator will tell you which workspace is currently active.

App Launcher

Regolith bundles the 'Rofi Application Launcher' which is a type-to-search type of a launcher. Just start typing what you are looking for and it will immediately filter results based on the text. And as you use this launcher more and more it starts remembering your choices and starts showing them on first like in the image below

One thing to remember here is that 'restart' is actually 'reboot' here so it might be something to look for when starting out.

Notifications

Notifications is probably the most not-so-obvious feature in Regolith. Regolith bundles with the Rofication Notification System which takes a very bold decision of never showing an alert for your notifications, making the setup distraction-free. All new notifications received go on to incrementing a counter near the bottom right of the i3bar. There is still a notification sound but no visible UI alerts. To see the notification you press Super + n to open a rofi window showing all the notifications. This is something I like a lot since it helps alleviate visual distractions while I'm doing deep work.

Now the other big thing with these notifications is that they are non-actionable. You cannot click or select this notification to open the respective app which furnished the notification. For me, this needed getting used to as with the traditional notifications system we are in the habit of taking actions directly on the notification to open the respective application. But on a personal level, I am fine with it since most of the notification I receive are from Slack or Android Studio.
To delete these notifications simply press Delete to remove individual notifications or Shift + Delete to delete all notifications from a particular app.

Traditional Gnome Settings

One good thing about Regolith, which is not available in the standard i3wm setup is the availability of the traditional gnome settings manager to allow you easy access to system settings without the need of relearning anything here. Its implemented as normal floating windows easy to interact with using a mouse.

Navigation and Usage Patterns

Working with non-tillable windows
There are a few applications which work well in the tiling paradigm and can lead to some weird window placements and artifacts. This happens for me notably with the Android Emulator.

Luckily we do have an option to make any window a floating window. Pressing Super + Shift + F on the currently selected window makes if a floating one which then overlaps the rest of the environment.

But we can't simply move this window around with the mouse. Here once again we have to take help from our friend the Super key and keep it pressed to enable window dragging behavior while you move the window around using the mouse.
Setting up a workflow
The AHA moment truly came to me when I created a workflow for myself and realized how easy it is to do pretty much everything with just the keyboard. To start setting up a workflow first we have to understand that all the applications that we will be using will live on separate workspaces. So basically you have to plan your workspaces depending on the priority and frequency of the apps which are in play.
For me the browser is the go-to app, so Firefox lives in the Workspace-1. Next is Android Studio which goes in Workspace-3 and next Slack which goes in Workspace-5. I chose Workspace-3&5 because that way my most important apps are all on odd workspace numbers. On Workspace-2, I have my Notion app and Gitlab app in vertical split mode. All music players go on Workspace-4 and anything extra goes in Workspace-6. I have had to rarely use more than 6 workspaces at a given time. In the customization section, I will talk about how to automatically move windows to these workspaces at launch.
Working parallelly in multiple apps

As I mentioned earlier, in this tiling desktop environment, apps open along with each other.

When more than one app are open, they always show up dividing the currently available space in half either vertically or horizontally. By default, the apps always open split vertically side-by-side.

So the first window shows of full screen, second split it in half, the third app will split the screen in one-thirds and so on.

But instead, if I wish to open the third app split in the lower half of the right side split horizontally, I will just press the orientation modifier i.e. Super + Backspace before opening the third app. And not when I open the third app its shown like in the image below.

The power of Regolith shines especially when you have multiple apps open in the same workspace aligned in the grid pattern of your choice. To move focus between the various windows, instead of moving the mouse, you can very quickly press Super + <arrow keys> to focus on the app depending on the window layout.
Moving windows between workspaces
This point is more about adopting a new habit more than anything else. To move the currently selected window to a different workspace we press Super + Shift + <workspace number>. This moves the current window to the desired workspace while keeping you on the workspace you were on. So if I wanted to move my terminal window from Workspace-1 to 2 but while remaining on Workspace-1 then I press Super + Shift + 2. But If I want to 'take' the terminal window 'with me' to Workspace-2 then I press Super + Alt +2, This moves the terminal window to Workspace-2 and also makes it the active workspace.
Resizing windows
One behavior I was not expecting to be this easy to do without a mouse was resizing windows. Pressing Super + r starts the window edit mode where pressing 'left' or 'right' resizes the split of horizontal windows and 'up' or 'down' resizes the split for vertical windows. You can also press '+' or '-' to increase or decrease margin between the windows. With a contrasting wallpaper, it looks pretty cool. Press Esc or Super + r again to exit the edit mode.

Customization

Though I was pretty happy with the default configuration that Regolith provides for i3, there were a few things I still wanted to change to help make things easier.

But before starting any customization we first have to setup the i3 config file to modify it. Best way to do so is to follow the steps in this link

Auto open apps in specific workspaces
After you have staged the i3 config files in the path /home/<user>/.config/regolith/i3 modify the config file and append the following in the end.
```
for_window [class="Slack"] move to workspace $ws5
for_window [class="jetbrains-studio"] move to workspace $ws3
for_window [class="ICE-SSB-notion"] move to workspace $ws2
for_window [class="ICE-SSB-gitlab"] move to workspace $ws2
for_window [class="Rhythmbox"] move to workspace $ws4
```
The above code will always move my Slack window to Workspace-5, Android Studio to Workspace-3 and so on.
Hot Tip: If you want to find the name of the window to be included in the above code, just open a terminal and type xprop and then click with your mouse on the desired window. It will print a lot of window-related internal details in the terminal and you can pick up the window name from there.
Show RAM usage in bottom bar
By default the bottom i3 bar shows everything except the RAM usage which is still super awesome because most desktop environments don't show resource usage by default and you have to go hunting for an extension or app to do so. So to enable the RAM usage indicator, go to /home/<user>/.config/regolith/i3xrocks and open the config file and uncomment the following lines
```
[memory]
interval=10
```
Now just type regolith-look refresh in the terminal to show the small pie chart of the total RAM with the available RAM amount.
Add a "Clipboard Manager"
This was the most tricky thing to get working in Regolith. As a daily user of Gpaste, clipboard manager is part of my regular flow of working when copy-pasting code from Stack Overflow on to my project and because there is no default support for traditional pop-up window systems, Gpaste didn't work. After a lot of Googling and hit and trials, I landed on Greenclip. This a rofi based clipboard manager which integrates which shows the previous selections similarly to how the notifications are shown.

To install, just download the executable from the github page and add the following file to the Regolith config file
```
# Greenclip
set $greenclip /path/to/file/greenclip
bindsym $mod+Shift+v exec rofi -modi "clipboard:$greenclip print" -show clipboard
exec --no-startup-id $greenclip daemon
```
You can check out the video linked in the Greenclip Github page readme for detailed step by step instructions.

Not everything is perfect

Frankly, I don't have much to write in this section apart from the fact that using Regolith definitely had its own learning curve but not as much as a vanilla i3wm setup would be. It's obviously about what clicks for whom and putting in just the little bit of effort to becoming more productive and feel like a "Hacker Man".

Though I'm still learning the ropes of using more keyboard shortcuts to get a better window layout, but all that I feel will come with time as its need would move up from good-to-have to must-have

Future

Though I'm super happy with my setup right now, I find the Pop Shell extension from System76 to be really interesting. This extension will bring the goodness of tiling WM to the standard Gnome setup which will make it further easier to use for first time adopters. But I still can't shake the feeling that using Gnome will still be a lot more resource hungry compared to the minimalistic i3wm via Regolith. None the less I'm also looking forward to the new developments and releases of Regolith Linux and if possible consider a donation to the developers.

Effective logging in Production with Firebase Crashlytics

Kshitij Aggarwal — Thu, 25 Jul 2019 07:12:21 +0000

Logging and specifically crash logging is a very important aspect of any app that is available beyond a developers machine. Its simply the act of getting the internal application details generated at the time of the application crash. Be it available to testers or available for public use, catching crashes and identifying errors is critically important for developers to provide a quality product. In mobile app development, Firebase Crashlytics is one of the most widely used Crash logging tool. Crashlytics was build by Fabric (Owned by Twitter) and was later bought by Google and integrated within Firebase.

At Envision, we heavily rely on Crashlytics to give us the insight into our app quality and any issues our users might be facing while using our app. With Crashlytics, we get the crashes our users face, as well as any internal issues our app might be running into which are not necessarily visible to end users.

Goals

The goals we have with Crashlytics currently are:

Crash Logging
Issue Identification & Diagnosis
App Behaviour insight

Implementation

There are various features in Crashlytics that generally go unnoticed. We would like to highlight some of the ways we use Crashlytics to achieve the aforementioned goals.

P.S. - The following details are Android specific but can be easily translated for iOS. All the links below also contain the steps and details of implementing Crashlytics in iOS

Automatic Crash Logging: Part of the core feature set, automatic crash logging is what you get the moment you integrate Crashlytics in your project. You can find the integration steps here. If you want to exclude debug builds from polluting your crash logs during active development, you can follow the steps here.
Non-Fatal Logging:
Non-Fatal logging is where we start using the advanced features of Crashlytics which helps in diagnosing and fixing issues beyond the crashes logged while the app was being used. When exceptions are logged manually in Firebase, they are logged as non-fatals. The best way to use non-fatals in your app is to log all exceptions generated in the catch section of the try/catch block. Additionally, we also create exceptions and log them in situations where our app is in an undesirable state and needs to be examined for the cause and determine its effect on the app.
```
try {
      methodThatThrows()
  } catch (e: Exception) {
      Crashlytics.logException(e)
      // handle your exception here
  }
```

Debug Logging:
We use Timber for managing logs on Android and it makes it very easy for us to manage our logging in debug & production versions. The following configuration prints the logs to the console in the debug version, but in the production versions, it sends the debug logs along with the exception to Firebase.

override fun onCreate() {
      super.onCreate()
         if (!BuildConfig.DEBUG) {
             Fabric.with(this, Crashlytics())
             Timber.plant(CrashReportingTree())
         } else {
             Timber.plant(Timber.DebugTree())
         }
   }

   private inner class CrashReportingTree : Timber.Tree() {
      override fun log(priority: Int, tag: String?, message: String, throwable: Throwable?) {
         if (priority == Log.ERROR || priority == Log.DEBUG) {
            Crashlytics.log(priority, tag, message)
            if (throwable != null) {
               Crashlytics.logException(throwable)
            }
         } else return
      }
  }

User Id/Email tagging:
Firebase has the ability to attach the logs collected from a particular user to their unique UserId. This allows us to diagnose and fix issues reported to us by our users especially during the beta test phase. In Firebase console, we have the ability to filter crashes and non-fatal logs for a particular user.
Crashlytics.setUserIdentifier(userId)
App Versioning
At Envision, we try to follow proper versioning of our beta and release builds so that all the crashes and logs collected in Firebase can be quickly filtered for a specific version and fixed for the next version. This same scheme is followed for the internal test builds as well so that additional data could be logged exclusively to the test versions.

Bottlenecks

Even with all these advanced features, Firebase still falls short is some occasions.

Limited log collection storage Debug Log storage is limited to 64KB per user in firebase and older logs are deleted as new logs come in. This can be a big hindrance in issue diagnostic since many at times by the time we identify an issue and begin diagnostics, the logs are gone.
Limited filtering options The number of filtering options in Firebase is limited to app versions, crashes vs. non-fatals, and User Id. All these work fine for basic crash log usage but for more complex and rare issues these filtering options are restricting. There are no ways in which logs can be filtered out based on a specific OEM, device category or device model. This is especially useful for Android apps where the number of available devices and OEM's are huge and device specific issues are common.
No search functionality There is no search functionality in Firebase crashlytics to search for a specific crash or debug log which again becomes very essential when dealing with specific issues or diagnosing rare crashes.
Slow interface Using Firebase console overall feels very slow and bloated with very large page loading and rendering times. And that is when you are using the Chrome browser. I become much slower when using Firefox.
No custom alerts Firebase is very limited when it comes to issues or trend alerts. They only send email alerts for new issues, regression issues, and trending issues. There are no ways to create custom alerts for e.g. alerts for trends for a specific issue or specific device.
No way to directly see debug logs Currently, the only way to see debug logs os to find them inside a crash log or a non-fatal crash. We understand that the way debug logs are collected and associated on a per crash/non-fatal basis but there should be ways for us to traverse through debug logs on a per User Id or device model basis as well.
Limited dashboard & graph statistics There is only one usable graph that is presented inside Firebase Crashlytics and that is the total crash count on a day, week or month basis. There should be more ways for us to visualize the crash statistics as well. Fabric had very useful graphs on their dashboards that gave a lot of value without us to dig around for that info.

Going Forward

As our app matures and our use case, Crashlytics has come to a point where we are getting restricted on a regular basis in achieving our goals to quickly identify and resolve issues. We are now looking at some other 3rd party & more advanced crash logging solutions such as BugSnag which might be paid but add value to our product in terms of reaching higher quality.

originally posted at https://medium.com/letsenvision/effective-logging-in-production-with-firebase-crashlytics-9fb3af9f242d

Dual booting Ubuntu Budgie on Windows laptop

Kshitij Aggarwal — Wed, 10 Jul 2019 04:55:49 +0000

My thoughts on the process of installing Ubuntu Budgie in parallel to Windows 10 on a Dell Inspiron 15 7000 series laptop.

Preconfigured Dell windows machine don't make it easy for you to dual boot Linux. I really had to mess around in BIOS to make it work.

Steps that I followed:

Disable secure boot.
Change boot order
Change SSD config from RAID to AHCI (https://www.youtube.com/watch?v=9ngnIKqPOc4)

All of this creates a lot of friction and had to Google around a lot to get to this point which is not really idle for new users and experienced people alike.

My inbuilt nVidia GPU gave me a very hard time with the whole install process. My machine went blank everytime I logged into Linux. I initially couldn't understand what was happening & reinstalled Linux multiple times just to make sure the installation was fine.

Again after a lot of googling I figured out that its a nVidia driver issue so I had to

Go to command-line before login
Setup my wifi from CLI
Add the repo for drivers, Install & configure the drivers from CLI And all this on a 4k display without font scaling, so literally reading ants there.

And this whole situation can only be fixed if distros ignore nVidia hardware unless drivers are installed bcoz Distros can't bundle the proprietary drivers due to licensing issues.

After successfully installed and working, few things I'm missing from windows in Ubuntu Budgie

Factional display scaling. It's either 100% or 200%. Nothing in between
Native apps for Notion, Google Drive backup & sync. But this list used to a lot longer 4-5 yrs ago so thats a very good sign of how much the ecosystem has evolved over the years.

All this is just the initial thoughts. They will evolve I'm sure. Overall things are fine. What my expectation out of this move is a secure & a dev friendly work environment and better compilation speeds. I'm still not holding my breath for improved battery life though.

Edit:
Received some help from my twitter friends which shared the following links to help out with some of the issues
https://www.omgubuntu.co.uk/2019/06/enable-fractional-scaling-ubuntu-19-04
https://www.omgubuntu.co.uk/2019/02/odrive-google-drive-linux-client
https://www.omgubuntu.co.uk/2019/05/slimbook-battery-optimizer-ubuntu

A helpful link I found: https://medium.com/@pwaterz/how-to-dual-boot-windows-10-and-ubuntu-18-04-on-the-15-inch-dell-xps-9570-with-nvidia-1050ti-gpu-4b9a2901493d

Why becoming & staying productive in India is difficult

Kshitij Aggarwal — Mon, 03 Jun 2019 06:19:56 +0000

People talk a lot about developer productivity but some points that people don't talk about are the environmental issues, available options, and pricing at which the tools are available to the developers in a particular country. Building & maintaining a productive work environment as an independent developer in India is very costly. So costly that on average we pay 2 to 3 times & sometimes even higher for the same hardware, software, and accessories than what people have to pay outside India.

But it's not just the price but many other factors that I want to bring to your attention:

Cost Issues

Costly Hardware: General cost of hardware (laptops/computers) and their accessories (monitors/keyboard/mice) are much higher in India compared to the US or East Asian market. My current laptop (Dell 7570) which I procured from the US cost me 25% lesser than what was available in India. My recent research into external monitor pricing also revealed a difference of good 30% to 50% between various models. And all these differences are direct market pricing and don't even consider the various deals that can increase the difference to approx double.
Subpar Configuration: The configuration that is available in India for laptops, computers, monitors, etc, for the most part, can be categorized as aftermarket leftover. The kind of configurations that are offered specially for the pre-build machines like laptops is bare-bones at a price point which will generally fetch a medium level config in other markets. And even the configurations which are supposedly "maxed out" have limited RAM, SSD, or Display options. For e.g. the laptop I own now has a 4K display (which I got from the US) was not even an option in any of the configurations available in India. And again going back to the first point, the prices at which these machines are offered are way more than the maxed out options in other countries. Similarly, for monitors, the specs with which they are available in India are generally many generations old but we still have to pay the full price that is of the current generation one.
Limited Companies & options: The number of companies that are actively selling their products are just limited to very high-end brands. It's a bit contrasting in nature when compared to the mobile industry where the devices are launched in India as soon as they are announced but for computer hardware peripherals we have to wait for months and sometimes years for products to start selling locally. Sometimes they are never even bought to the Indian market altogether. Logitech, Razer, and other such peripheral companies are another example where they don't offer most of the range of their devices in the Indian market.
Non-existent Customer Support: The idea of customer support is a joke in India. Anytime you have to deal with customer support for most of the organizations, you can very well kiss your product goodbye. Apart from the handful of companies like Logitech with which I have had good experience with, most companies just fail to deliver on the concept of customer support. Whereas in the US I have heard of easy exchange or repair policies in case the hardware faces any issue, no such policy exists in India. At max, they will offer to repair your device at prices that are close to the price of the original device and take many months to repair, that too when your product is under warranty. And even if you bought your product outside India which on paper has an International warranty, customer support will deny any help citing unavailability of the configuration in India. In the end, even if you are willing to pay money for a product, keeping it alive for a natural lifespan of the product is solely based on luck.
Taxes: With the new GST (Goods & Service Tax) introduced in India in 2017 coupled with the hefty and ever-increasing import duties levied on most of the products and peripherals, we end up paying upwards of 25% of the actual price in taxes. This includes both Hardware & Software.
No deals or discounts: Indian markets don't offer the kind of deals the US or other countries might enjoy on a regular basis. And especially no Black Fridays here as well. This limits a lot of opportunities for Indian consumers to buy discounted peripherals. It's not that we don't have deals per se but when the so-called Amazon Lightning deals hover in the range of 10% discounts, it doesn't make it the most lucrative of offers.

Environmental Issues

Dust & Heat: Geographically, most of India has summers or rather hot temperatures for close to 9 months in a year topping at a good 50 degrees Celsius. This makes cooling a big challenge, especially for laptops and computers. And the more we have to cool the devices artificially, the more we have to deal with DUST. Dust is one of the biggest reasons for the small lifespan of electronic products here. Laptops & computers face the biggest challenge since they get clogged very frequently with dust and have to be cleaned regularly in order to keep them operational. Mice have it the worst when it comes to dust. Because when dust gets inside the mouse, it accumulates inside the small click mechanism of the buttons and then they start misfiring or getting stuck. Until the time I was using the regular Logitech Mouse I had to buy a new one every year since they wouldn't last more than that. The latest mouse I own is a Logitech G603, which has a 3-year warranty and I have already got it exchanged once because of the dust issue.
Difficult to create Home Offices: Room sizes in Indian Homes are generally very small and keeping a full desk with a complete external monitor setup in a regular bedroom is out of the question. And so is having a separate room for your home office. And that's because Indian homes don't have a concept of centralized cooling/heating. So every room in the house needs to be individually cooled with separate air conditioning units. And thanks to the high electricity prices, cooling multiple rooms in the house at the same time becomes financially unviable. The only option that we have is to work on our laptops and adjust between working on bed or small temporary tables.

I understand that there might be business reasons for many of the points I have shared above but at the end the fact is that we are deprived of the tools which increase the quality and the quantity of the work we put out and unless these companies start selling their products and advertise them, how can they expect to grow in one of the world's largest markets. I also understand that the government rules for entering the market and selling products in India are very difficult to work with.
For environmental reasons, there is obviously nothing that can be done and creating a setup that counters these factors are more a matter of sunk costs and high running costs.

I hope that companies around the world who work with India based Freelance Developers have some insight into issues we face that might not look apparent but are our reality with which we have to deal with. And if they really care about their productivity, they can help contribute to it by buying the required hardware and peripherals for them, as they would for an on-premise employee.

P.S. I am aware that there can be many counter-arguments to the points I have shared but do understand that they come from my personal experience of working remotely for the past 5 years from Delhi, in conditions that might be very personal to me.

Novices guide to Dependency Injection & Dagger2 - Part 2 - Benefits

Kshitij Aggarwal — Sun, 21 Apr 2019 04:26:35 +0000

In the second article of the 'Novices guide to DI', before we go into further details, lets talk about the benefits.

Why would we event want to get into the complexity of understanding DI?
What advantages do we have by changing the way we code as discussed in the previous post:

Novices guide to Dependency Injection & Dagger2 - Part 1 - Introduction

Kshitij Aggarwal ・ Feb 18 '19

#android #dagger #beginners

I believe that knowing the advantages of learning a concept gives an extra dose of motivation to break past the mental block and step outside the comfort zone and to reach a place where the complexity fades away and things become more clear.

Lets begin:

Decoupling: As discussed in the previous post of the series, the whole idea of DI is to segregate the place where an object is created and where it is consumed. This decoupling is what allows for all the benefits discussed below.
Reusability: As we now have decoupled the object creation part and shifted it away from the actual code where it gets used, we can now easily reuse it without having to write the object creation code everytime it is required in multiple places. Simply consider things like error dialogs or toast messages. If we write the dialog or toast creation code once, we dont have to write it again everytime you want to use them. Just 'inject' the object and use them.
Maintainability: Now if you explore this possibility of having all object creation code, which is written only once throughout the code base and getting re-used everywhere, how easy it would be to perform any sort of changes (for bug fixing or new features or changed functionality) in this one place and have it gets reflected everywhere automatically without having to change it again everywhere the object was being used. This reduces the number of bugs introduced due to mismatched or improper object creation.
Testability: Further benefits and probably the most important one, thanks to the object creation centralization and decoupled object usage is testing. Since we now have two different entities - the object creation and the other it's usage, we can now test both these entities independently giving us a more robust overall application. We can now test the object creation by feeding it to a test code which verifies whether the created object is working fine or not. At the same time, we can test the object consumption code by feeding it with test objects of various permutations and combinations and test how our code behaves under various conditions. I will not go much into detail on how to actually perform these testes as this is a slightly advanced topic for now.
Increased development speed: Last but the most incrementally beneficial of the advantages is the increased development speed. Sure, in the starting of a project it might feel that its taking longer to setup the whole method injection or constructor injection but as you get into the habit, it becomes much faster. And as the application size grows, the benefits of DI starts showing as the time spent of creating objects repeatedly goes away as you confidently provide the objects to classes where they are needed.

So these are some of the benefits we get when we actually jump into the world of DI. There are even further benefits to be discussed but those are more specific to using the Dagger library itself, so those I will discuss in a separate post.

In the next post we will start with looking at Dagger and how we can use it to simplify DI

Novices guide to Dependency Injection & Dagger2 - Part 1 - Introduction

Kshitij Aggarwal — Mon, 18 Feb 2019 08:41:25 +0000

This guide is an attempt to convert the difficult to understand concept of Dependency Injection into a language which is easier to understand and comprehend. This article draws all the wisdom from hundred's of sources I read to wrap my head around this concept and from using it in production application.

Defining Dependency Injection (DI)

In very simple terms, DI is trying to segregate the dependency creation and dependency calling.

Let me explain.

Dependency is any class or object that is required and is not available in the current scope. It could be a platform level class like Toast, a 3rd party library like Retrofit or your own class defined somewhere else in the project. Currently, every time you require any of these 'dependencies', you try to create its object using the new operator. Alternatively, you may try to use some design pattern like Singleton or Factory to call upon a preexisting object of the required dependency.

class User {
   private ProfessionalDetails pDetails = new ProfessionalDetails();
   private AcademeicDetails aDetails = new AcademicDetails();
}

But now let me ask you to change the way you do things a little differently. Instead of creating or accessing your dependencies directly, how about I tell you that all the dependencies you ever require are always provided to you via the method parameters and you never have to create a new object yourself. The above code will then look something like this:

class User {
   private ProfessionalDetails pDetails;
   private AcademeicDetails aDetails;

   /* Example of Method (Dependency)Injection */
   public void userDetails(ProfessionalDetails pDetails, AcademicDetails aDetails){
      this.pDetails = pDetails;
      this.aDetails = aDetails;    
   }
}

This is called Method (Dependency)Injection.

As we defined DI earlier as segregating the dependency creation and calling, here, you are not worried where or how the dependency is created, you are just concerned with using them. Similarly if any dependency you require at Class level is provided to you via the class constructor like shown below, it's called Constructor Dependency Injection.

Now as a first step, I implore all of my readers to stay with this thinking of not creating new dependency objects and to get the dependencies via method or constructor injection. And to take things a little further, if I can ask you reduce the use of class variables in your methods and try to pass the requirements via method parameters. This is something which will be useful when we look at the larger picture of testable code but more on that later.