Forem: Aniket Kadam

Write-Only Social Media

Aniket Kadam — Sun, 16 May 2021 04:05:44 +0000

Social media can help you look for jobs, be visible to people and get word out about things that could help others. At what cost though?

The current disaster is an unevenly distributed pandemic but
there have always been unevenly distributed disasters as one side of the world recovers and the other reels.

If you're in the part that's currently reeling it can be hard to open up twitter to share resources or job hunt without a forceful reminder of what the state of everything is.

To solve this problem I've been using tools that are normally used by brands to maintain a social presence, a social media tool like Buffer

Write Only Social Media

Buffer is particularly helpful because it has free accounts, is easy to use to get set up for LinkedIn and Twitter and keeps the peace-wrecking "feed" off your eyeballs.

With it you could write and post things without ever having to look at what else is happening.

If you turn on emails for twitter DM's, you won't miss those either and going straight to http://twitter.com/messages/ will bypass the feed again to reply to them.

Stay safe, stay home if you're in the currently unlucky country/city and hopefully this too will pass.

How to Raise Hell with a Vaccine Booking System

Aniket Kadam — Mon, 10 May 2021 05:20:03 +0000

If you don't know about Cowin consider yourself lucky. It's the national vaccine slot booking website created by India.
The population of Mumbai was 12.5 million at last count. It currently vaccinates approximately 58,000 people per day, down from a high of approximately 64,000 a few weeks ago. At this rate it'd take over half a year to vaccinate everyone with a single shot. More than a year to cover both shots.

Here's how Cowin works.

You can only login with an OTP send to your mobile number. This registration lasts for 15 minutes until you are logged out.
You then register upto 4 people on 1 mobile number and choose to schedule them to get vaccinated. You are presented with a list of vaccination centers.

Here's the thing though, the page on which you desperately search for open slots, doesn't check if you're authenticated. You can easily go past the 15 minute timer and be logged out but it won't tell you until you actually go to schedule a shot from a rare open slot. The time it wastes to get another OTP guarantees you'll never see that slot again.

Many people were concerned that people in tech were using bots to book slots, which they were. Now here's how to raise hell. Your system has a problem with bots.

Because your government only gave near-monopoly profits to two companies manufacturing vaccines and then delayed ordering new vaccines by a month.

Here are a whole bunch of usability absolute nightmares that are wasting the time of every Indian playing this cursed game every night while desperately trying to save their lives in the pandemic.

Double Scrolling to See the List of Slots

There is also a double scrolling bar. One which scrolls the entire page of useless graphics and another much smaller window within which the vaccination slots scroll.
Which means the size of the window dedicated to showing the slots is not much taller than the size dedicated to showing a picture of our prime minister.

Do I as a user care about the graphics on the page limiting how many vaccination centres I can see? Absolutely not. This means I have to first move my mouse within the smaller scrolling section and then scroll. Adding anxiety.

The 18-45 Filter

You need to filter by 18+ or there are too many centres. Each time you click 'Search' to look for vaccines you need to select 18+ again because the selection is cleared.
Which means along with clicking on the search button every few seconds, you again have to click on the 18+ button.

Do I as a user want my choice reset and strain my hands constantly? Why in the hell would I?

Fun fact: The API call still retrieves information for all slots. The filtering is done client side.

Time Slots

If you do see a rare centre with open slots, each centre has 4 time slots available. You need to play an elaborate guessing game to guess which slot might be free.

Do I as a consumer care right now whether my slot is in the morning or evening? I don't give a damn. Eliminate the illusion of choice by removing this option entirely and just allocate whatever. It will save server time and user anxiety.

Give us ONE option for the centre and none for the time. I promise you almost no one cares what time in the day they can save their lives.

The Errors

While the government tries very hard to pretend like the site never crashes, basically every single person who has made it down to the time slots and clicked confirm has encountered Error code 500, which means there's a bug on the server side. An exception related to bad coding that means 75% of people who are quick enough to get to slots and attempt to book, get thrown out because of the error anyway.

The technical person in charge has decided this should be a silent error and just not tell people anything. The only thing that happens is that the confirm button becomes available to be pressed again.

Conclusion

They added captchas to chowkidar (guard) the site. But the most important thing in product development is "What are your users trying to do?"
Do they want the luxury of picking a time slot? Selecting over and over that they're above 18 every few seconds? Do they want to keep a watch on the time to make sure it hasn't been 15 minutes because they're auto-logged out? Do they want to play this cursed game every night?

A user-hostile, very Indian way of solving this problem is "strict-action", "captchas" punishment and attacks.

