まおちゃんず | #iOS | #Android Fashion News

Checking Your Cable Specs: The Secret Lies in the Wires

Last updated : 2025-11-08 06:03

When connecting your smartphone or development device to your computer, have you ever thought,

“Why is the transfer so slow?” or “Why am I getting connection warnings?”

One often overlooked cause is the cable’s specifications. Even if two USB cables look identical, their internal structure and supported standards can make a huge difference.

This time, I tried using a USB cable tester to see how we can easily check a cable’s actual specs.

🤔 What You Can Learn with the Treedix USB Cable Tester

The tool I used is the Treedix USB Cable Tester Board, which supports multiple connector types such as USB-A, Type-C, and Micro-B.
It can test both data transfer and charging performance — a very handy little board.

👉 Treedix USB ケーブルテスターボード USB ケーブルチェッカーデータワイヤ充電テストデータラインタイプ C – Treedix Official

👉 TREEDIX USB Cable Tester Manual - Test USB Cables for Charging and Data Transfer

According to its manual, if the LEDs for “High-Speed Charging” and “High-Speed Data” light up, it means the cable supports USB 3.x.

If they don’t light up, the cable is only USB 2.0 level.

In short, this tiny board lets you instantly “see” the invisible differences inside your cables.

🤔 Test Results: USB 2.0 vs USB 3.x

First, I tested the cable I had been using regularly — and it turned out to be USB 2.0.
Apparently, it was almost a charging-only cable with no proper data lines.

Next, I tested a recently purchased Buffalo cable. This time, the USB 3.x indicators lit up clearly, confirming that it supports high-speed data transfer.

When I switched to this cable for connecting my Android device to Android Studio, the connection warnings disappeared completely — the link became much more stable.

👉 Amazon.co.jp: バッファロー BUFFALO USB3.1 Gen2ケーブル(C to C) PD3A 1.0m ブラック【 iPhone 17 / 17 pro 動作確認済み】 BSUCC312P3A10BK : パソコン・周辺機器

However, I didn’t feel much difference in actual transfer speed, suggesting that other factors (like device or build performance) may be the real bottleneck.

🤔 Conclusion: Visualize Your Cables for Peace of Mind

A USB cable isn’t “just a wire.”

Its performance depends on which internal signal lines are actually connected.

Using a cable tester lets you easily determine whether your cable is charging-only, data-transfer capable, or high-speed compatible.

Especially for developers or anyone who needs a reliable connection, it’s worth testing your cables at least once.

Once you understand what’s inside, you’ll choose better cables and avoid unnecessary frustration in the future.

👉 実機デバッグで出る「Connection speed warning」とは ⚡

“Install Error(-10)” Got You Stuck? The Hidden Trick to Beat Google Play’s Pre-launch Test

Last updated : 2025-11-02 11:12

🤔 Why the “App Not Owned” Error Happens

If your app fails the Google Play Pre-launch Test with this scary message —

u9.a: -10: Install Error(-10): The app is not owned by any user on this device.
An app is "owned" if it has been acquired from Play.

— you’re not alone.

This happens because the Pre-launch Test runs on Google’s own test devices, which aren’t linked to your Play account or purchase history.
So, if your app uses Play Core libraries (like AppUpdateManager or AppReviewManager), the “ownership check” fails, and your app never even gets installed.

It’s one of those bugs that make you scream: “But it works fine on my phone!” 😩

🤔 The Secret Fix Google Never Told You

Here’s the insider trick that devs have quietly been using:


Settings.System.getString(context.contentResolver, "firebase.test.lab")

This line reveals whether your app is currently running inside Firebase Test Lab — the same environment used for Pre-launch Tests.
If the value is "true", you’re in a test device.
That means you can safely skip anything that requires Play services or user ownership checks.

Here’s how to use it:


val isTestLab = Settings.System.getString(context.contentResolver, "firebase.test.lab") == "true"
if (!isTestLab) {
    // Run Play Core logic only in real user environments
}

Boom. 💣
No more random -10 install errors.
Your Pre-launch Test will finally pass like a charm.

⚡ Summary

The “Install Error(-10)” is not a bug in your code — it’s a Play Console quirk.
By detecting the Test Lab environment with:


Settings.System.getString(context.contentResolver, "firebase.test.lab")

