LeetCode Solution : Reverse Only Letters in a String in Kotlin

  2:41 PM            No comments

Reversing only the letters in a string while keeping all other characters in their original positions is an interesting problem that tests your ability to manipulate strings. In this post, we'll solve the LeetCode problem "Reverse Only Letters" step by step.



Problem Statement

Given a string s, reverse only the English letters (uppercase and lowercase), keeping non-English letters in their original positions.

Rules:

  1. All non-English letters remain in the same position.
  2. Reverse the order of English letters only.

Examples:

  • Input: "ab-cd"
    Output: "dc-ba"
  • Input: "a-bC-dEf-ghIj"
    Output: "j-Ih-gfE-dCba"
  • Input: "Test1ng-Leet=code-Q!"
    Output: "Qedo1ct-eeLg=ntse-T!"

Constraints:

  • 1≤s.length≤1001 \leq s.length \leq 100
  • ASCII values of characters in s are in the range [33,122][33, 122].
  • s does not contain '\"' or '\\'.

Solution Approach

To solve this problem, follow these steps:

1. Identify English Letters

The key is to focus only on English letters (a-z and A-Z) and ignore all other characters.

2. Reverse Only Letters

Use a two-pointer approach to efficiently reverse the letters:

  • Place one pointer at the start and another at the end of the string.
  • Swap letters when both pointers point to English letters.
  • Skip over non-English letters by advancing or retreating the pointers.

3. Rebuild the String

Keep all non-English characters in their original positions while reversing only the letters.

Implementation in Kotlin

fun reverseOnlyLetters(s: String): String {
    val chars = s.toCharArray()
    var left = 0
    var right = s.length - 1

    while (left < right) {
        // Skip non-letters at the left
        while (left < right && !chars[left].isLetter()) {
            left++
        }
        // Skip non-letters at the right
        while (left < right && !chars[right].isLetter()) {
            right--
        }
        // Swap letters
        val temp = chars[left]
        chars[left] = chars[right]
        chars[right] = temp

        left++
        right--
    }

    return String(chars)
}

Explanation

  1. Convert String to Array: Convert the input string s to a CharArray so we can modify it in place.
  2. Two-Pointer Technique:
    • Start two pointers: left at the beginning and right at the end of the array.
    • Use isLetter() to check if the characters are English letters.
    • If both characters are letters, swap them.
    • Otherwise, move the pointers inward while skipping non-letter characters.
  3. Return the Result: Convert the modified CharArray back to a string and return it.

Dry Run Example

Input: "a-bC-dEf-ghIj"

Step Array State Left Right Action
Init ['a', '-', 'b', 'C', '-', 'd', 'E', 'f', '-', 'g', 'h', 'I', 'j'] 0 12 Start pointers
1 ['j', '-', 'b', 'C', '-', 'd', 'E', 'f', '-', 'g', 'h', 'I', 'a'] 1 11 Swap 'a' and 'j'
2 ['j', '-', 'I', 'C', '-', 'd', 'E', 'f', '-', 'g', 'h', 'b', 'a'] 3 10 Swap 'b' and 'I'
3 ['j', '-', 'I', 'h', '-', 'd', 'E', 'f', '-', 'g', 'C', 'b', 'a'] 4 9 Swap 'C' and 'h'
4 ['j', '-', 'I', 'h', '-', 'g', 'E', 'f', '-', 'd', 'C', 'b', 'a'] 5 8 Swap 'd' and 'g'
Done ['j', '-', 'I', 'h', '-', 'g', 'f', 'E', '-', 'd', 'C', 'b', 'a'] — — Result achieved

Output: "j-Ih-gfE-dCba"

Complexity Analysis

  1. Time Complexity: O(n)O(n), where nn is the length of the string. Each character is processed at most once.
  2. Space Complexity: O(n)O(n) due to the CharArray used for in-place modifications.

Why This Approach?

This solution is efficient and easy to understand. By using the two-pointer technique, we minimize unnecessary operations and handle non-letter characters seamlessly.

Here are a few different ways to solve the problem, each with varying techniques:

1. Using Stack (Explicit Data Structure)

fun reverseOnlyLettersUsingStack(s: String): String {
    val stack = ArrayDeque<Char>()
    for (ch in s) {
        if (ch.isLetter()) stack.push(ch)
    }
    val result = StringBuilder()
    for (ch in s) {
        result.append(if (ch.isLetter()) stack.pop() else ch)
    }
    return result.toString()
}

2. Using Regular Expressions (Regex)

fun reverseOnlyLettersUsingRegex(s: String): String {
    val letters = s.filter { it.isLetter() }.reversed()
    var index = 0
    return buildString {
        for (ch in s) {
            append(if (ch.isLetter()) letters[index++] else ch)
        }
    }
}

3. Using Mutable List and Two-Pointer Swap

fun reverseOnlyLettersUsingMutableList(s: String): String {
    val chars = s.toMutableList()
    var left = 0
    var right = chars.size - 1

    while (left &lt; right) {
        if (!chars[left].isLetter()) {
            left++
        } else if (!chars[right].isLetter()) {
            right--
        } else {
            chars[left] = chars[right].also { chars[right] = chars[left] }
            left++
            right--
        }
    }
    return chars.joinToString("")
}