It overloads the servers at a specific time everyday and sends the country into panic attacks over times and notifications and reds and greens.

Solutions

Something where every person registered is put into a queue, with a mild preferences as to where and when which can be analysed at leisure and people sent SMS' about when their slot might be, and the day that it is will avoid this national disgrace.

To do this however, we have to abandon something truly Indian. The concept of "strict action" and move towards smarter solutions that work for the people who need them.

Kotlin Flow - Implementing an Android Timer

Aniket Kadam — Tue, 13 Apr 2021 17:52:25 +0000

How complex could a timer be? We're about to find out in this dive into understanding Kotlin Flows by implementing one.

We'll be building out the logic with Kotlin Flows in a ViewModel and showing the timer with a Jetpack Compose, Composable. State will be represented with StateFlow.

What's in a timer?

You have an initial state, when the timer's inactive.
You have it counting down after it's tapped.
It resets when it's done.

If you want a jump start by looking at the code here it is.

The UI

The UI part of the timer will be represented by a CircularProgressIndicator and a Text that shows the value of the countdown numerically. The timer only starts when it's tapped and another tap resets it.

Here's the UI code.



@Composable
fun TimerDisplay(timerState: TimerState, toggleStartStop: () -> Unit) {
    Box(contentAlignment = Alignment.Center) {
        CircularProgressIndicator(
            timerState.progressPercentage,
            Modifier.clickable { toggleStartStop() })

        Text(timerState.displaySeconds)
    }
}

TimerState is a helper class. All it contains is the progress percentage (When 30 seconds elapses on a 60 second timer, that's 0.5% progress for the CircularProgressIndicator), and the text to show for seconds remaining.

With TimerState, you can provide the remaining seconds and total seconds and it calculates the rest of the information for the Composable.

Here's the code for TimerState



data class TimerState(
    val secondsRemaining: Int? = null,
    val totalSeconds: Int = 60,
    val textWhenStopped: String = "-"
) {
    val displaySeconds: String = 
         (secondsRemaining ?: textWhenStopped).toString()

    // Show 100% if seconds remaining is null
    val progressPercentage: Float = 
        (secondsRemaining ?: totalSeconds) / totalSeconds.toFloat()

    // Always implement toString from Effective Java Item 9
    override fun toString(): String = "Seconds Remaining $secondsRemaining, totalSeconds: $totalSeconds, progress: $progressPercentage"

}

There are some nuances about it you can read or skip. The nuances are, what do you show when the timer is stopped? For this data class, stopped is represented by the int for remaining seconds being null. By providing only secondsRemaining and totalSeconds the rest of the information which our TimerDisplay needs is calculated.

The Flow of Logic

I'm going to encapsulate the logic for the timer in a class called a TimerUseCase.
Here's how it's going to work.



(totalSeconds downTo 0).asFlow()

Effectively creates a list of numbers from the total number of seconds to 0 and emits them one by one as a Flow.
If totalSeconds was 5, we'd get 5,4,3,2,1,0 emitted.
In the final code we'd subtract this by 1 but we'll see why in a bit. Psst, it's related on the onStart.



(totalSeconds downTo 0).asFlow()
.onEach { delay(1000) }

Means whenever an item is emitted from this Flow, first we'll wait for 1 second and then let it proceed down the chain.
This is how the ticking of the timer is implemented.



.transform { remainingSeconds: Int ->
                emit(TimeState(remainingSeconds))
            }

This could've just been the next in the chain however there's a problem if we write it that way.
Here the only thing we're doing is creating a TimeState but if there was a more complex operation to be performed, it could take several milliseconds and now we're forcing time drift in the flow chain.
Here's an example. If it takes 1 second to emit the next remaining second but another 200ms to create an object like TimeState, then 1200ms have passed before the next item can be emitted. If this cycle repeats many times over the timer wouldn't be accurate anymore.

So we need something in between. Here's the actual code with 'conflate' being used to run the transform function concurrently (at the same time) on a separate thread from the one that ticks for time.

Also if the code was left as it was, you'd only see the timer begin to tick one second after you tapped it. We want it immediately showing the full time and then begin to tick so we make two modifications.

When the Flow is engaged, we immediately emit the total seconds as the first value on the countdown. Which means emitting totalSeconds with onStart. ```kotlin

.onStart { emit(totalSeconds) }

Then, the flow actually emits its first delayed value. The one for the next second. That's why the flow starts with
```kotlin


(totalSeconds - 1 downTo 0).asFlow()

Here's the code:



    /**
     * The timer emits the total seconds immediately.
     * Each second after that, it will emit the next value.
     */
    fun initTimer(totalSeconds: Int): Flow<TimeState> =
        (totalSeconds - 1 downTo 0).asFlow() // Emit total - 1 because the first was emitted onStart
            .onEach { delay(1000) } // Each second later emit a number
            .onStart { emit(totalSeconds) } // Emit total seconds immediately
            .conflate() // In case the creating of State takes some time, conflate keeps the time ticking separately
            .transform { remainingSeconds: Int ->
                emit(TimeState(remainingSeconds))
            }

Additional conditions

We're not done yet!
As it is, the timer can't handle being cancelled nor resetting to a default value once it's done counting. For that we'll need to set onCompletion when it's launched.

Here it is:



private var _timerStateFlow = MutableStateFlow(TimerState())
val timerStateFlow: StateFlow<TimerState> = _timerStateFlow

We'll need to create a private MutableStateFlow to emit the TimerState and a public StateFlow to be bound to the composeable.



    private var job: Job? = null

    fun toggleTime(totalSeconds: Int) {
        if (job == null) {
            job = timerScope.launch {...}
        } else {
            job?.cancel()
            job = null
        }
    }

Once the toggleTime function is called, if there was no Coroutine Job running earlier, it begins a new one.
If this is tapped again, it will cancel the currently running job.



job = timerScope.launch {
                initTimer(totalSeconds)
                    .onCompletion { _timerStateFlow.emit(TimerState()) }
                    .collect { _timerStateFlow.emit(it) }
            }

The onCompletion block is like a 'finally'. Whether the Flow completed normally or with an error, the onCompletion block will be called and reset the TimeState so the UI can be reset.
Also in the collect, we put the received TimeState into the TimerStateFlow for the UI to observe.

Here's it all together.



class TimerUseCase(private val timerScope: CoroutineScope) {

private var _timerStateFlow = MutableStateFlow(TimerState())
val timerStateFlow: StateFlow<TimerState> = _timerStateFlow

private var job: Job? = null

fun toggleTime(totalSeconds: Int) {
    if (job == null) {
        job = timerScope.launch {
            initTimer(totalSeconds)
                .onCompletion { _timerStateFlow.emit(TimerState()) }
                .collect { _timerStateFlow.emit(it) }
        }
    } else {
        job?.cancel()
        job = null
    }
}
/**
 * The timer emits the total seconds immediately.
 * Each second after that, it will emit the next value.
 */
private fun initTimer(totalSeconds: Int): Flow<TimerState> =
//        generateSequence(totalSeconds - 1 ) { it - 1 }.asFlow()
    (totalSeconds - 1 downTo 0).asFlow() // Emit total - 1 because the first was emitted onStart
        .onEach { delay(1000) } // Each second later emit a number
        .onStart { emit(totalSeconds) } // Emit total seconds immediately
        .conflate() // In case the operation onTick takes some time, conflate keeps the time ticking separately
        .transform { remainingSeconds: Int ->
            emit(TimerState(remainingSeconds))
        }
}
}

