DEV Community: Getinfo Toyou

I built Json To Toon — Save 40-60% on AI tokens instantly by converting your JSON to TOON.

Getinfo Toyou — Wed, 23 Sep 2026 14:30:21 +0000

error: invalid model selection (--model "Gemini 3.5 Flash (High)" --effort ""): model Gemini 3.5 Flash (High) is not recognized as a known model or custom model in settings
Available models:
Gemini 3.8 Flash (High)
Gemini 3.8 Flash (Medium)
Gemini 3.8 Flash (Low)
Gemini 3.7 Flash (High)
Gemini 3.7 Flash (Medium)
Gemini 3.7 Flash (Low)
Gemini 3.6 Flash (High)
Gemini 3.6 Flash (Medium)
Gemini 3.6 Flash (Low)
Gemini 3.1 Pro (High)
Gemini 3.1 Pro (Low)
Claude Sonnet 4.6 (Thinking)
Claude Opus 4.6 (Thinking)
GPT-OSS 120B (Medium)

I built Photoconvert — Securely resize and convert images right in your browser.

Getinfo Toyou — Mon, 21 Sep 2026 14:30:16 +0000

I built Home Loan EMI Calculator — Calculate your home loan EMI and view repayment schedules instantly.

Getinfo Toyou — Fri, 18 Sep 2026 14:40:58 +0000

I built Aimarkdownpro — Convert Markdown to clean HTML with AI-optimized precision.

Getinfo Toyou — Wed, 16 Sep 2026 14:30:30 +0000

I built Javascript — Interactive programming lessons to master coding step-by-step.

Getinfo Toyou — Fri, 11 Sep 2026 14:30:13 +0000

I built Imageslim — Fast, private image resizing and compression in your browser.

Getinfo Toyou — Wed, 09 Sep 2026 14:30:15 +0000

Optimizing CameraX and ML Kit for Real-World Workflows: Building Sharp QR

Getinfo Toyou — Mon, 07 Sep 2026 14:31:12 +0000

Optimizing CameraX and ML Kit for Real-World Workflows: Building Sharp QR

Most modern Android phones ship with a default camera app capable of detecting QR codes. Yet, if you look at the Play Store, barcode and QR scanning utilities remain persistently popular.

Why? Because default camera implementations are designed for casual photography, not high-throughput, specialized utility tasks. Most third-party alternatives swing too far in the opposite direction: bloated with intrusive ads, full-screen video interruptions, and sketchy permissions.

When I set out to build Sharp QR, my goal was to build a clean, reliable scanner and generator focused on performance and practical utility.

Here is a look at who this tool was built for, the technical challenges behind it, and what I learned building it with modern Android tooling.

Who Actually Needs a Dedicated QR Tool?

While everyday users occasionally scan a restaurant menu, certain professional workflows demand something far more dependable and focused:

Event Organizers and Check-in Staff: When you need to process hundreds of attendees entering a venue, a standard camera app hunting for focus on wrinkled paper or dim phone screens causes massive bottlenecks. They need instant feedback, persistent history logs, and offline reliability.
Marketers and Print Designers: Marketers regularly generate URLs, vCards, and Wi-Fi credentials for packaging, posters, and business cards. They need a tool that can instantly generate precise, high-contrast QR matrices, verify how they parse across different data schemas, and test them locally before sending assets to the print shop.
Field Technicians and IT Administrators: Technicians regularly scan asset tags, network router credentials, and serial numbers in poorly lit server racks or warehouses. They need direct access to torch controls, instant clipboard copying, and zero ad popups blocking their workflow.

The Tech Stack

To keep the footprint small and the UI responsive, I relied on modern, first-party Android libraries:

Language: Kotlin
UI Layer: Jetpack Compose (Material 3)
Camera Pipeline: AndroidX CameraX (camera-camera2, camera-lifecycle, camera-view)
Vision Processing: Google ML Kit Barcode Scanning API (bundled model)
Local Persistence: Room Database with Kotlin Coroutines and Flow
QR Generation: ZXing Core (strictly used for the encoding matrix logic)

Technical Challenges

1. Frame Analysis Bottlenecks with CameraX