4. Using Recursion

fun reverseOnlyLettersRecursive(s: String): String {
    val chars = s.toCharArray()
    fun helper(left: Int, right: Int): String {
        if (left &gt;= right) return String(chars)
        if (!chars[left].isLetter()) return helper(left + 1, right)
        if (!chars[right].isLetter()) return helper(left, right - 1)
        chars[left] = chars[right].also { chars[right] = chars[left] }
        return helper(left + 1, right - 1)
    }
    return helper(0, chars.size - 1)
}

5. Using Streams (Kotlin Functional Approach)

fun reverseOnlyLettersUsingStream(s: String): String {
    val letters = s.filter { it.isLetter() }.reversed().iterator()
    return s.map { if (it.isLetter()) letters.next() else it }.joinToString("")
}

These solutions showcase a variety of approaches—some use explicit data structures like stacks, while others use functional programming or regular expressions. Choose the method that best fits your style or problem constraints!

Summary

The "Reverse Only Letters" problem is a great exercise in string manipulation and working with constraints. Using the two-pointer technique ensures an optimal and clear solution. Whether you’re preparing for coding interviews or improving your problem-solving skills, this approach is worth mastering.

Feel free to try this code on your own and tweak it for other scenarios!

Scenario-based technical questions for a Senior Android Engineer interview

  3:00 PM            No comments

Comprehensive list of scenario-based technical questions for a Senior Android Engineer interview, covering various aspects of Android development and software engineering practices:



Scenario 1: Rewriting a Legacy App

Question: How would you approach rewriting a legacy Android app to improve scalability and maintainability?
Answer:
I would adopt Clean Architecture to structure the app into independent layers:

  • Domain Layer for business logic
  • Data Layer for repository and API interactions
  • Presentation Layer for UI using MVVM

I would migrate the app incrementally to avoid disruptions, starting with small modules and ensuring extensive unit tests for the rewritten sections. Dependency Injection (e.g., Hilt) would manage dependencies, and new features would be developed using the improved architecture while the legacy sections are refactored.

Scenario 2: Navigation Crash

Question: Users report crashes when navigating between fragments. How would you fix this?
Answer:
I would investigate the crash logs to pinpoint lifecycle issues, such as using retained fragments incorrectly. Transitioning to the Android Navigation Component resolves most navigation-related lifecycle issues, ensuring safe fragment transactions. Adding null checks and default fallbacks would prevent null pointer crashes. Tools like Firebase Crashlytics help monitor the fix in production.

Scenario 3: API Integration

Question: How do you manage third-party API integrations to make the app robust and future-proof?
Answer:
I’d encapsulate the API logic in a Repository Layer, isolating the app from changes to the API. Libraries like Retrofit handle networking, while Result wrappers ensure error states are managed gracefully. To future-proof, I’d use an abstraction layer so that switching APIs later won’t require massive codebase changes.

Scenario 4: RecyclerView Performance

Question: The RecyclerView in your app lags with large datasets. How would you optimize it?
Answer:
I’d optimize the ViewHolder pattern, avoiding redundant inflation of views. Leveraging ListAdapter with DiffUtil improves performance for dynamic datasets. For heavy image loads, libraries like Glide or Picasso are used with proper caching enabled. If the dataset is very large, Paging 3 ensures efficient, paginated loading.

Scenario 5: Unresponsive API Calls

Question: Users complain about unresponsive API calls. How do you handle this?
Answer:
To address this, I’d offload API calls to Coroutines on Dispatchers.IO to ensure they don’t block the main thread. Adding timeouts and retry mechanisms in OkHttp Interceptors prevents unresponsiveness. Showing a loading state keeps users informed, and local caching reduces API dependency for repeated data.

Scenario 6: Secure Token Storage

Question: How do you securely store API tokens in an Android app?
Answer:
For API 23+, I’d use EncryptedSharedPreferences or the Android Keystore System to store tokens securely. To prevent exposure during transit, all API requests are made over HTTPS, and sensitive tokens are refreshed periodically using OAuth mechanisms.

Scenario 7: Testing Flaky UI Tests

Question: How do you address flaky UI tests in your CI pipeline?
Answer:
I’d identify the root causes, such as timing issues or non-deterministic behaviors. Using IdlingResources ensures UI tests wait for background tasks to complete. Tests are rewritten for determinism by mocking external dependencies. For UI animations, disabling animations during testing improves reliability.

Scenario 8: Multi-Environment Support

Question: How do you configure an Android app for multiple environments (dev, staging, prod)?
Answer:
I’d use Gradle build flavors to define separate configurations for each environment. Each flavor would have its own properties file for environment-specific settings like base URLs or API keys. This setup ensures clean separation and easy switching during development and deployment.

Scenario 9: Junior Developer Code Review

Question: A junior developer’s pull request contains suboptimal code. How do you address this?
Answer:
I’d provide constructive feedback by highlighting specific issues, such as code inefficiencies or deviation from standards. Suggestions would be supported with documentation or examples. To improve learning, I’d schedule a pair programming session to guide them in implementing the changes.