The ViewModel

Doing all that work in the UseCase frees up the ViewModel to be very clean like so.



class TimerVm : ViewModel() {

    private val timerIntent = TimerUseCase(viewModelScope)
    val timerStateFlow: StateFlow<TimerState> = timerIntent.timerStateFlow

    fun toggleStart() = timerIntent.toggleTime(60)
}

And finally it's used in the MainActivity like so:



val vm = viewModel<TimerVm>()
val timerState = vm.timerStateFlow.collectAsState()
TimerDisplay(timerState.value, vm::toggleStart)

You've now got a great timer that'll always behave! You might have learned a few things about encapsulation, coroutines and Jetpack Compose along the way too!

I'm on the lookout for a Senior Android position with great customer impact, a great team and great compensation. Let me know if you're hiring! Also open to consulting contracts.

Snackbars Without Scaffolds (and why you should avoid them)

Aniket Kadam — Sun, 11 Apr 2021 14:36:45 +0000

Considerations

Sometimes you might run into a situation where you need a Snackbar in a layout that can't have a Scaffold.
For instance, if you wanted a modal BottomSheet and a Scaffold, those aren't two things you can easily use together. Mainly because the ModalBottomSheetLayout doesn't have a SnackbarHost and doesn't play nicely with other wrapping layouts.
In this case, you'd have to create and more importantly place your own SnackBarHost.

Placement Methods

Take a look at the Scaffold.kt's code for placing Snackbars, it involves measuring the Snackbar and calculating an avoidance of the Fab button and such.
Perhaps you'd reconsider your layout to see if it's worth this?

Creating it

It's quite simple to create it though!



