Prog24 Engineering Notes

Animating Android UI with a Background Thread

When you build interactive Android screens, it's tempting to put a bit of logic directly on the main thread: some loop, a bit of sleep, and a moving element. But the UI thread is fragile – if you block it, the app stutters or even freezes.

A simple pattern that still works great today is: run your long-running or repetitive work in a background Thread , and use runOnUiThread only for UI updates. It keeps animations smooth and the main thread responsive.

Quick Breakdown

• create a dedicated Thread for the animation loop
• do the timing and calculations off the UI thread
• use runOnUiThread only to update view properties
• small, consistent sleep → consistent frame rate

Compact Example: Moving a View Smoothly

                        
                            Thread mover = new Thread(() -> {
    try {
        while (true) {
            runOnUiUiThread(() -> {
                ViewGroup.MarginLayoutParams params =
                        (ViewGroup.MarginLayoutParams) tri.getLayoutParams();
                params.leftMargin += shiftPx;   // move a bit to the right
                tri.setLayoutParams(params);
            });

            // 25 frames per second
            Thread.sleep(40);
        }
    } catch (InterruptedException ignored) {
    }
});

mover.start();
                        
                    

The important part: the heavy loop and timing are in the background thread. The UI work is just a small update inside runOnUiThread , which keeps the animation smooth instead of blocking the main thread.

Cleaning Up Status Code Mapping with PHP 8.2 match

Mapping status codes to human-friendly messages is one of those tiny tasks that appears in almost every backend. Many codebases still use long chains of if / elseif blocks for this. It works, but it’s verbose and easy to break.

PHP 8.2 offers a much cleaner alternative: the match expression. It’s concise, type-safe, and makes intent obvious in one glance.

Classic if / elseif Approach

                        
                            <?php

$statusCode = 404;

if ($statusCode === 200 || $statusCode === 201) {
    $message = 'OK';
} elseif ($statusCode === 400) {
    $message = 'Bad request';
} elseif ($statusCode === 401 || $statusCode === 403) {
    $message = 'Not allowed';
} elseif ($statusCode === 404) {
    $message = 'Not found';
} else {
    $message = 'Unknown error';
}

echo $message; // Not found
                        
                    

This quickly becomes hard to maintain as more status codes are introduced. The branching logic grows and scanning it takes mental effort.

Cleaner Version with match

                        
                            <?php

$statusCode = 404;

$message = match ($statusCode) {
    200, 201 => 'OK',
    400      => 'Bad request',
    401, 403 => 'Not allowed',
    404      => 'Not found',
    default  => 'Unknown error',
};

echo $message; // Not found
                        
                    

Why match Is Often Better

• expression-based → returns a value directly
• exhaustive by design → encourages a default branch
• clear mapping → data-like structure instead of control clutter
• safer comparisons → strict comparison, less surprising than loose equality

For HTTP status codes, enums, or internal state mapping, match gives you a more “table-like” representation of logic. That makes refactoring and reviewing significantly easier.

Improving DOM Performance in JavaScript with DocumentFragment

When dynamically generating tables or lists in JavaScript, it’s tempting to append each row one by one directly into the DOM. It’s easy to write, but the browser isn’t a fan – every append can trigger layout work.

A simple optimisation is to build your DOM nodes inside a DocumentFragment first, then attach the finished structure in one go. It’s a small change that can have a big performance impact, especially on large tables or data-heavy dashboards.

Why Direct DOM Updates Can Be Slow

• each append can cause reflow and repaint
• large loops = many layout recalculations
• UI stutter on slower devices or large data sets

Appending 10 000 rows directly to a table means 10 000 opportunities for the browser to recalculate layout. With DocumentFragment , the browser does all the layout work once at the end.

Direct DOM Append (Simple, but Slower)

                        
                            const tableBody = document.querySelector('#contacts-table tbody');

for (let i = 0; i < 10000; i++) {
  const tr = document.createElement('tr');

  for (let j = 0; j < 10; j++) {
    const td = document.createElement('td');
    td.textContent = `Row ${i} — Cell ${j}`;
    tr.appendChild(td);
  }

  // Direct DOM update on each iteration
  tableBody.appendChild(tr);
}
                        
                    

Using DocumentFragment (Batched, Much Faster)

                        
                            const tableBody = document.querySelector('#contacts-table tbody');
const fragment = document.createDocumentFragment();

console.time('Fast fragment insert time');

for (let i = 0; i < 10000; i++) {
  const tr = document.createElement('tr');

  for (let j = 0; j < 10; j++) {
    const td = document.createElement('td');
    td.textContent = `Row ${i} — Cell ${j}`;
    tr.appendChild(td);
  }

  fragment.appendChild(tr);
}

// One single DOM update
tableBody.appendChild(fragment);

console.timeEnd('Fast fragment insert time');
                        
                    

When to Reach for DocumentFragment

• rendering big tables or lists from API data
• generating dashboards with many repeated components
• importing and displaying bulk records
• anywhere a loop creates many DOM nodes

Modern frameworks like Vue and React optimise DOM updates internally through virtual DOM. If you’re working with vanilla JavaScript or TypeScript, DocumentFragment is a simple way to bring similar batching behaviour into your own code.

Why I Use Conventional Commits

Commit messages are tiny, but they shape the long-term readability of any repository. A vague history full of “update stuff” and “fixes” is painful to understand – and almost impossible to automate.

Conventional Commits is a lightweight standard that adds a simple structure on top of the messages you already write. It makes your Git log cleaner, easier to scan, and much more useful for tools that generate changelogs, releases or dashboards.

Quick Breakdown

• predictable structure → faster history scanning
• type prefixes communicate intent at a glance
• ideal for automation (changelog, release notes, tooling)
• encourages smaller, focused commits
• works with any tech stack or repository

Compact Examples (with Micro-Meanings)

                        
                            feat: add password reset API                // new feature
fix: handle empty body in login request     // bug fix
refactor: extract validation rules into helper   // code cleanup
docs: improve installation steps            // documentation
perf: optimize product listing query        // performance improvement
test: add missing unit tests                // test coverage
chore: update dependencies                  // maintenance
                        
                    

The pattern is intentionally simple:

                        <type>: <short, imperative description>
                    

With an optional scope when you want to be more specific:

                        feat(auth): add refresh token support
                    

Why This Matters for Teams

• you can filter history by type (only feat, only fix, etc.)
• release notes can be generated automatically from commit types
• code reviews become easier, because intent is clear even before opening the diff
• new team members understand the repository’s evolution faster