The problem

You working remotely and you and the target device are too far away. Or you work on a remote server and want to debug your app on your phone.

The solution

1. Connect phone to the one machine with adb, let’s call it “machine A
2. On the machine A, run adb kill-server and adb start-server
3. On the machine A, run ssh -R 5555:localhost:5555 machineB
4. On the remote machine, where you want to debug, run adb devices to check that the phone is connected

The problem

Discord on Linux doesn’t have the option by defaul to play audio from you apps simultaneously with your microphone.

The solution

What we do is to create two virtual sinks, one for microphone and another for music.

pactl load-module module-null-sink sink_name=MicSink sink_properties=device.description=MicSink
pactl load-module module-null-sink sink_name=MusicSink sink_properties=device.description=MusicSink

Thats just two empty devices, let’s bring them to life. We want to play music in our output device (in my case it is called “TU106”)

pactl load-module module-loopback source="MusicSink.monitor" sink="TU106"

And we also want to send the same audio to the microphone sink, as it will go to Discord.

pactl load-module module-loopback source="MusicSink.monitor" sink="MicSink"

The final step is to send your physical microphone to the virtual microphone sink. (in my case mic called “NoiseTorch Mic…”)

pactl load-module module-loopback source="NoiseTorch Microphone for THRONMAX PULSE MICROPHONE" sink=MicSink

The final setup

Now, go to pulseaudio pavucontrol and in Playback select “MusicSink” for your music player, and in Recording select “MicSink” for Discord. One of the “loopback-…” devices must play in your physical output device, others go to MicSink.

Sometimes in everyday Android development, you encounter strange, if not mystical bugs. (standard introduction)

In the previous episode Databinding Episode I; Hidden Danger

Let’s assume there is a *.kt class:

Base.kt
open class Base {
  open fun isEmpty() = false
}

and its *.java inheritor:

Child.java
class Child extends Base {
  public boolean isEmpty = true;
}

Here we can already notice that we have shot ourselves in the foot. But let’s continue.

We wanted to use the Child class in databinding.

Attention, question: will the following View be visible?

some.xml
<layout>
<data>
  <variable name="child" type="Child" />
</data>

<View
  ...
  android:visibility="@{child.isEmpty ? View.VISIBLE : View.GONE}"
  ...

Moral of the Story

1. Do not inherit Java classes from Kotlin classes.
2. Maybe it’s time to switch to Jetpack Compose?

First step - we buy this chunky guy Update: on their site, only the full version with internals THICC-15 is left

What is it: an empty laptop without a processor, RAM, hard drive.

Why choose it?

Firstly, without these components, the duty will be less. Secondly, it’s the only one of its kind (apart from its twins, like Xmg Apex-15) laptop supporting a desktop Ryzen 9.

While the package is on its way, we quickly buy ourselves a Ryzen 3950x (because an Android project is serious business)

Ordered, received, unpacked, happy?

Unfortunately, it’s slightly too noisy even without heavy load. 16 cores after all.

Thinking about what to do with it.

Finishing

Literally. We take a jigsaw, remove the cover and carefully cut out the middle of it. O_O

No turning back now :)

Now we need a mesh. We cut it out of an old laptop stand.

Glue the mesh to the frame of the cover with epoxy resin and super glue.

Almost ready.

We buy small copper plates for cooling separately. Height ~3.5 mm.

We will attach them on top of the cooling system, so we need to remove the labels-handles from it and clean the surface.

Copper wire and heat-resistant rubber rings will be suitable for attachment.

Don’t forget to apply thermal paste, as the surface is uneven.

All done, ready to assemble.

Why Such Power?

The laptop is suitable as a portable desktop computer. It’s convenient when your entire environment is always with you in full power.

Recording of this talk - Experiment with Kotlin Mobile Mutliplatform

• repository https://github.com/samoylenkodmitry/KMMSimple
• threading - on iOS there are no coroutines, you need to invent an adapter
• iOS shared file is too large - 2MB minimum,