@Composable
fun SnacksNoScafs() {

    val snackState = remember { SnackbarHostState() }
    val snackScope = rememberCoroutineScope()

    SnackbarHost(hostState = snackState, Modifier)

    fun launchSnackBar() {
        snackScope.launch { snackState.showSnackbar("Sup? Here's some snacks.") }
    }

    Button(::launchSnackBar) {
        Text("Show Snackbar")
    }
}

Without additional placement information the host ends up at the top like so:

Let me know if you end up needing to use these two and how you dealt with the tradeoffs yourself.

This was valid as of Jetpack Compose beta 3.

I'm on the lookout for a Senior Android position with great customer impact, a great team and great compensation. Let me know if you're hiring! Also open to consulting contracts.

How to Add a Snackbar to Jetpack Compose

Aniket Kadam — Wed, 07 Apr 2021 06:32:22 +0000

Snackbars are now the default way to show transitory information in Android. They replaced Toasts a while ago and for good reason!

If you're using Jetpack Compose, it's a bit of a procedure to use them though. Here's how you do it.

If you need a quick refresher, here's the answer. Don't worry if it doesn't make sense, I'll explain all the components by the end of the article.

snackbarCoroutineScope.launch{
    scaffoldState.snackbarHostState.showSnackbar("Snacks in Compose")
}

Note: This is valid as of Jetpack Compose Beta 3 (1.0.0-beta03)

Starting With a Button

We'll start off with a Compose UI that has a button which prints a log and then instead of a log, we'll get to a point where it can show a Snackbar.

Here's that button printing a log.

@Composable
fun MainScreenUI() {
    Button(onClick = { Log.d("tag", "Button Clicked") }) {
        Text("Click Me")
    }
}

For a conventional Snackbar, you need a Scaffold. A scaffold is a container that makes it easy to add all kinds of standard UI like top bars, bottom bars and even places the Snackbar conveniently for you. The 'state' of the Snackbar is held within the state of the Scaffold.

I'm guessing you already have some UI in a Compose function so just add a Scaffold to the top.

Halfway There, Adding the Scaffold

@Composable
fun MainScreenUI() {

    Scaffold {
        Button(onClick = { Log.d("tag", "Button Clicked") }) {
            Text("Click Me")
        }
    }

}

Now we need two things:

A ScaffoldState so we can get at the SnackbarState within it.
Snackbars are generally animated and do some background work to appear so we also need a CoroutineScope to run their background work in.

Personally I think it's a bit strange that we've got to handle the background animation of the Snackbar ourselves but that's the api.

Getting To the SnackbarState

First we'll add the ScaffoldState


@Composable
fun MainScreenUI() {

    val scaffoldState = rememberScaffoldState()

    Scaffold(scaffoldState = scaffoldState) {
        Button(onClick = { Log.d("tag", "Button Clicked") }) {
            Text("Click Me")
        }
    }

}

Note: We'll be using 'remember' which wraps a state object for the ScaffoldState into a value that persists after recompositions. If you want more details on that, ask me on Twitter I'll be happy to answer.

Now we'll create a CoroutineScope for the SnackBar and launch it, in place of the log!

The Complete Code

@Composable
fun MainScreenUI() {

    val scaffoldState = rememberScaffoldState()
    val snackbarCoroutineScope = rememberCoroutineScope()

    Scaffold(scaffoldState = scaffoldState) {
        Button(onClick = { 
            snackbarCoroutineScope.launch {
                scaffoldState.snackbarHostState.showSnackbar("Button Clicked")
            }
        } ) {
            Text("Click Me")
        }
    }

}

As you can see, finally it all comes down the line:

snackbarCoroutineScope.launch {
    scaffoldState.snackbarHostState.showSnackbar("Button Clicked")
}

The SnackbarState is within the ScaffoldState we retrieved. The new CoroutineScope we created is used to launch the snackbar.

Easy as pie! Once you know what's going on that is.

I'm on the lookout for a Senior Android position with great customer impact, a great team and great compensation. Let me know if you're hiring! Also open to consulting contracts.

Notes on a Heap

Aniket Kadam — Sun, 09 Aug 2020 05:39:48 +0000

As usual I learned about heaps from two places:

Vaidehi's BaseCS
Introduction to Algorithms

What's a heap?

A binary tree
Parents are always greater than their children (max-heap) OR
Parents are always smaller than their children (min-heap)

Implementation Notes:

Instead of a node object structure, it's most useful to use a simple array to represent this.

This is because we need:

Rapid access to the last element in the heap (which always happens to be the last element in the array)
Easy ways to swap the values of two nodes while leaving all their children the same.

So the maths that puts this in order is:

For a 0 indexed array
The left child of an index is at 2i + 1
The right child of an index is at 2i + 2
You'd need the equation for the parent but it's best to calculate it from 2*parentIndex + 1 = childIndex to get (childIndex - 1)/2
As long as you keep the entire calculation in Int, your language will round it off appropriately whether it's actually the left child or not.
Since you'd either end up with a .5 value if it was the right child, which rounds down to the correct parent index, or the actual parent index as an Integer.

Kotlin Implementation

Easier to use a mutableList and a recursive implementation.
You'd need to use removeElementAt(size - 1) to get the last value to put at the root.
I prefer implementing classes that handle generic values, so the MaxHeap takes a T
However, the type given here has to be a Comparable so that > and < work. So that's the only limitation on the generic value.

Functions:

Insert

Insert, always bubbles up

Memory Helper: "inserting is positive, going up is positive, they go together"

Extract

Extract, you'd need to bubble down The root is what you extract, which is the largest or smallest value in the heap. The last element in the heap is then put at the root and bubbled down.

Memory Helper:

"The whole point of the heap is to extract the min/max value and then the value you'd put in there is already at the top so you'd have to go down"

Useful property:

Extracting or inserting always takes LogN time, you can the smallest or largest n elements by calling its extract over and over.

Fun facts:

The book uses 1 indexed arrays and Vaidehi uses 0 indexed arrays, this changes their equations for child nodes.

Code + Test

The Simplest Recycler EmptyView

Aniket Kadam — Wed, 05 Aug 2020 08:24:41 +0000

A recyclerview with something to show when it's empty is a pretty common pattern, many times we're tempted to do this in code.

We're going to look at a better way to do than:
Checking if the number of items in the adapter is zero and then show the empty view else, show the recyclerview.

Here's the code, and it's all XML

No code required. This will show the recyclerview when items are present, and the progressbar in the center when it's not.

How does it work?

A few key points

The layout is a vertically oriented LinearLayout with only two items, the recyclerview and the container for the progressbar.
The progressbar is the second item in this list.
Recyclerview's widths and heights are always calculated from their children. If there are no children, it sets itself to zero. When there are children, it actually follows the rest of the rules given to it like match_parent

If you look into the source code of the RecyclerView you'd see this line in onMeasure, which is what defines the dimens of the view.

mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec);

So that's it! You can now get a clean empty view that naturally gets shoved under the recyclerview when there are items and you didn't one bit of Java/Kotlin code to do it yourself!

Dagger with a Hilt

Aniket Kadam — Fri, 24 Jul 2020 10:30:55 +0000

AndroidEntryPoint is now quite a bit better and in general availability so we can now move to this method!

This lets us specify the bare minimum to have a functional Dagger setup, with few drawbacks and get going really quickly with the code we care about.

Looking to rapidly bootstrap a new app with Dagger and Hilt?
Here are some steps to how it might practically be used. You could go in order to jump to the section you'd like.

Setup
Create an Application class
Let's get a ViewModel, but first..
Creating a Retrofit Provider
Creating an API interface for the actual call
Creating concrete instances of the API
Creating a Repository
Finally the ViewModel
Wrapping it up in the Activity

Basic Setup

Add classpath "com.google.dagger:hilt-android-gradle-plugin:2.28-alpha" to your project level build.gradle (the one at your project root)
Add apply plugin: 'dagger.hilt.android.plugin' to the top of your app level build.gradle
Ensure you have apply plugin: 'kotlin-kapt' in your app level build.gradle as well
Import the following at the app level build.gradle:

implementation "com.google.dagger:hilt-android:2.28-alpha" kapt"com.google.dagger:hilt-android-compiler:2.28-alpha"

Once you've gotten your setup ready, here's what you do.

Create an Application class

Then annotate it with @HiltAndroidApp

@HiltAndroidApp
class DemoApplication : Application()

Don't forget to add the classname of your application to the Manifest!

    <application
        android:name=".DemoApplication"
        android:allowBackup="true"

Let's get a ViewModel, but first..

Since it's only going to be useful with a repo and some Api passed in:

We're going to be using the standard separation of concerns which means we're going to need three classes

The provider for the Retrofit instance
The API interface for the network call to be made by retrofit
The repository which will take in an instance of the created API and be responsible for exposing it to the ViewModel

We're going to create them in that order only because the app wouldn't compile in an intermediate state otherwise.

Creating a Retrofit Provider

I'll get to what @ApplicationComponent is and why the module is an object along with why this particular provider is marked @Singleton right after showing you code for this module.