Setting up CameraX with ImageAnalysis.Analyzer is straightforward on paper, but keeping the frame rate steady across diverse hardware is tricky. Feeding every 30fps YUV frame directly into ML Kit's detector quickly leads to thermal throttling and dropped frames on budget devices.

To solve this, I decoupled frame delivery from analysis. Using ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST ensured the camera pipeline never blocked waiting for ML Kit to complete inference on the previous frame. Additionally, I scoped the target analysis resolution to 1080p, which provides the sweet spot between reading dense, small QR codes and maintaining sub-50ms inference times.

2. Eliminating Detection Jitter

When scanning in continuous mode or saving scan history, ML Kit will report the same barcode across 15 consecutive frames. Without debouncing, your database fills up with duplicates instantly.

I built a simple time-window debounce mechanism using Kotlin Flows:

private var lastScannedValue: String? = null
private var lastScannedTimestamp: Long = 0L
private val scanCooldownMs = 1500L

fun onBarcodeDetected(rawValue: String) {
    val now = System.currentTimeMillis()
    if (rawValue != lastScannedValue || (now - lastScannedTimestamp) > scanCooldownMs) {
        lastScannedValue = rawValue
        lastScannedTimestamp = now
        processBarcode(rawValue)
    }
}

3. Asynchronous Code Generation

Generating QR codes with custom error correction levels (L, M, Q, H) using ZXing can cause perceptible frame drops if executed on the main dispatcher, particularly for large payloads like vCards. I offloaded all BitMatrix calculations and Bitmap rendering to Dispatchers.Default, passing the finished bitmap to Compose via a state holder.

Lessons Learned

Don't overcomplicate the vision pipeline: Google ML Kit's bundled barcode model adds minimal app size while running fully on-device without an active internet connection. It consistently outperformed custom OpenCV pipelines for standard 2D formats.
Haptic feedback matters: In high-speed workflows (like scanning asset tags), visual cues on screen aren't enough. Adding subtle, immediate haptic feedback via Vibrator upon successful parsing drastically improves the operator's scanning rhythm.

Try It Out

Sharp QR is built to do one job with speed and precision, without paywalls or distracting banner ads.

If you regularly work with QR codes or need a reliable utility for your workflow, you can download Sharp QR on Google Play.

You can also explore more independent utilities built for practical use cases at getinfotoyou.com.

Building a Zero-Bloat Android Runner: Object Pooling, Low-Latency Input, and Optimization

Getinfo Toyou — Fri, 04 Sep 2026 14:31:08 +0000

Modern mobile gaming often comes with an unspoken tax: 500MB download sizes, endless splash screens, and aggressive background services that drain batteries. When you just want a quick three-minute distraction while standing in line or riding the train, waiting through loading bars and shader pre-compilations ruins the experience.

I built Echo Runner to solve that specific annoyance. It is a lean, fast-paced endless runner designed to launch instantly, run at a locked 60 frames per second on budget devices, and deliver straightforward arcade reflex gameplay without unnecessary bloat.

Here is a look at the technical decisions behind Echo Runner, the engineering challenges of low-spec Android optimization, and who gains the most from this approach.

Who Benefits Most From This Architecture?

Before diving into the code, it helps to understand the target profile. Echo Runner was designed specifically for two groups:

Commuters and casual mobile gamers on budget or aging hardware: Players who do not own flagship phones, have limited storage, or deal with spotty network connections. They need a responsive game that opens in two seconds, consumes minimal battery, and does not hitch when an obstacle appears.
Players who value reflex-driven gameplay over pay-to-win systems: Many modern runners introduce artificial speed caps or energy meters that recharge with microtransactions. Echo Runner is built on clean, pure skill progression where level difficulty scales mathematically rather than commercially.

The Tech Stack

To balance rapid development with low-level control, I used:

Engine: Unity (stripped-down Universal Render Pipeline with all post-processing passes removed except minimal bloom).
Language: C# using strictly allocation-free patterns during the main loop.
Target Platform: Android (targeting API level 34, backward-compatible to Android 8.0).
Asset Pipeline: Low-poly meshes, unlit vertex-colored shaders, and compressed audio buffers to keep total APK download size low.

Technical Challenges and Solutions