Scenario 10: Periodic Background Jobs

Question: How do you fetch data periodically in an Android app without impacting performance?
Answer:
I’d use WorkManager with periodic work constraints. Configurations like network type and battery usage constraints ensure efficiency. Exponential backoff handles retries on failure, and app state is preserved using Data objects passed to the worker.

Scenario 11: Slow Build Times

Question: Your team is experiencing slow build times. How would you address this issue?
Answer:
I’d analyze the build process using Gradle’s build scan tools to identify bottlenecks, such as excessive task configurations or dependencies. Recommendations include:

  • Dependency resolution: Use API instead of implementation for unnecessary module dependencies.
  • Parallel execution: Enable parallel execution in Gradle.
  • Build caching: Configure remote caching to speed up builds in CI environments.
  • Modularization: Break the app into smaller modules, improving build times for incremental changes.

Scenario 12: App State Restoration

Question: How would you handle app state restoration after process death?
Answer:
I’d use ViewModel and SavedStateHandle to persist critical UI state. For larger datasets or app-wide data, Room Database or SharedPreferences would store non-sensitive data. The onSaveInstanceState method ensures transient states (like scroll positions) are restored using Bundle.

Scenario 13: Dependency Updates

Question: A library you depend on has released a critical update. How do you handle updating dependencies?
Answer:
I’d analyze the release notes and change logs to understand potential impacts. Before updating, I’d test the new version in a separate branch or a feature flag. CI pipelines would run full regression tests to ensure no functionality breaks. Gradle’s dependency locking helps manage controlled updates in the team.

Scenario 14: Multi-Module Navigation

Question: How would you implement navigation in a multi-module app?
Answer:
I’d use the Navigation Component with dynamic feature modules. Deep links are utilized for cross-module navigation. Navigation logic remains within each module, and shared arguments are passed using SafeArgs. Dynamic feature module delivery ensures lightweight APKs for specific features.

Scenario 15: Offline-First Architecture

Question: How would you design an offline-first app?
Answer:
I’d use a Room Database as the single source of truth, with APIs syncing data in the background using WorkManager. Conflict resolution strategies (e.g., timestamp-based syncing) ensure consistency. Data updates are observed via LiveData or Flow, providing a seamless offline and online experience.

Scenario 16: Memory Leaks in Fragments

Question: How would you debug and resolve memory leaks in fragments?
Answer:
I’d use tools like LeakCanary to detect leaks. Common issues include retaining fragment references in ViewModels or adapters. Avoiding anonymous inner classes and clearing listeners in onDestroyView prevents leaks. Switching to Fragment KTX utilities simplifies fragment lifecycle handling.

Scenario 17: Expanding App to Tablets

Question: How would you optimize your app to support tablet devices?
Answer:
I’d implement responsive layouts using resource qualifiers (layout-w600dp, etc.). ConstraintLayout or Compose's BoxWithConstraints helps create flexible designs. Tablets would leverage split-screen functionality and dual-pane layouts for a richer experience. I’d test on actual devices or simulators with varying aspect ratios.

Scenario 18: Network State Handling

Question: How would you handle intermittent network connectivity in your app?
Answer:
Using ConnectivityManager, I’d monitor network status and notify users of connectivity changes. For intermittent connections, I’d use WorkManager with a NetworkType.CONNECTED constraint for retries. Local caching with Room or offline-first design ensures minimal disruption for users.

Scenario 19: ProGuard Rules Issue

Question: After enabling ProGuard, some features break in release builds. How do you troubleshoot this?
Answer:
I’d check ProGuard logs for obfuscation rules causing issues. Adding keep rules for critical classes or libraries resolves the problem. For example, libraries like Gson need rules to retain serialized class names. Testing the release APK in a staging environment prevents such errors from reaching production.

Scenario 20: Gradle Dependency Conflicts

Question: How do you handle dependency version conflicts in a multi-module project?
Answer:
I’d resolve dependency conflicts by enforcing versions in the root build.gradle using the constraints block. Gradle’s dependency resolution tools or ./gradlew dependencies help identify conflicts. Upgrading to a shared compatible version or excluding transitive dependencies ensures compatibility.

Scenario 21: Gradual Migration to Jetpack Compose

Question: How would you migrate an app with traditional XML layouts to Jetpack Compose without disrupting ongoing development?
Answer:
I’d use ComposeView to integrate Jetpack Compose into existing XML-based screens. This allows for gradual migration by converting one feature or screen at a time. The strategy ensures compatibility between Compose and View-based UIs. Migration priorities would be screens with simple layouts or those undergoing redesigns. Thorough testing would validate seamless UI interactions during the transition.

Scenario 22: Managing App Performance During Animation

Question: How do you optimize animations to maintain 60 FPS in an Android app?
Answer:
I’d use Jetpack Compose animations or Android’s Animator API, ensuring minimal main-thread blocking. Optimizations include precomputing values, reducing overdraw with proper layering, and using lightweight vector assets instead of large bitmaps. Profiling tools like GPU Profiler or Layout Inspector help identify performance bottlenecks. Asynchronous animations using Coroutines also minimize UI thread load.