import dagger.Module
import dagger.Provides
import dagger.hilt.InstallIn
import dagger.hilt.android.components.ApplicationComponent
import io.reactivex.schedulers.Schedulers
import okhttp3.OkHttpClient
import retrofit2.Retrofit
import retrofit2.adapter.rxjava2.RxJava2CallAdapterFactory
import javax.inject.Singleton

@InstallIn(ApplicationComponent::class)
@Module
object RetrofitModule {

    @Singleton
    @Provides
    fun getRetrofit(client: OkHttpClient) : Retrofit = Retrofit.Builder().baseUrl("https://something.com")
        .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
        .client(client)
        .build()

    @Provides
    fun getClient() : OkHttpClient = OkHttpClient()
}

Since we only ever want one instance of Retrofit (to improve connection pooling) this is a Singleton provider.
It might feel odd having a default okhttp client provided but this is often modified with interceptors.

This is installed in the Application component since we want the retrofit instance to not only be unique for the entire app, but also at the highest level in the dependency graph so it's available to all other modules.

This follows the standard practise of Modules being Singletons (via the object notation) for faster runtime performance.

Note: Since Dagger 2.25, we no longer need to annotate the functions JvmStatic.

Creating an API interface for the actual call

import io.reactivex.Observable
import retrofit2.http.GET

interface SomethingApi {
    @GET("widgets/")
    fun getWidgets(): Observable<String>
}

The pretend API has an endpoint called widgets and we're going to get ourselves some widgets!

Creating concrete instances of the API

Since it requires retrofit to create concrete instances of the API, we're going to need a module that will manage that.

import dagger.Module
import dagger.Provides
import dagger.hilt.InstallIn
import dagger.hilt.android.components.ActivityRetainedComponent
import retrofit2.Retrofit

@InstallIn(ActivityRetainedComponent::class)
@Module
object ApiModule {

    @Provides
    fun getSomethingApi(retrofit: Retrofit): SomethingApi =
        retrofit.create(SomethingApi::class.java)
}

Note that is in an ActivityRetainedComponent since it's intended to be used by a ViewModel that will itself be preserved on activity rotation. The only difference between the ActivityRetainedComponent and the ActivityComponent is that the provided object in the first scope is 'retained' or kept, through configuration changes. See here

Creating a Repository

This repo will abstract away the network and DB api's for the ViewModel


import io.reactivex.Observable
import javax.inject.Inject

class MainRepo @Inject constructor(private val somethingApi: SomethingApi) {
    fun getWidgets() : Observable<String> = somethingApi.getWidgets()
}

Finally the ViewModel

ViewModel Factories no longer need to be created since the Hilt compiler will do that bit of code generation.

You'll need implementation "androidx.hilt:hilt-lifecycle-viewmodel:1.0.0-alpha01" for the @ViewModelInject annotation.

Also kapt "androidx.hilt:hilt-compiler:1.0.0-alpha01" for the hilt compiler that will actually generate the ViewModel factories for you.

import androidx.hilt.lifecycle.ViewModelInject
import androidx.lifecycle.ViewModel

class MainViewModel @ViewModelInject constructor(
    private val mainRepo: MainRepo
) : ViewModel() {

}

Wrapping it up in the Activity

Now we're ready to use this ViewModel in the Activity and it's done with:

import android.os.Bundle
import androidx.activity.viewModels
import androidx.appcompat.app.AppCompatActivity
import dagger.hilt.android.AndroidEntryPoint

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    private val mainViewModel: MainViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

To get the viewModels delegate, you'll need to add the activity or fragment kotlin extension libraries depending on where you want to use it.
That's implementation "androidx.activity:activity-ktx:1.2.0-alpha06" or
implementation "androidx.fragment:fragment-ktx:1.3.0-alpha06"

That's it!
You're ready to use dependency injected viewmodels!

If you wanted to use this with fragments and want to share the activity's viewmodel with them, use activityViewModels instead of viewmodels in them.

Check back in later to see how to use this with navigation components and with testing.

Looking to get your devs up to speed on the latest techniques to boost productivity and your time to market? Reach out to me for consulting at consulting@aniketkadam.com

Intro to Testing: Why Test

Aniket Kadam — Thu, 09 Jul 2020 14:15:52 +0000

When you write a feature, how do you know it works?
A lot of people, will run their code, and if you're an Android dev, you see it running on the phone and now you know if it works.

For Android in particular, this takes quite a while to do.
Have you ever sat down, and timed how long it takes from the time you write some function and hit run, to the time it actually starts up on a phone?
How many times do you do that procedure when writing code? How many times a day do you do it? Sure instant run might help a lot of times, but what if the thing you're checking requires you to go a bit deeper into the app? Each trial run could easily take 5 minutes and then if you just tried something 6 times, you've spent half an hour of your day on it.