1. Eliminating Garbage Collection Spikes

In an endless runner, spawning and destroying platforms, obstacles, and pick-ups dynamically is the standard pattern. In C#, frequent calls to Instantiate() and Destroy() trigger the Mono runtime's garbage collector. When the GC runs on low-end Android hardware, it causes noticeable micro-stutter (50-100ms frame drops)—which instantly kills a player in a precision reflex game.

To fix this, I implemented an aggressive generic object pooling system:

public class ObjectPool<T> where T : Component
{
    private readonly Queue<T> _availableObjects = new();
    private readonly T _prefab;
    private readonly Transform _parent;

    public ObjectPool(T prefab, int initialSize, Transform parent = null)
    {
        _prefab = prefab;
        _parent = parent;
        for (int i = 0; i < initialSize; i++)
        {
            T instance = Object.Instantiate(_prefab, _parent);
            instance.gameObject.SetActive(false);
            _availableObjects.Enqueue(instance);
        }
    }

    public T Rent()
    {
        T item = _availableObjects.Count > 0 ? _availableObjects.Dequeue() : Object.Instantiate(_prefab, _parent);
        item.gameObject.SetActive(true);
        return item;
    }

    public void Return(T item)
    {
        item.gameObject.SetActive(false);
        _availableObjects.Enqueue(item);
    }
}

Every track segment, barrier, and power-up is pre-warmed during initial scene setup. During active gameplay, allocations per frame drop to zero bytes.

2. Input Latency Calibration

Touch latency on Android varies wildly across manufacturers due to display refresh rates and touch-polling implementations. In a runner game where a lane switch requires split-second timing, queued touch events caused players to feel like controls were sluggish.

Instead of reading touch inputs in Unity's standard Update() loop with raw delta checks, I migrated the input stack to Unity's modern Input System, consuming tap and swipe events directly from the hardware queue during FixedUpdate() sync phases. This cut perceived input lag significantly on 60Hz panels.

Lessons Learned

Profiling on real low-end hardware is mandatory: Testing on modern Snapdragon processors hides memory leaks and fill-rate limits. Testing on an entry-level MediaTek chip exposed visual bottlenecks in the particle systems within five minutes.
Simplicity beats feature bloat: Trimming complex UI menus and third-party analytics SDKs dropped load times from four seconds to under one second.

Try It Out

If you want a lightweight, distraction-free arcade game for your daily commute, you can download Echo Runner directly on Google Play:

Google Play Store: Download Echo Runner
Web & Info: echorunner.getinfotoyou.com

Feedback on performance across different Android hardware configurations is always welcome in the comments.

How I Built a Markdown Editor for Android That Doesn't Squeeze Out Your Productivity

Getinfo Toyou — Mon, 31 Aug 2026 14:30:36 +0000

Writing documentation, drafting blog posts, or taking structured notes on a phone is generally a frustrating experience. While desktop markdown editors have evolved to offer smooth, distraction-free environments, mobile tools often force you to choose between a clunky text input area or a heavily restricted UI.

As a developer, I frequently get ideas for technical posts or need to update repository readmes while away from my desk. The struggle of manually typing backticks, hashes, and brackets on a standard mobile keyboard—coupled with the lack of instant previews—led me to build AIMarkdownPro Editor.

Here is the story of how I tackled the challenges of mobile markdown editing, the tech stack I chose, and what I learned along the way.

The Main Problem: Mobile Friction

The core issue with editing Markdown on mobile is friction. Keyboards aren’t optimized for syntax symbols, and switching back and forth between edit mode and preview mode breaks your writing flow. Furthermore, standard AI writing assistants often strip away your markdown formatting or return poorly structured blocks that require manual cleanup.

I wanted an app that solved these specific issues:

Quick access to markdown syntax elements.
A live, side-by-side or tabbed preview that renders correctly.
An AI assistant that respects and works directly with Markdown structure.

The Tech Stack

To build a responsive editor, I selected a modern Android stack:

Kotlin: For concise and safe code.
Jetpack Compose: To build a declarative, fluid UI that adapts easily to different screen sizes and orientations.
Markwon / Flexmark (adapted): For parsing and rendering Markdown to rich text in the preview.
Coroutines: To handle parsing and AI generation off the main thread, keeping the UI responsive.