Scenario 23: Handling Sensitive Data in Logs

Question: How do you ensure sensitive user data doesn’t appear in logs during debugging?
Answer:
I’d avoid logging sensitive data altogether by following best practices like:

  • Tag masking for potentially sensitive information.
  • Utilizing Log.d() only in debug builds using BuildConfig.DEBUG.
  • Leveraging tools like Timber for conditional logging and ensuring proguard-rules.pro strips out all logs in release builds.

Scenario 24: App Crash on Specific Devices

Question: Your app works fine on most devices but crashes on a few specific models. How would you debug this?
Answer:
I’d start by analyzing device-specific crash logs through Firebase Crashlytics or Play Console’s Vitals. Common issues include hardware limitations, API compatibility, or vendor-specific customizations. I’d test on emulators or real devices mimicking those models and apply device-specific feature toggles or fallback logic to ensure stability.

Scenario 25: Adopting KMM (Kotlin Multiplatform Mobile)

Question: How would you decide if Kotlin Multiplatform Mobile (KMM) is suitable for your project?
Answer:
I’d evaluate if the app’s business logic can be shared across platforms. Projects with extensive API integrations or business rules benefit most from KMM. I’d ensure the team is comfortable with Kotlin and modular architecture. UI layers would remain native (Jetpack Compose for Android and SwiftUI for iOS), while the shared code handles networking, data parsing, and logic.

Scenario 26: Debugging High Battery Usage

Question: Users report your app drains their battery quickly. How would you address this?
Answer:
Using Android Studio’s Energy Profiler, I’d monitor wake locks, background jobs, and location services. Optimizations include batching background tasks with WorkManager, reducing GPS usage frequency with fused location providers, and leveraging low-power modes for periodic operations. Removing unnecessary foreground services helps reduce power consumption.

Scenario 27: Scaling an App for Millions of Users

Question: How would you scale an Android app to handle millions of active users?
Answer:
I’d optimize the app for minimal network usage using effective caching strategies (e.g., Room or DiskLruCache). Efficient API pagination and batched updates would reduce server strain. Metrics and crash monitoring tools (e.g., Firebase Analytics, Sentry) provide insights into performance and usage patterns. Incremental rollout strategies prevent widespread issues.

Scenario 28: Addressing App Uninstall Feedback

Question: How do you act on feedback that users uninstall your app due to poor onboarding?
Answer:
I’d streamline the onboarding process by reducing friction with concise, visually engaging walkthroughs. Adding in-app prompts for permissions only when necessary improves the first experience. A/B testing onboarding flows and analyzing retention metrics help refine the process.

Scenario 29: Maintaining Backward Compatibility

Question: How do you support legacy Android devices while using modern features?
Answer:
I’d use Jetpack Libraries to provide backward-compatible implementations of modern features. Features exclusive to higher API levels are guarded with Build.VERSION.SDK_INT checks. Custom implementations or polyfills provide fallbacks for unsupported features on older devices.

Scenario 30: Real-Time Feature Flags

Question: How would you implement feature flags for dynamic control over app behavior?
Answer:
I’d integrate a feature flag service like Firebase Remote Config or a custom implementation using a REST API and local caching. Flags are dynamically fetched at app startup and stored in local preferences. The code paths for new features remain toggleable, allowing easy enable/disable scenarios without requiring an app update.

Scenario 31: Integrating Payments

Question: How do you integrate in-app purchases securely?
Answer:
I’d use Google Play Billing API for secure purchase handling. Verifying purchases with the server ensures authenticity. Sensitive business logic is implemented server-side, and the app only displays validated purchase states. Subscription models follow best practices for automatic renewal handling and cancellation prompts.

Scenario 32: Codebase Documentation

Question: Your team is struggling with understanding parts of the codebase. How do you address this?
Answer:
I’d introduce KDoc comments in the code for method and class documentation. A centralized wiki system like Confluence or GitHub Pages provides detailed guides and architecture diagrams. Regular knowledge-sharing sessions ensure all team members are aligned.

Scenario 33: Leading a Team through Technical Debt

Question: Your team is facing significant technical debt due to quick fixes in the past. How would you prioritize and address this challenge?
Answer:
I’d start by identifying critical areas of technical debt using static analysis tools (e.g., SonarQube) and gathering feedback from developers. I’d prioritize issues that impact performance, security, or maintainability. During sprint planning, I would allocate time for refactoring while ensuring that new features are still being delivered. Introducing Code Reviews with an emphasis on long-term maintainability helps avoid further accumulation of technical debt. Additionally, I’d encourage the team to gradually improve the codebase with regular cleanup tasks and foster a culture of continuous refactoring.

Scenario 34: Managing Conflicting Opinions in the Team

Question: During a sprint planning session, two developers strongly disagree on the architecture approach for a feature. How would you handle this conflict?
Answer:
I’d listen to both developers and ensure they explain their reasoning clearly, focusing on the pros and cons of each approach. I’d encourage data-driven discussions (e.g., performance benchmarks, previous project examples). If needed, I’d bring in a third-party expert (e.g., senior developer or architect) to help make an informed decision. If the disagreement persists, I’d consider running a proof-of-concept (POC) to evaluate both approaches in real-world conditions. This fosters a collaborative environment while helping the team make the best technical decision for the feature.