What if you could save all that time?

Testing has become associated with something complex but nothing could be further from the truth. Yes, you will be learning new techniques and learning to think a bit differently but the end result is that your work will be easier!

You're going to spend less time, to get more things done and you'll be more confident that things are working the way they should.

We all test our code, the only difference is whether it takes milliseconds or minutes.

I use testing for two reasons:

Faster development.
A measure of confidence in its correctness.

We'll take a look at how to do this next time in this series, alongside when to do it, what to test, what not to test, mental models and benefits you get from it.

Meanwhile, take a look at one of the central concepts in testing that I wrote about here

If your team could use some help, or would like getting things more often and faster with less time; I consult on Android. Reach out to me at consulting@aniketkadam.com

Android Sorting CheatSheet

Aniket Kadam — Wed, 13 May 2020 10:44:54 +0000

For Kotlin

If there's just one value to compare, then the following can be used

    names.sortedBy{ it.length }

The two methods are used to compare the items in the list. If the first one returns equal, then the second will take over

fun arrangeNames(names: List<String>): List<String> {
    names.sortedWith(compareBy({it.length}, {it.length}))
}

For Java

When using java, a comparator object has to be created, these can be chained with thenBy calls.
A stream still needs to be created and collected for the result to be calculated.

public List<String> arrangeNames(List<String> names) {
    Comparator<String> sizeComparator = Comparator.comparing(String::length).thenBy(String::length)
    return names.stream().sorted(sizeComparator).collect()
}

Effective Git, zero to max in small steps: First Steps

Aniket Kadam — Tue, 28 Apr 2020 08:17:49 +0000

Git probably has the highest ratio of misunderstanding/usage ratios of any software tool. It's also one with a tremendous variety of valid usages that look very little like each other.

I'm going to walk through some of its strengths and one good thing to use it for.

Ostensibly, git is a tool to:

Keep track of changes to a codebase
Synchronize, and provide tools to synchronize, changes to the same file that may sometimes conflict.

If you're using git for open source work, you need to consider that the credentials you add to it are public too so you need some extra strategies to deal with that.

Tools and Intro

If you'd like a GUI, I'd recommend whatever's built into your code editor. vcode and Android Studio both have quite decent git clients.

For an advanced usage like selective stage ( partially committing changes in one file ) I very highly recommend git-cola.

Knowledge of the commandline is very useful if you've totally broken something ( which happens on an uncommon but not rare basis ), and to better understand some cryptic errors you might get from the GUIs sometimes.

As far as possible, I'll try to remain tool agnostic and use only git terms, but also tell you things in terms of the commandline.