Technical Challenges

Two main challenges arose during development:

1. Real-Time Syntax Highlighting

In Jetpack Compose, the TextField component is powerful but can lag if you attempt heavy parsing on every keystroke. Applying syntax highlighting to the raw editor text in real-time meant writing a highly efficient, incremental parser. I had to throttle the highlighting updates to prevent the keyboard input from stuttering, especially on larger documents.

2. AI Integration that Understands Context

Integrating an AI writer meant teaching the assistant to output raw Markdown that fits seamlessly into the user's document. Instead of replacing the entire text, the AI needs to understand the cursor's location and generate contextually relevant headings, lists, or code blocks. This required carefully structured prompts and parsing the stream of incoming tokens to dynamically update the active editing block.

Lessons Learned

Keep it local first: Relying entirely on cloud APIs can make a mobile app feel sluggish. Keeping as many editing operations local as possible—and streamlining network calls—is crucial for a smooth user experience.
Keyboard accessory bars are essential: Adding a simple helper row above the virtual keyboard for quick symbols like hashes, asterisks, backticks, and brackets reduces the friction of writing Markdown by at least 80%.

Try It Out

If you've ever wanted to write or edit your technical documentation on the go without the usual hassle, you can try AIMarkdownPro Editor. It is available on Google Play. You can also learn more about the project at the AIMarkdownPro website, which is part of my solo developer portfolio at getinfotoyou.com.

I'd love to hear how you handle mobile writing workflows and what features you find most helpful.

Building a High-Performance Batch Image Compressor for Android: Native Bitmap Optimization and Pipeline Challenges

Getinfo Toyou — Wed, 26 Aug 2026 14:30:30 +0000

As a mobile developer, I frequently find myself needing to tweak, resize, or compress image files on the go. While web-based compression tools exist, uploading multi-megapixel source files over cellular data is slow, insecure, and expensive. I wanted a way to process high-resolution photos locally on Android, matching the precision and batch capabilities of desktop software.

This led me to build ImageSlim Pro. Throughout the process, I focused on addressing the specific needs of three groups of people who rely heavily on mobile media processing: content creators, web designers, and field photographers.

Who Benefits Most?

During development, I prioritized features that solve distinct friction points for specific users:

On-the-go Content Creators: When you are uploading to social platforms or publishing articles from the field, bandwidth is precious. Content creators need to reduce file sizes drastically without introducing blocky compression artifacts. By allowing precise control over quality percentage and resolution dials, they can find the sweet spot between visual fidelity and small file sizes.
Mobile Web Designers: Mobile layouts require optimized WebP or PNG assets. Designers using tablets or phones to manage websites can convert and batch-resize assets to exact pixel dimensions, ensuring fast page load speeds for their clients.
Photographers Sharing Drafts: Photographers often need to send quick proofing galleries to clients. Sending raw files is impractical, but using low-quality automated compressors strips away crucial color profiles. ImageSlim Pro preserves EXIF metadata and maintains color integrity while shrinking the file footprint.

The Technical Stack

To keep the application responsive during heavy batches, I chose:

Kotlin & Jetpack Compose: For a lightweight, modern UI.
Kotlin Coroutines & Flow: To manage background processing queues and stream real-time progress updates to the UI.
Android NDK (Native Development Kit): Specifically utilizing native libraries for encoding WebP and JPEG format variations, bypassing some of the higher-overhead Java-level Bitmap APIs.

Overcoming the Memory Bottleneck

The biggest technical hurdle was Android's strict memory management. If a user drops twenty 48-megapixel images into a batch queue, decoding them all into memory simultaneously will instantly trigger an Out Of Memory (OOM) crash.

To solve this, I designed a pipeline that processes images sequentially using a worker queue. Instead of decoding full-resolution bitmaps directly, the app reads the image dimensions first using inJustDecodeBounds = true. Based on the target output dimensions, it calculates the optimal inSampleSize to sub-sample the image during the actual decode phase. This keeps the memory footprint low and predictable, even when processing dozens of files.

Lessons Learned