you can bypass Play-related ownership checks and let your app install smoothly during the Pre-launch Test.

A single line of code could be the difference between “Test failed 🚫” and “Release ready ✅” — now that’s a win worth sharing.

👉 Firebase Test Lab × リリース前レポート環境を見分けるKotlin実装

Activity x Compose Lifecycle: The Complete Visual Guide 🚀

Last updated : 2025-10-31 16:57

👨‍💻 Activity Lifecycle


Activity.onCreate() <- Activity is created

↓

Activity.onStart() <- Preparing to become visible on screen

↓

Activity.onResume() <- Foreground state (interactive)

↓

Activity.onPause() <- Partially visible

↓

Activity.onStop() <- No longer visible

↓

Activity.onDestroy() <- Activity is destroyed

👨‍💻 Compose Lifecycle


[First Composition]
  - Composable is evaluated, Compose tree is built
  - LaunchedEffect -> Runs once after the commit
  - SideEffect -> Runs after every commit
  - DisposableEffect -> onDispose is called upon disposal

↓

[Recomposition]
  - UI is re-evaluated in response to state or data changes
  - Only the necessary parts are recomposed (efficient update)
  - SideEffect and DisposableEffect are also re-evaluated during recomposition

↓

[Dispose]
  - Depends on the ComposeView's disposal condition
  - DisposableEffect's onDispose is executed
  - Disposal timing is determined by the ViewCompositionStrategy

👨‍💻 Activity x Compose Lifecycle


Activity.onCreate() setContent { ... } <- Sets the ComposeView

↓

[First Composition]
  - Evaluates Composables and builds the UI
  - LaunchedEffect -> Runs once after commit
  - SideEffect -> Runs after each commit
  - DisposableEffect -> Defines onDispose

↓

Activity.onStart()

↓

Activity.onResume()

↓

[Recomposition]
  - Re-evaluates necessary parts in response to state changes
  - LaunchedEffect is not re-executed (only if its key changes)
  - SideEffect / DisposableEffect are re-evaluated

↓

Activity.onPause()

↓

(ComposeView is retained)
  - UI becomes partially obscured
  - State is maintained within the Composition

↓

Activity.onStop()

↓

[Preparing for Dispose (Detection)]
  - ViewCompositionStrategy monitors disposal conditions

↓

Activity.onDestroy()

↓

[Dispose]
  - ComposeView is destroyed
  - DisposableEffect.onDispose() is executed

This is the general flow.

Here are the notes for each item:

Activity.onCreate() A lifecycle method called when an Android app's Activity is created.

setContent { ... }

First Composition The Composable functions set in setContent are evaluated for the first time, and the UI is built.

LaunchedEffect: An Effect used for asynchronous processing. Runs only once after the first composition.

SideEffect: Runs after every composition commit (the timing when UI changes are applied).

DisposableEffect: An Effect used for resource cleanup. The logic defined in onDispose is executed when the Composition is disposed.

Activity.onStart() A lifecycle method called just before the Activity becomes visible to the user.

Activity.onResume() The Activity moves to the foreground and becomes fully interactive with the user.

Recomposition Only the necessary Composable functions are re-evaluated in response to changes in State.

LaunchedEffect: It is not re-executed during recomposition. However, it will be re-executed if its key changes.

SideEffect: It is re-evaluated on every recomposition.

DisposableEffect: It is re-evaluated on recomposition, and the cleanup logic (onDispose) from the old Effect is called.

Activity.onPause() The Activity enters a paused state and becomes partially obscured.

ComposeView Retention: The UI is not destroyed; it is retained. The state is also maintained within the Composition, allowing it to be reused upon re-display.

Activity.onStop() The Activity is no longer visible. A time to prepare for cleaning up state and resources.

Preparing for Dispose (Detection) ViewCompositionStrategy: A mechanism that monitors the conditions under which the ComposeView should be disposed. It triggers the Composition's disposal based on the View's lifecycle.

Activity.onDestroy() The timing when the Activity is completely destroyed.

Dispose The ComposeView is destroyed: The UI and state are completely released.
DisposableEffect.onDispose(): The resource cleanup logic is called.

👨‍💻 Summary