+9 MB for ktor,

+2MB for Kotlin serialization

Comparison of the final app size for iOS vs Android:

Pros:

• shared code
• for Android, there is no difference, you can write for multiplatform “just in case”

Challenges:

• need to maintain the library, both platforms will use it
• cannot break the compatibility of the library
• set up CI/CD
• unit tests
• all iOS developers need to install gradle, java, set up the environment
• problem with the large size of the shared file on iOS
• Android developer will need a Mac

Predictions:

• a new type of job on the market - a multiplatform programmer
• competition among native programmers will be higher, harder to find a job
• there will be a future simply because it is profitable for business (unless Apple interferes)

Experience of others:

A good talk-interview on the topic: Chasing two rabbits: is it necessary to be able to develop for Android and iOS Alexey Gladkov. Technical architect at Leroy Merlin

Current actively developed lints are Detekt and ktlint. klint have a don't overengineer philosophy while detekt is more configurable.

How to set up Detekt?

https://github.com/detekt/detekt

Download binary from here https://github.com/detekt/detekt/releases Config file can be auto generated from command line or simple download mine default-detekt-config.yml

How to set up ktlint?

https://github.com/pinterest/ktlint Download binary from here https://github.com/pinterest/ktlint/releases Ktlint can be configured with standard .editorconfig file. You can find one anywhere in github or get mine: .editorconfig

How to make it check each commit?

Copy and configure script from here: pre-commit

#!/bin/bash
# Setting up guide http://dmitrysamoylenko.com/2020/12/06/configure_lints.html
# https://github.com/checkstyle/checkstyle
# https://github.com/pinterest/ktlint
# https://github.com/detekt/detekt

# Determine the Java command to use to start the JVM.
if [ -n "$JAVA_HOME" ]; then
  if [ -x "$JAVA_HOME/jre/sh/java" ]; then
    # IBM's JDK on AIX uses strange locations for the executables
    JAVACMD="$JAVA_HOME/jre/sh/java"
  else
    JAVACMD="$JAVA_HOME/bin/java"
  fi
  if [ ! -x "$JAVACMD" ]; then
    die "ERROR: JAVA_HOME is set to an invalid directory: $JAVA_HOME

Please set the JAVA_HOME variable in your environment to match the
location of your Java installation."
  fi
else
  JAVACMD="java"
  which java >/dev/null 2>&1 || die "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.

Please set the JAVA_HOME variable in your environment to match the
location of your Java installation."
fi

GIT_ROOT_DIR=$(git rev-parse --show-toplevel)

cd ${GIT_ROOT_DIR}
#echo ${GIT_ROOT_DIR}
f=()
while read line; do
  if [ -n "$line" ]; then
    if [[ "$line" =~ .*"/build/".* ]]; then
      true #skip generated code
    else
      f+=("$line")
    fi
  fi
done <<<"$(git diff --diff-filter=d --staged --name-only)"

filesJava=""
filesKt=""
countJava=0
countKt=0
for i in "${!f[@]}"; do
  if [[ "${f[i]}" == *.java ]]; then
    filesJava+=" ${f[i]}"
    countJava=$((countJava + 1))
  fi
  if [[ "${f[i]}" == *.kt ]]; then
    filesKt+=" ${f[i]}"
    countKt=$((countKt + 1))
  fi
done

for i in "${!f[@]}"; do
  if [[ "${f[i]}" =~ .*.(java|kt)$ ]]; then
    lineNum=0
    while IFS= read line; do
      if [ -n "$line" ]; then
        lineNum=$((lineNum+1))
        if [[ "$line" =~ ^\ +[^\*].* ]]; then
          echo "Line starts with spaces. Please apply project code style. File: ${f[i]}:$lineNum, line: $line"
          exit 1
        elif [[ "$line" =~ .*oleg.*|.*xoxoxo.* ]]; then
          echo "forbidden word in line. File: ${f[i]}:$lineNum, line: $line"
          exit 1
        else
          true #skip good code
        fi
      fi
    done < "${f[i]}"
  fi
