<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>react-native on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/ja/tags/react-native/</link><description>Recent content in react-native on Ikoma's Blog</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Wed, 30 Sep 2026 11:33:30 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/ja/tags/react-native/index.xml" rel="self" type="application/rss+xml"/><item><title>Expo の fingerprint ランタイムバージョンは、JavaScript ではなく extra の編集で変わる</title><link>https://blog.yusukeikoma.com/ja/posts/fingerprint-runtime-version-changes-when-you-edit-extra/</link><pubDate>Wed, 30 Sep 2026 11:33:30 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/fingerprint-runtime-version-changes-when-you-edit-extra/</guid><description>OTA アップデートは、変更できないネイティブのバイナリを呼び出す JavaScript です。ランタイムバージョンは、そのバイナリの ABI バージョンだと考えられます。@expo/fingerprint 0.20.13 を使った実験で、どの編集がハッシュを変え(extra、version、ビルド番号、ネイティブモジュール)、どれが変えないか(JavaScript、純 JS の依存)を確かめ、既定値を黙って落とすスキップリストの落とし穴も見ます。</description></item><item><title>React Native 標準の URL は '../x' を解決しない</title><link>https://blog.yusukeikoma.com/ja/posts/react-native-builtin-url-does-not-resolve-dot-dot/</link><pubDate>Sat, 26 Sep 2026 21:31:14 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/react-native-builtin-url-does-not-resolve-dot-dot/</guid><description>ウェブサイトと React Native アプリで共有するクライアントライブラリが壊れるのは、fetch ではなく、Web プラットフォームの地味な部分であることが多いです。React Native 0.87.1 と Expo 57 のソースを読むと、ランタイムが3層あること、ウェブなら &amp;lsquo;/b/x&amp;rsquo; になるところを &amp;lsquo;/b/c/d/../x&amp;rsquo; と返す URL クラスがあること、Expo が置き換えない限り fetch にレスポンスのストリームがないことが分かります。必要なものを確認する小さなクライアントを、4つの模擬ランタイムでテストします。</description></item><item><title>バックグラウンドから戻ったWebSocketのOPENは、確かめるまで主張にすぎない</title><link>https://blog.yusukeikoma.com/ja/posts/mobile-os-background-sockets/</link><pubDate>Sat, 12 Sep 2026 14:18:24 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/mobile-os-background-sockets/</guid><description>AppleとAndroidの公式ドキュメントには、バックグラウンドのアプリは一時停止され、ネットワークが止められ、既存の接続が閉じられうると書かれています。つまり、フォアグラウンドに戻ったときの readyState === OPEN は、最後に処理したイベントの記憶にすぎません。この記事では、その記述から「確認する、作り直す、取りこぼしを取り戻す」という小さなルーチンを導き、Linux上の凍結プロセスという代役で動かします。実機では試していない点も、はっきり書きます。</description></item><item><title>ポーリングを変更通知の購読に置き換え、保険として残す</title><link>https://blog.yusukeikoma.com/ja/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/</link><pubDate>Thu, 20 Aug 2026 18:03:49 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/</guid><description>メッセージ単位で課金されるリレー越しに、モバイルクライアントがタイマー駆動のポーリングから共有の変更通知へ移った経緯を扱います。難しいのはストリームそのものではなく、保険のポーリングをいつ止めてよいかを正直に決めることです。</description></item><item><title>close イベントが来ないとき</title><link>https://blog.yusukeikoma.com/ja/posts/when-the-close-event-never-comes/</link><pubDate>Mon, 17 Aug 2026 17:27:04 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/when-the-close-event-never-comes/</guid><description>自分のソケットの close イベントを待ってから後始末するクライアントは、そのイベントが届かないと、黙って止まることがあります。接続を終えると決めた時点で状態を確定させ、後始末を冪等にし、イベントは自分が始めていない切断のために残します。</description></item></channel></rss>