Scenario 35: Onboarding a New Developer to an Existing Codebase

Question: How would you onboard a new developer who is unfamiliar with your app’s architecture and codebase?
Answer:
I’d provide the new developer with a structured onboarding guide, including:

  1. Codebase Overview: Detailed documentation on the architecture, technologies used, and the project structure.
  2. Key Concepts: Introduce design patterns like MVVM, dependency injection (e.g., Hilt), and CI/CD pipelines.
  3. Hands-On Tasks: Assign simple tasks (e.g., bug fixes or small feature enhancements) to help them get familiar with the codebase and development workflow.
  4. Mentorship: Pair the developer with a more experienced team member for code reviews and guidance.
    Regular check-ins ensure they feel supported throughout the process.

Scenario 36: Automated Tests in a CI/CD Pipeline

Question: How would you ensure that all tests are passing before deploying an app in a CI/CD pipeline?
Answer:
I’d configure the CI/CD pipeline (e.g., Jenkins, GitHub Actions) to run automated tests for every commit or pull request. This includes unit tests (via JUnit), UI tests (via Espresso or Compose Test), and integration tests. Code coverage tools (e.g., JaCoCo) would ensure comprehensive testing. Additionally, I’d enable static analysis tools like Lint and SonarQube to check for code quality issues. The pipeline would fail if any tests fail, preventing broken code from reaching production.

Scenario 37: Dealing with Deployment Failures

Question: You deploy a new version of the app, but users report issues. How do you handle this situation?
Answer:
I’d immediately roll back the deployment if the issues are critical, using Google Play Console’s staged rollout feature to limit exposure. Then, I’d review crash reports from Firebase Crashlytics and check analytics for affected users. Once the root cause is identified, I’d prioritize a hotfix, test it in a staging environment, and then redeploy. Post-mortem analysis would help understand what went wrong and ensure better testing or monitoring practices in the future. Communication with users about the issue and its resolution is essential for trust.

Scenario 38: Testing with Multiple Android Versions

Question: How would you ensure that your app works across various Android versions and devices?
Answer:
I’d set up automated tests targeting multiple Android versions using Firebase Test Lab or Sauce Labs to test on real devices. I’d include API version checks within the app to handle specific features and permissions for older Android versions. Additionally, I’d manually test on critical versions (e.g., Android 10, 11, 12, etc.) and leverage tools like Android Device Monitor to simulate devices with different screen sizes, resolutions, and OS versions.

Scenario 39: Continuous Integration (CI) Configuration

Question: You need to set up a new CI/CD pipeline for an Android project. What tools and steps would you use?
Answer:
I’d choose Jenkins, GitHub Actions, or CircleCI as CI tools. The pipeline steps would include:

  1. Clone Repository: Pull the latest code from the version control system (e.g., GitHub, GitLab).
  2. Build: Use Gradle to build the APK.
  3. Static Analysis: Run Lint and SonarQube checks for code quality.
  4. Run Tests: Execute unit tests (JUnit), UI tests (Espresso), and instrumented tests.
  5. Publish: Upload the build to Google Play Console or Firebase App Distribution for testing.
  6. Deploy: Deploy to production only after passing all tests and reviews.
    This setup automates the process and ensures consistency across environments.

Scenario 40: Code Freeze Before Release

Question: How do you manage a code freeze before a major release?
Answer:
Before the code freeze, I’d ensure all features for the release are completed and tested. The freeze date is communicated well in advance. During the freeze, only critical bug fixes and high-priority tasks are allowed. I’d schedule QA testing, run regression tests, and address any remaining issues promptly. A branch protection strategy is enforced, ensuring no new features or changes are merged during the freeze. The focus is on stabilizing the app for release, ensuring that no new bugs are introduced.

Scenario 41: Performance Testing and Optimization

Question: How would you approach performance testing and optimization for an Android app?
Answer:
I’d start by identifying critical areas that affect performance, such as startup time, network requests, memory usage, and UI responsiveness. Tools like Android Profiler, Systrace, and Firebase Performance Monitoring help pinpoint issues. For optimization:

  • Lazy loading reduces memory consumption and startup time.
  • Background tasks (e.g., using WorkManager) are optimized to avoid battery drain.
  • RecyclerView optimizations like ViewHolder patterns and DiffUtil for list updates.
  • Image loading is done efficiently using libraries like Glide or Picasso to handle caching and resizing.
  • Threading and Coroutines ensure smooth UI interactions by avoiding main-thread blocking.

Scenario 42: Handling App Crashes in Production

Question: How do you respond if your app crashes in production and affects a significant portion of users?
Answer:
I’d first check Firebase Crashlytics or Play Console crash reports to identify the crash’s root cause. If the issue is critical, I’d initiate a hotfix and ensure it passes all necessary tests before redeploying. Rollbacks or staged rollouts minimize user impact while fixing the issue. In parallel, I’d work on a longer-term solution to prevent similar issues, such as adding more test coverage, improving error handling, or adding more specific logging. Clear communication with users is also essential during this process.