done

if [ ${#filesJava} -eq 0 ]; then
  echo "No *.java files to check."
else
  configloc=-Dconfig_loc=${GIT_ROOT_DIR}/ivi/config/checkstyle
  config=${GIT_ROOT_DIR}/ivi/config/checkstyle/checkstyle.xml
  params="${configloc} -jar ${GIT_ROOT_DIR}/githooks/checkstyle-8.38-all.jar -c ${config}${filesJava}"

  ${JAVACMD} $params
  result=$?
  if [ $result -ne 0 ]; then
    echo "Please fix the checkstyle problems before submit the commit!"
    exit $result
  else
    echo "#java files: $countJava"
  fi
fi

if [ ${#filesKt} -eq 0 ]; then
  echo "No *.kt files to check."
  exit 0
fi

# ktlint check
git diff --diff-filter=d --staged --name-only | grep '\.kt[s"]\?$' | xargs ./ktlint .
result=$?
if [ $result -ne 0 ]; then
  echo "Please fix the ktlint problems before submit the commit!"
  exit $result
fi

#detekt check

check_by_detekt() {
  arg=$1
  files=${arg%?}
  if [ ${#files} -eq 0 ]; then
    true #skip
  else
    params="--fail-fast --config default-detekt-config.yml --input ${files}"
    ./detekt ${params}
    result=$?
    if [ $result -ne 0 ]; then
      echo "Please fix the detekt problems before submit the commit!"
      exit $result
    fi
  fi
}
count=0
filesd=""
for i in "${!f[@]}"; do
  if [[ "${f[i]}" == *.kt ]]; then
    filesd+="${f[i]},"
    count=$((count + 1))
    # split into batches
    if [ $count -gt 1000 ]; then
      check_by_detekt $filesd
      count=0
      filesd=""
    fi
  fi
done

check_by_detekt $filesd
echo "# kt files: $count"
exit 0

How to make it work for all team members?

Make folder githooks/ in the root git project directory and put all downloaded files into it. Then in top of the project build.gradle insert:

exec {
	executable './../enable_lints.sh'
}

This will execute the script enable_lints.sh that will apply git path to the githooks/ directory and make git execute the script pre-commit before each commit. Contents of the script:

enable_lints.sh

#!/bin/bash
git config --global core.hooksPath githooks

Remember to make each script executable

chmod +x ./ktlint
chmod +x ./detekt
chmod +x ./githooks/pre-commit

Now add the githook/ directory and all new files to git and push it to server. All team should just open project again so AndroidStudio will run build.gradle script. Notice that script support only unix os and should be specially edited to support windows.

Those two collections are all sorted and very useful when you need to maintain some order in dynamically filled data. However, when concurrency takes place there is a gotcha. We have a choice: use manual synchronization or use ConcurrentSkipListSet from java.concurrent package.

My case

I have a task that gets episodes from a server in a bulk operation. For example, when there is an 800 episodes total it makes 8 asynchronous requests 100 episodes each. Resulting list of episodes needs to be sorted and displayed on the client side.

Code for manual synchronizations looks like this:

final Set<Video> allEpisodes = new TreeSet<>(sortByEpisode);

final Video[] sortedEpisodes;

synchronized (allEpisodes) {
	Collections.addAll(allEpisodes, notFakeVideos);
	sortedEpisodes = allEpisodes.toArray(Video.EMPTY_ARRAY);
}
//use of sortedEpisodes

which is somewhat verbose.

In the opposite, code with concurrent collection looks very clean.:

final Set<Video> allEpisodes = new ConcurrentSkipListSet<>(sortByEpisode);

Collections.addAll(allEpisodes, notFakeVideos);

final Video[] sortedEpisodes = allEpisodes.toArray(Video.EMPTY_ARRAY);

Almost none of the concurrent stuff is visible to the programmer which is a good thing for maintainability and error-proneness.

Benchmark?

I’m tested two solutions using Android emulator API 30. Here are results:

For my use case manual synchronization is almost twice as fast as using concurrent collection.

But which is better?

Winner: TreeSet+synchronized! However, in broad case the answer is: “It depends”. My case consist of only 10 invocations of adding elements and one toArray() call. It is a tiny number of concurrent events. That’s why concurrent collection overhead makes a visible difference for performance.

I should say upfront that this article is not intended to nitpick this library, as I personally find it quite appealing. First, we’ll create a simple list to add views to. This is an inefficient method, but it will illustrate the overall picture of how much attention was paid to performance in the new framework. So, let’s compare the old method:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val N = 100_000
        setContentView(
            ScrollView(this).apply {
                addView(
                    LinearLayout(context).apply {
                        orientation = LinearLayout.VERTICAL
                        repeat(N) {
                            addView(
                                TextView(context)
                                    .apply { text = "hello $it" })
                        }
                    })
            })
    }
}

And the new method:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val N = 100_000
        setContent {
            MyApplicationTheme {
                Surface(color = MaterialTheme.colors.background) {
                    ScrollableColumn {
                        repeat(N) {
                            Text(text = "Hello $it")
                        }
                    }
                }
            }
        }
    }
}

This is a simple scrolling list, where N text views are arranged vertically.

We measure performance using Android Studio’s Profiler tab after the heap growth stabilizes.

1. N = 1 Heap size for View - 1.5M vs Compose - 2.7M This is the basic difference with just one view. Twice as much, but not critical for modern devices.

2. N = 40,000 View 723M vs Compose 26778M You can see how memory usage significantly increases depending on the number of elements in compose.

3. N = 60,000 here the emulator ran out of heap space of 512 MB (with allocated RAM=30GB) and compose crashed with OutOfMemoryError

4. N = 100,000 continue testing View - 1807M. There’s a huge potential for growth in the number of elements present at the same time.

Let’s plot the memory growth against the number of elements. Memory usage for View grows linearly, which is not the case for Compose.

The Real Power of Jetpack Compose

It takes just 3 lines to create a lazy list like RecyclerView

LazyColumnFor(items = (1..1_000_000).toList()) {
  Text(text="Hello $it")
}

For comparison, achieving the same result using RecyclerView:

RecyclerView(this).apply {
  adapter = object : RecyclerView.Adapter<RecyclerView.ViewHolder>() {
     override fun onCreateViewHolder(parent: ViewGroup, viewType: Int) =
        object : RecyclerView.ViewHolder(TextView(context)) {}

     override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
        (holder.itemView as TextView).text = "hello $position"
     }

     override fun getItemCount() = N

  }
  layoutManager = LinearLayoutManager(context)
}

Let’s take a closer look at the Lazy list. It’s interesting to see how often it redraws elements. Let’s draw multicolored circles using Canvas:

LazyColumnFor(items = (1..N).toList()) {
  Text(text = "Hello $it")
  Canvas(modifier = Modifier.size(10.dp), onDraw = {
     this.drawOval(
        color = Color(
           Math.random().toFloat(),
           Math.random().toFloat(),
           Math.random().toFloat()
        ), size = this.size.times(3.0f)
     )
  })
}

As we can see, Canvas() redraws every tick

However, Text() redraws only when it leaves the visible area:

This is encouraging: they are thinking about component redraw optimizations in advance.

Also, the LazyColumnFor(items) function interface does not yet allow creating a truly infinite list. A finite set of items is always expected.

tl;dr

Jetpack Compose is still in alpha version and it’s evident that priority is given to API conciseness. Let’s hope that Google doesn’t stop at the first iteration and optimizes the components.

After all, it’s their own slogan - #pert_matters, which they gradually seem to forget https://www.youtube.com/playlist?list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE)

It can be found empirically. Set a breakpoint in the Application.onCreate callback and you will discover it at the top of the stack trace, in the class ActivityThread. Here it is, the “familiar” entry point of a JVM application:

    public static void main(String[] args) {
        ...
        Looper.prepareMainLooper();

        ActivityThread thread = new ActivityThread();
        thread.attach(false, startSeq);
        ...

        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

Skipping things irrelevant to our topic, here’s what’s happening:

1. Looper.prepareMainLooper() “prepares” the Looper (creates a thread-local instance of the Looper class)
2. ActivityThread thread =... An instance of ActivityThread is created
3. thread.attach The attach method of ActivityThread is executed (creates an instance of the application and calls the Application.onCreate callback)
4. Looper.loop() The looper starts. From this moment, the looper begins to poll its internal queue and execute tasks from it. All other activity callbacks will end up here.
5. throw new RuntimeException("Main thread loop unexpectedly exited") The last line reveals the essence of the SDK architecture - the application should not reach this line in its lifetime. If we do, the application terminates with an error. Thus, a problem and its solution emerge: if some random Activity or View callback throws an error, the entire application crashes. There’s no way to safeguard against this in advance. In Java, there is a universal global mechanism for catching errors:

		Thread.currentThread().setUncaughtExceptionHandler((t, e) -> ... ); //ловим все ошибки

But the above architecture doesn’t allow this mechanism to be used, as the error will first be thrown in the Looper.loop() call, ending it, and only then it will come out in main() and our set error handler. Once the error is caught by the handler, we are left with the problem of the completed Looper.loop, and therefore an application that no longer responds to system callbacks and clicks.

Solution to the Frozen Application Problem

To get the activity to respond to clicks and callbacks again, just restart the looper:

		Looper.loop();

So, the final solution. In Application.onCreate:

		Thread.currentThread().setUncaughtExceptionHandler((t, e) -> continueSafeLoop(e));

	public static void continueSafeLoop(final Throwable e) {
		Throwable error = e;
		while (true) {
			Assert.fail(error);
			try {
				final Looper looper = Looper.myLooper();
				new Handler(looper).removeCallbacksAndMessages(null);
				final MessageQueue queue = ReflectUtils.readField(looper, "mQueue");
				final Long ptr = ReflectUtils.readField(queue, "mPtr");
				final Boolean quitting = ReflectUtils.readField(queue, "mQuitting");
				if ((ptr == null || ptr != 0) && (quitting == null || !quitting.booleanValue())) {
					Looper.loop();
				} else {
				break; //this is just detecting the end of the looper; done only reflectively
				}
			} catch (final Throwable err) {
				error = err;
			}
		}
	}

Now you can experiment by throwing an error in any of the callbacks and see that the application does not crash and does not freeze. Of course, you will still need to abstract away from direct activity callbacks, as there is a detect call to the super method. And you must ensure sending caught crashes to Firebase/Crashlytics, as there will no longer be crashes in the standard error reports in the Google Play console.

P.S.: It is noteworthy that the class ActivityThread is not a Thread and is not about the Android class Activity, but rather about “activity” in the sense of “a set of actions,” and creates not one activity, but the entire Application. In essence, it acts as a delegate of all system callbacks of the application, responsible for its state transitions. This is also stated in its JavaDoc:

/**
 * This manages the execution of the main thread in an
 * application process, scheduling and executing activities,
 * broadcasts, and other operations on it as the activity
 * manager requests.
 *
 * {@hide}
 */

A bit of an unfortunate name choice, in my opinion :)

By default, there’s a visible refactoring option for this through alt+insert - getter.

The problem is that if a field is already used in many places, just creating a getter is not enough. You also need to replace direct access with this getter everywhere.

Fortunately, JetBrains has thought of this! Press ctrl+shift+A, enter and open the refactor this action.

In the menu, there are many different refactorings. We select encapsulate.

A dialog will open where you select the needed fields, tick the getters/setters, and click refactor.

Done!

As we can see, direct access has been replaced with the getter throughout the code.