The Jetpack Compose and Activity lifecycles are closely linked, with specific processes occurring at each stage, from UI initialization (setContent) to disposal (Dispose).

It is especially important to understand the differences between effects like LaunchedEffect, SideEffect, and DisposableEffect, and to manage them appropriately.

Furthermore, by efficiently reusing the UI in response to Activity state changes (like onResume or onPause) and cleaning up resources as needed, you can achieve stable application behavior.

初回コンポーズは Activity.onStart() までに終わる

Last updated : 2025-10-30 19:11

🤔 Activity x Compose のライフサイクル


Activity.onCreate()
  setContent { ... }   ← ComposeView をセット

    ↓

  ［初回コンポーズ（First Composition）］
    ・Composable を評価し UI を構築
    ・LaunchedEffect → コミット後に一度実行
    ・SideEffect → 各コミットごとに実行
    ・DisposableEffect → onDispose 定義

    ↓

Activity.onStart()

    ↓

Activity.onResume()

    ↓

  ［再コンポーズ（Recomposition）］  
    ・状態変更に応じて必要部分のみ再評価
    ・LaunchedEffect は再実行されない（Key 変更時のみ）
    ・SideEffect / DisposableEffect は再評価

    ↓

Activity.onPause()

    ↓

  （ComposeView は保持）
    ・UI は部分的に見えなくなる
    ・状態は Composition 内で維持

    ↓

Activity.onStop() 

    ↓

  ［破棄準備（Dispose 検知）］
    ・ViewCompositionStrategy による破棄条件監視

    ↓

Activity.onDestroy()

    ↓

  ［破棄（Dispose）］
    ・ComposeView が破棄される
    ・DisposableEffect.onDispose() 実行

🤔 まとめ

初回コンポーズは Activity.onStart() までに終わる。

👉 これだけでわかる！Activity × Compose のライフサイクル完全図解 🚀

IDE × AIモデル別：プロンプトに食わせるべきファイルまとめ

Last updated : 2025-10-28 22:24

主要IDEごとに、連携AI・推奨ファイル・目的・補足を整理した表です。プログラミング中心にまとめています。

1. 基本のセット

プロジェクト概要・設計
README.md, architecture.md
AIに全体像・設計方針・責務を理解させる
依存・環境情報
build.gradle(.kts), package.json, Podfile, .env.example
SDK・ライブラリ・環境変数を正確に認識させる
コーディング方針・ルール
.prompt.yaml, .copilot-instructions.md, .editorconfig
命名規則、禁止API、コードスタイルを統一

2. IDE × AIモデル別の推奨ファイルと効果

IDE	推奨AIモデル	重点ファイル	効果	補足
Android Studio / IntelliJ	Gemini Code Assist, Copilot	.prompt.yaml, build.gradle, architecture.md	Androidプロジェクト全体を理解した補完・設計提案	プロジェクト全体の構造を解析可能。方針ファイルで安定化。
Xcode	Copilot, GPT-5	.prompt.yaml, Package.swift, README.md	SwiftUI/MVVM設計に沿った正確なコード生成	Xcodeは依存解析が弱めなので .prompt.yaml を明示すると効果大。
VS Code	Copilot Chat, GPT-5	.copilot-instructions.md, package.json, README.md	軽量環境で多言語対応、チーム開発の方針共有に有効	拡張機能単位でAI切替可能。指示ファイルが最重要。
Cursor / Windsurf / Aider	GPT-5 / Claude 3.5 / Gemini 1.5	.prompt.yaml / .cursorconfig, README.md, architecture.md, build設定	設計・生成・リファクタを自動で分担	ファイル単位でAIが文脈キャッシュを保持。設計書参照可。
Jupyter / DataSpell / VSCode + Python	GPT-4 Turbo, Gemini Advanced	.ipynb / .csv / .xlsx, analysis.md / README.md, .prompt.yaml	データ解析・統計・グラフ生成	データ＋分析目的＋出力形式を渡すと的確に解析可能。
Figma / Webflow / Framer	Gemini 1.5 Pro (Vision), GPT-5 Vision	.fig / .svg / layout.json, style_reference.jpg, .prompt.yaml	UIデザイン→コード変換・スタイル抽出	構図＋目的＋出力フォーマット指定でSwiftUIやComposeコード化が容易。