Would you like even more specific scenarios or focus on any other technical areas? Let me know in comments below !

Sudoku Puzzle Image with Jetpack Compose

  2:40 PM            No comments

 To create a Sudoku puzzle image programmatically in Kotlin, you can use libraries such as Android Canvas or Jetpack Compose. Below is an example using Jetpack Compose, which is a modern toolkit for building Android UI.

Sudoku Puzzle Image with Jetpack Compose

This code draws a 9x9 Sudoku grid with some numbers pre-filled.

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.Canvas
import androidx.compose.foundation.layout.*
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.graphics.Paint
import androidx.compose.ui.text.TextStyle
import androidx.compose.ui.unit.dp
import androidx.compose.ui.unit.sp
import androidx.compose.foundation.text.BasicText

class SudokuActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            SudokuGrid()
        }
    }
}

@Composable
fun SudokuGrid() {
    val puzzle = arrayOf(
        charArrayOf('5', '3', '.', '.', '7', '.', '.', '.', '.'),
        charArrayOf('6', '.', '.', '1', '9', '5', '.', '.', '.'),
        charArrayOf('.', '9', '8', '.', '.', '.', '.', '6', '.'),
        charArrayOf('8', '.', '.', '.', '6', '.', '.', '.', '3'),
        charArrayOf('4', '.', '.', '8', '.', '3', '.', '.', '1'),
        charArrayOf('7', '.', '.', '.', '2', '.', '.', '.', '6'),
        charArrayOf('.', '6', '.', '.', '.', '.', '2', '8', '.'),
        charArrayOf('.', '.', '.', '4', '1', '9', '.', '.', '5'),
        charArrayOf('.', '.', '.', '.', '8', '.', '.', '7', '9')
    )

    Box(Modifier.fillMaxSize().padding(16.dp)) {
        Canvas(modifier = Modifier.fillMaxSize()) {
            val gridSize = size.width
            val cellSize = gridSize / 9f

            val paint = Paint().apply { color = Color.Black }

            // Draw the grid lines
            for (i in 0..9) {
                val lineWidth = if (i % 3 == 0) 6f else 2f
                drawLine(
                    start = androidx.compose.ui.geometry.Offset(i * cellSize, 0f),
                    end = androidx.compose.ui.geometry.Offset(i * cellSize, gridSize),
                    paint.apply { strokeWidth = lineWidth }
                )
                drawLine(
                    start = androidx.compose.ui.geometry.Offset(0f, i * cellSize),
                    end = androidx.compose.ui.geometry.Offset(gridSize, i * cellSize),
                    paint.apply { strokeWidth = lineWidth }
                )
            }
        }

        // Fill the grid with numbers
        for (row in puzzle.indices) {
            for (col in puzzle[row].indices) {
                val number = puzzle[row][col]
                if (number != '.') {
                    BasicText(
                        text = number.toString(),
                        style = TextStyle(color = Color.Black, fontSize = 20.sp),
                        modifier = Modifier
                            .offset(x = (col * (size / 9f)).dp, y = (row * (size / 9f)).dp)
                    )
                }
            }
        }
    }
}

How It Works:

  1. Grid Drawing:
    The Canvas composable is used to draw the Sudoku grid. Thicker lines are drawn every three cells to demarcate the 3x3 sub-grids.

  2. Number Placement:
    A nested loop iterates over the puzzle array and places numbers using BasicText at the correct cell coordinates.

  3. Customizations:

    • Grid Size: Automatically adapts to the screen.
    • Font Size and Style: Easily customizable for better visuals.

Output:

  • A 9x9 Sudoku grid is displayed, with the given puzzle pre-filled.
  • The grid uses clear lines and neatly places numbers in their respective cells.


This example provides a dynamic, scalable, and modern approach for creating Sudoku images directly in an Android app.

Sudoku Logic: A Guide for Android Engineers

  2:33 PM            No comments

Sudoku is a classic logic-based puzzle that challenges both casual enthusiasts and seasoned programmers. Beyond entertainment, solving Sudoku programmatically can improve an engineer's problem-solving and algorithmic thinking. In this article, we explore two popular LeetCode challenges — Valid Sudoku and Sudoku Solver — along with efficient solutions in Kotlin, tailored for Android engineers.



1. Understanding Sudoku Rules

A Sudoku puzzle is a 9x9 grid divided into 3x3 sub-grids. The objective is to fill the grid so that:

  1. Each row contains numbers 1-9 without repetition.
  2. Each column contains numbers 1-9 without repetition.
  3. Each 3x3 sub-grid contains numbers 1-9 without repetition.

Challenge 1: Valid Sudoku

Problem: Check whether a partially filled Sudoku board is valid, without requiring it to be solvable.

Kotlin Solution