Note: Since git depends on a local database in the .git folder, changes made from any tool are generally visible in any other tool ( except Android Studio's stages ). So feel free to mix and match as you like.

Concepts

For the barest use of git, you only need to know two commands.
stage

and

commit

A commit is a group of 'changes' that you save at once into git. There's a reason I said changes and not files but we'll get to that later. You can think of a change as one line of text that's been added or deleted.\

Since we can add multiple changes at once, to tell git what changes we want to group together, we stage them.
Staging tells git that this version of the change is something you're adding to a list that you might want to save or commit together.

If you try to commit without stage, git will do nothing. Since the list of changes that you wanted to save or commit is empty.

So let's say you create a new folder and open a terminal inside it.
You initialize git in that folder, to track changes in that folder, with the command
git init

Now, let's say you create a text file in there called Readme.txt, you can see how git sees it with
git status

Now that you can see that git knows a new file is in there, you can save it into git with
git add Readme.txt

Another thing you could do, is stage all the files in the folder with
git add .
Notice the dot at the end, this tells git to add whatever files it sees in this folder

Once you've got the files staged, you can commit!

The barest command (which you should never run actually) you need for this is
git commit and you'll see that it's done.

Why shouldn't we just commit (save changes) like this? Because no one would know what changed in with this set of changes.

A high-level description message should always be provided with every commit that says why it changed along with an overview of what.
So a good description message could be "Added readme"

Here's what the commit command looks like when you add a message that explains the change as well.
git commit -m "Added readme"

That's it for this intro!
Next time, we'll look into branching and merging. What those are and why you might do them.

Tips to Writing Tech Talks/Blog posts

Aniket Kadam — Sun, 09 Feb 2020 15:26:50 +0000

Should You Do a Talk?

Yes.

An unreserved, no-background-needed, yes. Writing and Speaking is how you show to other people not only that you know your stuff but that you can communicate it effectively.

These are vital skills not only for your work, but to help you in your next job search as well.

I guarantee that what you know and the mental model you have for what you know, is going to help someone. So please write it even if it's been written about before.

It's about writing/speaking about it in your own voice.

Stagefright

You can stare straight at the back of the room and pretend you're giving a talk to a large empty room, bonus, it looks like you're confidently looking right at the crowd! If you're nervous, stack the front row or middle with your friends whose job is to nod and smile and thumb's up and you're going to look right at them as you give your talk.

Another technique which I picked up later is best explained via a quote from the movie Bohemian Rhapsody, about the lead singer of a band called Queen.

Mary Austin: What's it like, singing for all those people?
Freddie Mercury: When I know they're listening, when I know I really have them, I couldn't sing off-key if I tried. I am exactly the person I was always meant to be. I'm not afraid of anything

The audience is your friend. They want you to do well. You're chatting to them about something that was fun enough for you want to tell other about it and they're eager to hear it. You're all going to love this :)

What to do a talk about?

Whatever you do in your daily work! Have you:

Come up with a nice solution for something?
Gotten through a painful setup of a library or a dev environment?
Learned something that was difficult for you and now have an insight that can explain it in a simpler way?

All these ideas are what you know really well and have spent some time on. You could save somebody else that same time by doing a talk/blog post on it!

Create a Talk Outline

Whatever you want to talk about, what would be the broad headings of how you'd explain it to someone?

If you consider a book on the topic, what would be the chapter headings? Write these down.

Once you've got your chapter points, you can look at them overall and get an idea of how the talk would go and how you'd like to present it.

Keep adding bullet points, like sub-chapters about the ideas you want to discuss within the main chapter. These may eventually be a slide each, or just points on one slide for the chapter!

It's a good idea to give people a reason to care, tell them about the biggest benefits of your ideas in the first 2 minutes of the talk.

Don't talk about setup unless that was the hard part for you, you can link people to the setup and that's usually enough.

Making your slides.

Don't have a huge amount of text on your slide. The less you have, the better. Nobody can read and follow what you're saying at the same time.

At most, do bullet points. If you do have bullet points, animate them in when you reach them, don't display them all at once. Most slide making software have something for this including Google Slides which is what I use.

Code

If you have code, only include the section relevant to the concept you're trying to explain.

You can add a github link for the full detail and don't overwhelm the people with large classes or waay too many functions.

A good rule of thumb is, if it's too much code to comfortably read as a slide from across the room you're sitting in, it's too much code for a slide.

Write your code in Android Studio, use Roman Nurik's Slides Code Highlighter to give you the syntax colouring in Google Slides.

Another way to do this is with Carbon which will give you pngs or svgs of your code but when you make the inevitable mistakes, you can't edit that image!

That's why I prefer getting the colour formatted text and running it through the slides code highlighter.

Finding Places to Speak

I'd always suggest looking into your local meetups. You can usually find these on meetup.com or asking about it on twitter or asking your other colleagues what they know about.

The huge famous meetups you can always find on google.

Applying To CFPs (call for papers)

Ideally you should do this before you've even written your talk. Most abstract applications will end in rejection. Get used to rejection, it's also really good for you.

By writing short abstracts, an enticing paragraph about what your talk could be about and what people could expect to learn from it, you'll minimize the time you take to apply to conferences and increase your chances of being accepted at one.

You can absolutely write a talk about anything you've done, I always feel like there's not enough there to fill a 40 minute slot and then when I sit to make the slides I realise there's waaaay too much to cover in just one talk!

And if the idea is rejected and you really want to do it anyway, consider making it a blog post!

Backups

I use Google Slides and the Slides Offline Chrome Extension so that I have the slides available even if the internet is spotty.

I also create a public sharing link and put it into bit.ly with a nice readable name and keep that as a Whatsapp Message or emailed to someone so that I can refer to that in case you can't use your machine at all for whatever reason.

Handling The Audience

It's always best if you can involve the audience somehow. Whether that's making them laugh, or guiding them so that they can get an intuitive feel for what's next and asking if they can fill-in-the-blanks or asking for their own experience of things. The more you give the audience a chance to speak, the more they'll connect to you.

Advanced Ideas

Once you've given a few talks and are familiar with the idea. Be aware that this isn't a college lecture or a dull presentation.

Speaking is a performance. You're an actor on a stage and your job is hold the attention of these people and give them something to remember. How you achieve that is usually by amping up either your natural personality or whatever you find entertaining to see.

Good luck!

Speaking is what Donn Felker calls "The Single Best Thing You Can Do For Your Career" and I'm very inclined to agree.

Good luck, you can do this and you're going to get better with practise.