Building this app taught me a lot about garbage collection (GC) churn. In early iterations, allocating new byte arrays for every image compression operation caused frequent GC pauses, leading to visible UI stuttering despite using background threads. Transitioning to a reusable byte buffer pool resolved the issue, smoothing out the performance.

Additionally, I learned the importance of preserving metadata. Stripping EXIF data is easy, but keeping it intact while rebuilding the image structure requires carefully parsing and writing the JPEG APP1 segments.

Give it a Try

If you are a photographer, designer, or creator looking for a clean, local-first tool to handle your mobile image processing, you can try the app on the Google Play Store or read more about the project at imageslim.getinfotoyou.com. You can also view my other projects at getinfotoyou.com. I would love to hear your feedback on the processing pipeline or any features you would like to see added.

How I Built a Zero-Network Android Image Compressor to Solve the 10MB Photo Problem

Getinfo Toyou — Mon, 24 Aug 2026 14:30:35 +0000

Modern phone cameras are incredible, but they have a massive side effect: file size. A single photo taken on a mid-range Android phone can easily range from 6MB to 15MB. While that detail is great for printing posters, it is complete overkill for sharing on chat apps, uploading to a blog, or storing on your phone.

As my device storage filled up and my cloud storage warnings started popping up, I realized I needed a quick way to shrink my photos. I looked at web-based tools, but I didn't feel comfortable uploading private family photos to random servers just to resize them. I looked at existing apps, but they were bloated with ads, trackers, and demanded internet access.

So, I decided to build ImageSlim Free, an offline-first Android app designed to solve this exact problem: shrinking image file sizes by up to 90% without sacrificing visible quality.

Here is how I built it, the technical hurdles I faced, and what I learned along the way.

The Core Problem: Mobile Storage and Bandwidth Bloat

When you share a 10MB photo over a weak mobile connection, it takes forever. If you run a self-hosted blog, uploading multiple 10MB images destroys your page load speeds and hikes up your hosting bills. The core value of ImageSlim is simple: let users select one or multiple images, scale them down, compress the bytes, and save them—all in a few seconds, and entirely on-device.

Technical Challenges of On-Device Processing

Processing high-resolution images on Android is notoriously difficult due to memory limitations.

The OutOfMemory (OOM) Trap: If you load a 108 megapixel photo directly into Android's memory as a Bitmap, it can require hundreds of megabytes of RAM. Android will instantly kill your app process if you exceed the heap limit.
UI Thread Blocking: Image compression is CPU-intensive. Running it on the main thread freezes the user interface, causing the system to throw an "Application Not Responding" (ANR) dialog.

To tackle the OOM issue, I used sub-sampling. Instead of loading the full-resolution image into memory just to resize it, I used BitmapFactory.Options with inJustDecodeBounds = true to query the image dimensions first. Once I knew the original size, I calculated an appropriate inSampleSize to decode a downscaled version directly into memory, dramatically reducing the RAM footprint.

To keep the app responsive, I wrapped the entire compression workflow inside Kotlin Coroutines, specifically utilizing Dispatchers.Default for CPU-bound tasks. This keeps the UI buttery smooth even when processing a batch of images.

The Tech Stack

I wanted the project to be lightweight and modern:

Language: Kotlin
UI Framework: Jetpack Compose. This allowed me to build a clean, minimal interface without the boilerplate of XML layouts.
Concurrency: Kotlin Coroutines and Flow to manage background processing states.
Graphics Pipeline: Native Android Graphics libraries (android.graphics.Bitmap), utilizing JPEG/WEBP compression algorithms.

Lessons Learned

Building this app taught me a lot about native memory management. Unlike Java objects, Bitmaps in older Android versions allocated memory in the native heap, but even in modern versions, garbage collection behavior can be unpredictable during heavy image manipulation. Explicitly calling bitmap.recycle() and ensuring references are cleared as soon as the file is written made a massive difference in stability.

Additionally, I learned that restricting your app's capabilities can actually be a feature. By choosing not to request the Internet permission (android.permission.INTERNET) in the manifest, I made it impossible for the app to send data anywhere. This built immediate trust with privacy-conscious users.

Try It Out

If you're tired of running out of phone space or waiting for photo uploads to finish, you can download ImageSlim Free on Google Play.