fun isValidSudoku(board: Array<CharArray>): Boolean {
    val rows = Array(9) { mutableSetOf<Char>() }
    val cols = Array(9) { mutableSetOf<Char>() }
    val grids = Array(9) { mutableSetOf<Char>() }

    for (i in 0 until 9) {
        for (j in 0 until 9) {
            val num = board[i][j]
            if (num == '.') continue
            
            val gridIndex = (i / 3) * 3 + j / 3
            if (num in rows[i] || num in cols[j] || num in grids[gridIndex]) {
                return false
            }

            rows[i].add(num)
            cols[j].add(num)
            grids[gridIndex].add(num)
        }
    }
    return true
}

Explanation

  1. Tracking Numbers:

    • Use three arrays of sets to store numbers seen in rows, columns, and sub-grids.
    • Each array has 9 sets (one for each row, column, or grid).

  2. Grid Mapping:

    • Map each cell to its corresponding sub-grid using the formula:
      gridIndex = (i / 3) * 3 + j / 3.

  3. Validation:

    • For every non-empty cell, check if the number already exists in the corresponding row, column, or grid. If so, return false.

  4. Time Complexity:

    • O(81)O(81): Iterating over the fixed 9x9 board.

  5. Space Complexity:

    • O(27)O(27): Using three arrays of 9 sets.

Challenge 2: Sudoku Solver

Problem: Write a program to solve a given Sudoku puzzle by filling empty cells.

Kotlin Solution

fun solveSudoku(board: Array<CharArray>) {
    solve(board)
}

private fun solve(board: Array<CharArray>): Boolean {
    for (row in 0 until 9) {
        for (col in 0 until 9) {
            if (board[row][col] == '.') {
                for (num in '1'..'9') {
                    if (isValidPlacement(board, row, col, num)) {
                        board[row][col] = num
                        if (solve(board)) return true
                        board[row][col] = '.' // Backtrack
                    }
                }
                return false // Trigger backtracking
            }
        }
    }
    return true // Puzzle is solved
}

private fun isValidPlacement(board: Array<CharArray>, row: Int, col: Int, num: Char): Boolean {
    for (i in 0 until 9) {
        if (board[row][i] == num || board[i][col] == num || 
            board[(row / 3) * 3 + i / 3][(col / 3) * 3 + i % 3] == num) {
            return false
        }
    }
    return true
}

Explanation

  1. Backtracking Approach:

    • Identify the first empty cell ('.').
    • Try placing numbers from '1' to '9'.
    • Check if the placement is valid. If yes:
      • Place the number and proceed to the next empty cell recursively.
      • If the board cannot be solved with the current placement, backtrack by resetting the cell.

  2. Validation:

    • Ensure the number does not conflict with the row, column, or 3x3 grid.

  3. Time Complexity:

    • In the worst case, O(9m)O(9^m), where mm is the number of empty cells.

  4. Space Complexity:

    • O(m)O(m) for the recursion stack.

How Does This Relate to Android?

  1. Logic Implementation:

    • The same backtracking and validation techniques can be applied to game development in Android (e.g., building a Sudoku app).

  2. Data Structures:

    • Kotlin's Array and Set are essential in Android development for handling collections efficiently.

  3. Performance Optimization:

    • Reducing space and time complexity is vital for smooth Android app performance.

  4. UI Updates:

    • Integrate this logic with Jetpack Compose or RecyclerView to dynamically update the Sudoku board UI based on user interaction.

Conclusion

Mastering Sudoku logic teaches key programming concepts:

  • Data Validation: Ensuring correctness in user input or data processing.
  • Backtracking: A versatile approach for solving constraint-based problems.
  • Efficiency: Balancing complexity with performance.

For Android engineers, these problems also highlight Kotlin's expressiveness and its suitability for crafting efficient algorithms.

Whether you are preparing for a coding interview or building a Sudoku app, these solutions provide a foundation to tackle complex challenges with confidence.

How to Implement the SOLID Principles in an Android App Using Kotlin

  11:08 AM            No comments

The SOLID principles are fundamental design principles that help developers create maintainable, scalable, and robust software. These principles, initially introduced by Robert C. Martin (Uncle Bob), provide a framework for writing clean and reusable code. In this article, we'll explore how to implement the SOLID principles in an Android app using Kotlin, with practical examples and use cases for each principle.


1. Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change.

Use Case: Managing responsibilities for a User Profile feature.
A common violation of SRP in Android development is creating a class that handles UI logic, network calls, and database operations. By adhering to SRP, we can separate these responsibilities.

Implementation Example:

class UserProfileRepository {
    fun getUserProfile(userId: String): UserProfile {
        // Fetch user profile from API or database
    }
}

class UserProfileViewModel(private val repository: UserProfileRepository) : ViewModel() {
    val userProfile = MutableLiveData<UserProfile>()

    fun loadUserProfile(userId: String) {
        viewModelScope.launch {
            val profile = repository.getUserProfile(userId)
            userProfile.value = profile
        }
    }
}

Here, the UserProfileRepository handles data fetching, while the UserProfileViewModel handles UI logic.

2. Open/Closed Principle (OCP)

Definition: A class should be open for extension but closed for modification.

Use Case: Adding new payment methods without modifying existing code.
When adding new functionality, we should avoid changing existing classes. Instead, we can extend them.