For more details on the project and other tools, feel free to check out the portfolio page at imageslim.getinfotoyou.com. Let me know your thoughts or if you have any questions about the implementation!

Why I Built an Offline-First Android App to Manage My AI Prompts

Getinfo Toyou — Wed, 19 Aug 2026 14:30:25 +0000

As developers, we are constantly switching contexts. On any given day, we might be jump-starting a new project, writing tests, or debugging legacy code. Over the last couple of years, large language models (LLMs) like ChatGPT, Claude, and Gemini have become core parts of my daily coding and documentation workflow. But as my usage grew, I noticed a frustrating bottleneck: prompt management.

The Problem: Where Did I Put That Prompt?

I started with a fragmented setup. I had a markdown file on my desktop for coding prompts, a note-taking app on my phone for writing prompts, and a few drafts saved in my email. Whenever I needed a specific prompt that had worked perfectly a week ago, I had to search through multiple apps, copy the text, tweak the variables, and paste it into the browser.

This process was inefficient. I wanted a single, dedicated library on my mobile device—something I could access instantly, search through, and copy from with a single tap. Since I couldn't find a lightweight, privacy-focused solution that fit my needs without unnecessary complexity, I decided to build one myself: AI Prompt Vault.

Choosing the Tech Stack

Since speed and privacy were my top priorities, I chose a modern, native Android tech stack:

Language: Kotlin, because of its safety features and concise syntax.
UI Framework: Jetpack Compose. Building UIs declaratively allowed me to quickly prototype the interface and handle dynamic states (like search queries and category filters) cleanly.
Local Database: Room Database. I wanted the app to be completely offline-first. Your prompts should remain your own data, stored locally on your device.
Dependency Injection: Hilt, to keep the codebase clean, modular, and testable.

Technical Challenges

Building a simple utility app doesn't mean there aren't interesting engineering challenges. Three aspects stood out during development:

1. Instant Full-Text Search

When you have dozens of prompts, scrolling is too slow. I needed instant search that matches terms in both the prompt title and the body. To achieve this without relying on a backend server, I integrated SQLite's FTS4 (Full-Text Search) module via Room.

Setting up the virtual FTS table required mapping the database entities correctly to ensure search queries were executed in milliseconds. The result is a highly responsive search bar that filters your prompt library as you type.

2. State Management and MVI

In Jetpack Compose, managing UI state across configuration changes (like screen rotation) can get tricky, especially when dealing with active search queries, category selections, and list states. I adopted a Model-View-Intent (MVI) architecture. By exposing a single immutable state flow from the ViewModel, the UI remains predictable. When a user selects a category, it triggers an action that updates the state, which in turn recalculates the filtered list via Room's Flow integration. This means the database is the single source of truth, and the UI reacts instantly to any changes.

3. Clean Clipboard Integration

The core user action in the app is copying a prompt to the clipboard. Android handles clipboard access via the ClipboardManager. However, ensuring a seamless user experience across different Android versions (especially with the clipboard overlay introduced in Android 13) meant I had to carefully handle background threads and system notifications. I implemented a simple one-tap copy gesture that updates the clipboard and gives subtle haptic feedback to confirm the action.

Lessons Learned

Building AI Prompt Vault taught me a valuable lesson in product scope. Initially, I wanted to build a cloud sync feature. I planned to use Firebase, set up user authentication, and synchronize prompts across multiple devices.

But as I talked to potential users (and looked at my own habits), I realized that a cloud database introduced unnecessary friction. Users didn't want to create another account just to store prompts. They valued privacy and speed. By stripping away the cloud synchronization and focusing entirely on a fast, local SQLite database, I delivered a more secure and responsive product.

I also realized how important it is to design for variable inputs. Often, a prompt is not static—it has placeholders (e.g., [Insert code here]). Handling dynamic variables within a local database and presenting them in a clean UI is a feature I'm actively refining.

Try It Out

If you find yourself copying and pasting the same instructions into LLMs or losing track of your best prompts, you can download AI Prompt Vault on Google Play:

AI Prompt Vault on Google Play Store

It is a simple, practical utility designed to make your daily AI interactions a little more productive. I would love to hear your feedback on how you manage your prompts and what features you would find useful.