Implementation Example:

interface PaymentProcessor {
    fun processPayment(amount: Double)
}

class CreditCardPayment : PaymentProcessor {
    override fun processPayment(amount: Double) {
        println("Processing credit card payment of $$amount")
    }
}

class PayPalPayment : PaymentProcessor {
    override fun processPayment(amount: Double) {
        println("Processing PayPal payment of $$amount")
    }
}

fun processPayment(paymentProcessor: PaymentProcessor, amount: Double) {
    paymentProcessor.processPayment(amount)
}

Here, adding a new payment method requires creating a new class that implements PaymentProcessor, without modifying existing code.

3. Liskov Substitution Principle (LSP)

Definition: Subtypes must be substitutable for their base types.

Use Case: Implementing different types of notifications (e.g., Email and SMS).
The derived class should work seamlessly in place of its base class without altering the program's behavior.

Implementation Example:

open class Notification {
    open fun send(message: String) {
        println("Sending notification: $message")
    }
}

class EmailNotification : Notification() {
    override fun send(message: String) {
        println("Sending email: $message")
    }
}

class SMSNotification : Notification() {
    override fun send(message: String) {
        println("Sending SMS: $message")
    }
}

fun notifyUser(notification: Notification, message: String) {
    notification.send(message)
}

4. Interface Segregation Principle (ISP)

Definition: A class should not be forced to implement methods it does not use.

Use Case: Managing different authentication methods like Google and Facebook login.
Instead of creating a single interface with all authentication methods, split it into smaller interfaces.

Implementation Example:

interface GoogleAuth {
    fun authenticateWithGoogle()
}

interface FacebookAuth {
    fun authenticateWithFacebook()
}

class GoogleLogin : GoogleAuth {
    override fun authenticateWithGoogle() {
        println("Authenticated with Google")
    }
}

class FacebookLogin : FacebookAuth {
    override fun authenticateWithFacebook() {
        println("Authenticated with Facebook")
    }
}

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions.

Use Case: Injecting dependencies in a weather app.
We can use interfaces and dependency injection to reduce coupling between classes.

Implementation Example:

interface WeatherService {
    fun fetchWeatherData(city: String): WeatherData
}

class OpenWeatherService : WeatherService {
    override fun fetchWeatherData(city: String): WeatherData {
        // Fetch weather data from OpenWeather API
    }
}

class WeatherViewModel(private val service: WeatherService) : ViewModel() {
    val weatherData = MutableLiveData&lt;WeatherData&gt;()

    fun getWeather(city: String) {
        viewModelScope.launch {
            val data = service.fetchWeatherData(city)
            weatherData.value = data
        }
    }
}

// Using Hilt for Dependency Injection
@Module
@InstallIn(SingletonComponent::class)
object WeatherModule {
    @Provides
    fun provideWeatherService(): WeatherService = OpenWeatherService()
}

Additional Detailed Example: A Ride-Sharing App

Scenario: A ride-sharing app implementing SOLID principles to manage different ride types (e.g., economy, luxury) and location services.

Single Responsibility Principle

Separate ride management from location tracking:

class RideManager {
    fun calculateFare(distance: Double, rate: Double): Double {
        return distance * rate
    }
}

class LocationTracker {
    fun getCurrentLocation(): Location {
        // Logic to fetch current location
    }
}

Open/Closed Principle

Add new ride types without modifying the existing system:

abstract class Ride {
    abstract fun calculateFare(distance: Double): Double
}

class EconomyRide : Ride() {
    override fun calculateFare(distance: Double): Double {
        return distance * 0.5
    }
}

class LuxuryRide : Ride() {
    override fun calculateFare(distance: Double): Double {
        return distance * 1.5
    }
}

Liskov Substitution Principle

Substitute ride types without affecting functionality:

fun showRideFare(ride: Ride, distance: Double) {
    println("Fare: ${ride.calculateFare(distance)}")
}

Interface Segregation Principle

Segregate ride payment and ride tracking:

interface RidePayment {
    fun processPayment(amount: Double)
}

interface RideTracking {
    fun trackRide(rideId: String)
}

Dependency Inversion Principle

Decouple the ViewModel from the ride repository:

interface RidePayment {
    fun processPayment(amount: Double)
}

interface RideTracking {
    fun trackRide(rideId: String)
}

Summary: Why SOLID Principles Matter in Android Development

  • Maintainability: Classes with a single responsibility and clear boundaries are easier to debug and extend.
  • Scalability: By adhering to OCP and DIP, the app can grow without disrupting existing functionality.
  • Reusability: Following ISP and LSP ensures that components are modular and can be reused across different parts of the application.
  • Testability: SOLID principles promote decoupled and well-structured code, making it easier to write and maintain unit tests.

By applying the SOLID principles, you can design Android apps with improved modularity, testability, and extensibility. Whether building an e-commerce app, a music player, or a ride-sharing app, these principles help organize code effectively. They ensure that your app remains adaptable to future requirements while reducing the risk of bugs and technical debt. Use these examples as a starting point for implementing SOLID in your projects!

Subscribe to: Posts (Atom)