Errong Leng | Faith & Code — Reflections on Scripture and Software

React Native TTS iOS 问题全解析：修复 BOOL 错误与事件监听失效（2026 实战指南） 在 React Native 中使用文本转语音（TTS）本来很简单，但在 iOS 上却可能踩坑。 本文总结了两个非常常见但又很隐蔽的问题，并提供经过验证的解决方案。 🧨 问题一：Objective-C type BOOL is unsupported 错误信息 TextToSpeech.setDefaultRate(): Error while converting JavaScript argument to Objective C type BOOL convert javascript argument to object C type Bool object C type bool is unsupported 🔍 根本原因 这 不是你的代码问题 。 这是由于 iOS 原生桥接层（Objective-C）类型定义错误导致的，尤其在 React Native 新架构（Fabric / TurboModules）下更容易触发。 部分版本的 react-native-tts 错误地使用了： (BOOL *)onWordBoundary ❌ 错误 而 React Native bridge 不支持 BOOL 指针类型 ，只支持： BOOL NSNumber * ✅ 解决方案 https://github.com/ak1394/react-native-tts/issues/291 使用已修复的 fork 版本： @iternio/react-native-tts npm install @iternio/react-native-tts 该版本已修复 iOS 类型问题，可以正常运行。 ⚠️ 问题二：事件监听器未注册 警告信息 Sending `tts-start` with no listeners registered. 即使你已经写了监听： Tts.addEventListener('tts-start', () => { setIsSpeaking(true); }); 🔍 根本原因 问题在于： ...

  React Native TTS on iOS — Fixing “Objective-C BOOL Unsupported” and Missing Event Listeners Working with text-to-speech in React Native should be simple — until you hit iOS. Recently, I ran into two frustrating issues using   react-native-tts   on iOS. After digging through GitHub issues and debugging native code, here are the   root causes and fixes . 🧨 Issue 1: Objective-C type BOOL is unsupported Error TextToSpeech.setDefaultRate(): Error while converting JavaScript argument to Objective C type BOOL or convert javascript argument to object C type Bool object C type bool is unsupported 🔍 Root Cause This is   not your code . It’s caused by a   type mismatch in the iOS native bridge , especially under the new React Native architecture (Fabric / TurboModules). Some versions of   react-native-tts   incorrectly define Objective-C method parameters like: (BOOL *)onWordBoundary // ❌ incorrect React Native   does NOT support   BOOL * ...

解决 React Native iOS 缺少 iPad 图标错误（152x152 / 167x167） 在提交 React Native iOS 应用到 App Store 时，如果你遇到类似错误： Missing required icon file. The bundle does not contain an app icon for iPad of exactly '152x152' pixels The bundle does not contain an app icon for iPad Pro of exactly '167x167' pixels 这个问题看起来很奇怪，因为你的 Xcode 项目中已经显示支持 iPad。 🔍 现象 你可能已经看到： Deployment Info 中有 iPad 配置 iPad Orientation 已启用 但是打开 Assets.xcassets → AppIcon 时： ❌ 没有 iPad 图标槽位 最终导致 App Store 校验失败。 🧠 根本原因 这是因为配置不一致导致的： 项目设置支持 iPad ✅ AppIcon 资源仍然是 iPhone-only ❌ 在很多 React Native 项目中，默认生成的 AppIcon 并不包含 iPad 图标槽位。 ✅ 解决方案（最简单有效） 重新创建 AppIcon： 打开 Assets.xcassets 删除当前的 AppIcon 右键 → New App Icon 命名为 AppIcon 新的 AppIcon 会自动包含： iPad 图标（152x152） iPad Pro 图标（167x167） 🖼️ 必须提供的图标 你至少需要提供： 152 × 152（iPad） 167 × 167（iPad Pro） 将对应 PNG 图片拖入即可。 ⚠️ 重要检查 确保项目确实支持 iPad： Build Settings → Targeted Device Family = 1,2 含义： 1 = iPhone 2 ...

Fix Missing iPad App Icon in React Native iOS (Xcode Validation Error) If you're submitting a React Native iOS app and encounter errors like: Missing required icon file. The bundle does not contain an app icon for iPad of exactly '152x152' pixels The bundle does not contain an app icon for iPad Pro of exactly '167x167' pixels This issue can be confusing — especially when your project already shows iPad support in Xcode. 🔍 The Confusing Part In Xcode, you may already see: iPad orientation settings enabled Deployment Info showing iPhone + iPad However, when opening Assets.xcassets → AppIcon , there are no iPad icon slots . This leads to App Store validation failure. 🧠 Root Cause This is caused by a mismatch between: Xcode project settings (which support iPad) Asset catalog configuration (which may still be iPhone-only) In many React Native projects, the default AppIcon set is created without iPad slots, even when the app later ...

解决 Xcode 报错：Sandbox rsync “Operation not permitted”（React Native / CocoaPods） 在使用 React Native 开发 iOS 应用时，如果你在 Xcode 中遇到类似如下错误： Sandbox: rsync deny(1) file-read-data Operation not permitted PhaseScriptExecution [CP] Embed Pods Frameworks 那么你踩到了 Xcode 15+ 中一个非常常见的坑。 🔍 问题原因 Xcode 15 引入了更严格的安全机制 —— User Script Sandboxing（用户脚本沙箱） 。 这个机制会限制构建过程中脚本的文件访问权限，而 CocoaPods 在编译时会执行一个脚本（Embed Pods Frameworks），使用 rsync 来复制 framework： ❌ 无法读取 framework 文件（如 React.framework） ❌ 无法写入 app bundle 最终导致 Operation not permitted 错误。 ✅ 解决方案（最有效） 关闭 Xcode 的 User Script Sandboxing ： 打开 Xcode 选择你的 Project（不是 Target） 进入 Build Settings 搜索： User Script Sandboxing 将其设置为： NO 然后执行清理并重新编译： Shift + Command + K 通常问题会立刻解决。 💡 原理说明 关闭脚本沙箱后，CocoaPods 的构建脚本将可以正常执行： 读取 framework 文件 复制到应用目录 保留签名信息（CodeSignature） ⚠️ 如果仍然报错（补充方案） 可以尝试以下操作： 给 Xcode 添加 Full Disk Access（完整磁盘权限） 删除 DerivedData 目录 重新执行 pod install 🚀 总结 这个问题并不是你的项目配置错误，而是： Xcode ...

Fix Xcode Sandbox rsync “Operation not permitted” Error (React Native / CocoaPods) If you are building a React Native iOS app and suddenly see errors like: Sandbox: rsync deny(1) file-read-data Operation not permitted PhaseScriptExecution [CP] Embed Pods Frameworks You are not alone. This issue is very common in Xcode 15+ due to stricter sandboxing rules. 🔍 Root Cause Xcode introduced User Script Sandboxing , which restricts scripts (like CocoaPods' framework embedding step) from accessing certain files. During build, rsync is used to copy frameworks (e.g. React.framework), but the sandbox blocks it: ❌ Cannot read framework files ❌ Cannot write into app bundle This results in the infamous Operation not permitted error. ✅ Solution (Works Instantly) Disable User Script Sandboxing in Xcode: Open your project in Xcode Select the project (not target) Go to Build Settings Search for: User Script Sandboxing Set it to: NO Then clean and r...

  不要错过耶稣 听完这篇讲道，我一直在想一件事：人真的很容易看错、甚至认不出耶稣是谁。 一开始提到 Joshua Bell 在地铁里拉小提琴的例子让我很有感触。一个这么厉害的音乐家就在眼前，大家却匆匆走过，没有人真正停下来欣赏。其实，当年的耶稣也是这样——祂就在人的中间，但很多人却没有认出祂。 在 Good Friday 那一天，耶稣被嘲笑、被鞭打、被钉在十字架上。从人的角度看，这完全像是一个失败者的结局。如果我当时在场，我会怎么想？我真的会相信祂是神的儿子吗？还是也会怀疑？ 可是后来发生的事情很不一样——幔子裂开，地震，甚至坟墓也开了。感觉就像神在说：“你们要看清楚，这不是普通的一件事。” 让我最触动的是那个百夫长。他不是门徒，也不是犹太人，但他看见这些事之后，却说：“这真是神的儿子。” 这让我反思自己：我平时也会说“耶稣是神的儿子”，但我真的打从心里相信吗？ 因为如果耶稣真的是神的儿子，那一切都不一样了。祂的死就不是白白的，而是为我们；我们也真的可以来到神面前；甚至连死亡也不再是最后的结局。 对我来说，这篇讲道最大的提醒就是： 不要错过耶稣。 祂其实没有隐藏，只是我常常没有认真去看、去认识祂。就像当时的人一样，离祂很近，却还是没有真正认识祂。 所以我现在的祷告很简单： 主啊，求你让我真的看见你是谁，也让我不只是口里承认，而是心里真实地相信。

Don't Miss Jesus Listening to this sermon really made me think about how easy it is to misunderstand who Jesus is. The example at the beginning about   Joshua Bell   playing in a subway really stuck with me. Someone incredibly valuable can be right in front of us, and we still miss it. That’s kind of what happened with Jesus. People saw Him, heard Him, even watched Him die—and still didn’t recognize Him. At the cross, everything looked like failure. On   Good Friday , Jesus was mocked, beaten, and crucified like a criminal. If I were there, I wonder what I would have thought. Would I have believed He was really the Son of God? Or would I have doubted too? But then the signs happen—the curtain tearing, the earth shaking, even the tombs opening. It’s like God is saying, “Look carefully. This is not just another death.” And what really struck me most is the centurion. He wasn’t a disciple. He wasn’t even a Jew. Yet after seeing everything, he says, “Truly this was the Son o...

从困惑到盼望 复活节的故事，其实很真实。 那些跟随耶稣的人，一开始并没有马上明白发生了什么。妇女是困惑的，彼得也是不确定的，一切都不像他们原本所想的那样。 我发现，这和我自己的经历很像。 很多时候，我并不明白神在做什么。事情的发展常常出乎我的意料，让人困惑，甚至有点失望。 但让我印象很深的是，天使给出的解释其实很简单：“他不在这里，已经复活了。” 他们没有长篇大论地证明什么，只是提醒人去记得耶稣曾经说过的话。 这让我明白，信心有时候并不是把一切都想明白，而是选择相信神已经说过的话。 彼得的反应也让我很有感触。虽然他曾经否认主，但当他听到消息时，他还是跑去看。他没有逃避，而是朝着耶稣走去。 这给了我很大的安慰。 因为复活意味着：过去可以被赦免，现在可以得自由，将来充满盼望。 我也许还不完全明白，但我可以像彼得一样，继续向前，带着一点点的信心，相信神正在做更大的事。 从困惑到盼望，这正是复活节带给我们的旅程。

From Confusion to Joy One thing that stood out to me in the Easter story is how real it feels. The women were confused. Peter was unsure. No one fully understood what was happening at first. And honestly, that’s where I often find myself too. There are many moments in life when I don’t fully understand what God is doing. Things don’t always make sense. Like the disciples, I try to put the pieces together, but they don’t seem to fit. But what struck me was this: the answer wasn’t complicated. The angels didn’t give a long explanation. They simply reminded them of what Jesus had already said. “He is not here. He has risen.” Sometimes, faith is just that simple. Not having every answer, but choosing to trust what God has already spoken. I was also really encouraged by Peter. Even after denying Jesus, he still ran to the tomb. He didn’t hide. He didn’t give up. He ran toward the possibility that something new had happened. That gives me hope. Because the resurrection ...

我们如何为 macOS 应用添加国际化和多语言支持 支持多语言对于拓展全球用户至关重要。本文将以我们的 macOS 应用 iTrans 为例，介绍我们如何通过 Swift 和 Xcode 实现国际化（i18n）和中文本地化。 1. 审查所有用户可见文本 第一步是查找代码中所有用户可见的字符串。我们在 SwiftUI 视图、模型和操作符中搜索所有硬编码文本。 2. 提取待本地化字符串 我们将所有硬编码字符串替换为支持本地化的 API： 在 SwiftUI 中， Text 视图使用 LocalizedStringKey 。 其他字符串使用 NSLocalizedString 。 Text(LocalizedStringKey("Unlock your iPhone")) // 或 NSLocalizedString("Untitled", comment: "File with no name") 3. 创建本地化文件 我们为每种支持的语言创建了 Localizable.strings 文件： en.lproj/Localizable.strings —— 英文 zh-Hans.lproj/Localizable.strings —— 简体中文 每个文件都包含所有用户可见文本的键值对。 英文示例： "Unlock your iPhone" = "Unlock your iPhone"; 中文示例： "Unlock your iPhone" = "解锁你的 iPhone"; 4. 将本地化文件添加到 Xcode 工程 为了让 Xcode 识别本地化文件： 我们通过项目导航器将 Localizable.strings 文件添加到工程。 在文件检查器中，启用本地化并勾选所有支持的语言。 5. 测试本地化效果 Xcode 让我们可以轻松测试不同语言下的应用效果： 在 Scheme 编辑器中，将应用语言设置为“简体中文”并运行应用。 我们还验证了所有界面文本在英文和中文下都能正确显示。 6. ...

How We Added Internationalization and Multi-Language Support to Our macOS App   Supporting multiple languages is essential for reaching a global audience. In this post, we’ll walk through how we added internationalization (i18n) and Chinese localization to our macOS app, iTrans , using Swift and Xcode. 1. Audit All User-Facing Text The first step was to identify all user-facing strings in our codebase. We searched through our SwiftUI views, models, and operators for any hardcoded text that would be visible to users. 2. Extract Strings for Localization We replaced all hardcoded strings with localization-friendly APIs: For SwiftUI, we used LocalizedStringKey in Text views. For other strings, we used NSLocalizedString . Text(LocalizedStringKey("Unlock your iPhone")) // or NSLocalizedString("Untitled", comment: "File with no name") 3. Create Localization Files We created Localizable.strings files for each supported language: en.l...

如何在本地搭建 React Native iOS 开发环境 在本地搭建 React Native iOS 项目听起来很简单，但实际操作中常会遇到问题：Ruby 版本不兼容、CocoaPods 安装失败、Xcode 配置不当，甚至神秘的构建错误。下面是一个真实可行的完整环境搭建流程。 🍎 步骤 0 — 准备 Xcode（关键但容易忽略） 即便你已经从 App Store 安装了 Xcode ，系统可能还没有完全配置好命令行工具。我在遇到问题后，完成了以下步骤才顺利运行： 1. 选择正确的 Xcode 路径 sudo xcode-select -s /Applications/Xcode.app/Contents/Developer xcode-select -p 预期输出： /Applications/Xcode.app/Contents/Developer 2. 同意 Xcode 许可协议 sudo xcodebuild -license 然后： 按 space 滚动查看协议 在末尾输入 agree 同意 如果没有完成这步，构建可能会无提示失败或报错。 3. 安装命令行工具（如果尚未安装） xcode-select --install React Native iOS 构建依赖 Xcode 工具链和 iOS SDK。正确配置可以避免 pod install 或构建失败。 🧰 步骤 1 — 检查 Ruby 环境 检查当前使用的 Ruby： which ruby ruby -v 如果显示类似： ~/.rbenv/shims/ruby ruby 2.7.6 说明 rbenv 正在管理你的 Ruby ，而不是系统或 Homebrew Ruby。 🚀 步骤 2 — 使用 rbenv 安装新版 Ruby rbenv install 3.3.0 rbenv global 3.3.0 rbenv rehash ruby -v 📦 步骤 3 — 安装 CocoaPods gem install cocoapods pod --version 📁 步骤 4 — 安装 iOS 依赖 cd ios pod install 🔄 步骤 5 — 更新 Pod 仓库（如有需要） pod rep...

How I Set Up My Local Environment to Run a React Native iOS App Setting up a React Native project for iOS locally sounds simple—until you hit the usual roadblocks: Ruby versions, CocoaPods issues, Xcode configuration, and mysterious build failures. Here’s a clean, real-world setup that actually works. 🍎 Step 0 — Prepare Xcode (Critical but Easy to Miss) Even if you already installed Xcode from the App Store, your system may not be fully configured for command-line builds. I ran into issues until I completed these steps: 1. Select the Correct Xcode Path sudo xcode-select -s /Applications/Xcode.app/Contents/Developer xcode-select -p Expected output: /Applications/Xcode.app/Contents/Developer 2. Accept the Xcode License sudo xcodebuild -license Then: Press space to scroll through the license Type agree at the end Without this, builds may fail silently or with confusing errors. 3. Install Command Line Tools (if not already) xcode-select --install React Native i...

How to Safely Truncate a String by Byte Length in Java (UTF-8 Solution) In Java backend development, it’s common to enforce size limits on strings, such as: Database column byte limits API payload size constraints Logging or message size restrictions A typical approach is: value.substring(0, n); However, this is not safe when dealing with UTF-8 encoding . The Core Problem: Characters ≠ Bytes In UTF-8 encoding: ASCII characters → 1 byte Chinese characters → 3 bytes Emoji → 4 bytes For example: "hello" → 5 bytes "你好" → 6 bytes "😊" → 4 bytes This means: Truncating by character count does NOT guarantee byte size limits --- Does Java Provide a Built-in Solution? No — Java does not provide a direct method to safely truncate a string by byte length. While Java offers low-level APIs such as: CharsetEncoder ByteBuffer String.getBytes() They are not designed for simple, safe truncation and requ...

Java如何安全按字节长度截断String（UTF-8完整解决方案） 在Java开发中，我们经常需要对字符串进行长度限制，比如： 数据库字段有字节长度限制 接口参数有大小限制 日志或消息需要截断 很多人第一反应是使用： value.substring(0, n) 但这种方式在涉及 UTF-8 编码 时是 不安全的 。 问题本质：字符长度 ≠ 字节长度 在 UTF-8 编码中： 英文字符 → 1 byte 中文字符 → 3 bytes Emoji → 4 bytes 例如： "hello" → 5 bytes "你好" → 6 bytes "😊" → 4 bytes 因此： substring 按字符截断，无法控制字节大小 --- Java 标准库有没有现成方法？ 答案是： 没有直接可用的方法 。 虽然 Java 提供了： CharsetEncoder ByteBuffer String.getBytes() 但都需要手动处理，且实现复杂，不适合直接使用。 --- 错误实现方式（常见坑） ❌ 方式1：substring value.substring(0, 50); 问题：可能超过字节限制 ❌ 方式2：直接截断 byte[] new String(bytes, 0, maxBytes, UTF_8); 问题： 可能截断多字节字符 产生乱码（�） --- 正确实现：UTF-8安全按字节截断 public static String truncateUtf8(String value, int maxBytes) { if (value == null) return null; byte[] bytes = value.getBytes(StandardCharsets.UTF_8); if (bytes.length <= maxBytes) return value; int len = maxBytes; // 找到字符起点 int star...

解决数据库“value too long for column”错误：Java中基于字节的UTF-8字符串截断 如果你在 Java 后端开发中遇到过 “value too long for column” 的数据库错误，那么问题的根本原因可能并不像表面看起来那么简单。 本文将通过一个真实的生产事故，讲清楚 UTF-8 编码 带来的坑，以及为什么 字符串长度不等于字节长度 ，并提供一个 安全按字节截断字符串 的正确实现方式。 生产问题复盘 我们在生产环境遇到如下错误： value too long for column 数据库字段限制： 50 bytes 输入字符串长度： 53 个字符 代码已做处理：截断为 50 个字符 看起来完全没问题，但插入数据库时依然失败。 根本原因：UTF-8 编码 字符数 ≠ 字节数 在 UTF-8 编码中： 英文字符（ASCII）→ 1 字节 中文字符 → 通常 3 字节 Emoji → 4 字节 因此，一个 50 个字符的字符串，很可能超过 50 字节。 错误的实现方式 常见代码如下： if (value.length() > 50) { value = value.substring(0, 50); } 这只能保证字符数，而无法保证字节数。 更严重的是，如果直接按字节截断，还可能： 截断多字节字符 生成非法 UTF-8 字符串 出现乱码或替换字符（�） 正确解决方案：按字节安全截断 正确做法必须满足： 遵守数据库的 字节限制 保证结果是 合法 UTF-8 字符串 不能截断一个字符的一部分 Java 实现（UTF-8安全截断） public static String truncateUtf8(String value, int maxBytes) { if (value == null) return null; byte[] bytes = value.getBytes(StandardCharsets.UTF_8); if (bytes.length <= maxBytes) return valu...

Fix “Value Too Long for Column” Error: UTF-8 String Truncation by Bytes in Java If you've ever encountered the "value too long for column" database error, especially in a Java backend, the root cause may not be obvious. In this post, we’ll walk through a real production issue caused by UTF-8 encoding , explain why string length is not equal to byte length , and show how to correctly truncate strings by bytes without breaking multibyte characters. The Production Issue We hit a production error during a database insert: value too long for column Database column limit: 50 bytes Input string length: 53 characters Code already truncated to 50 characters At first glance, everything looked correct—but the insert still failed. Root Cause: UTF-8 Encoding The issue comes down to this: 50 characters does NOT equal 50 bytes in UTF-8 In UTF-8 encoding: ASCII characters → 1 byte Chinese characters → 3 bytes Emoji → 4 bytes This mean...

解决 React Native Android Gradle 构建错误的经验分享 最近在开发 React Native Android 项目时，遇到了顽固的 Gradle 构建错误，主要集中在插件解析和本地构建缓存缺失等问题，比如 com.facebook.react.settings 和 foojay-resolver 相关报错。 问题表现 执行 Gradle clean 时提示插件解析失败 本地构建产物缺失或损坏 报错涉及 metadata.bin 和 FoojayToolchainsPlugin 解决步骤 停止所有正在运行的 Gradle 进程： ./gradlew stop 删除本地 native 构建缓存： rm -rf .cxx 清理并重新构建项目，同时刷新依赖： ./gradlew clean build --refresh-dependencies 最终效果 按照上述步骤操作后，构建顺利通过，所有插件和本地依赖相关错误都被解决。如果你也遇到类似问题，不妨试试这套方法！

How I Fixed React Native Android Gradle Build Errors Recently, I encountered persistent Gradle build errors while working on a React Native Android project. The errors were related to plugin resolution and missing native build artifacts, such as com.facebook.react.settings and foojay-resolver . Symptoms Gradle clean failed with plugin resolution errors Native build artifacts missing or corrupted Errors referencing metadata.bin and FoojayToolchainsPlugin Solution Steps Stop all running Gradle daemons: ./gradlew stop Delete the native build cache: rm -rf .cxx Clean and rebuild the project with refreshed dependencies: ./gradlew clean build --refresh-dependencies Result After these steps, the build succeeded and all plugin and native dependency errors were resolved. If you encounter similar issues, try this sequence before diving into more complex troubleshooting!

React Native 导航模式：为共享页面使用全局 Stack 在许多 React Native 应用中，你可能希望从多个 Tab 打开同一个页面（如 Article 或 Details ），并且希望返回按钮能回到正确的 Tab。如果你只是把页面放在某个 Tab 的 Stack 里，会遇到一个常见的 UX 问题：返回按钮总是回到该 Stack 的根页面，而不是你来时的 Tab。 问题描述 假设你有一个包含 Home 、 Study 和 Mastery 的 Tab Navigator。如果你把 ArticleScreen 放在 Home 的 Stack 里，并从 Study 或 Mastery 跳转到它，返回按钮总是回到 Home ，而不是你来时的 Tab。这是因为导航栈是 Tab 局部的。 解决方案：使用全局 Stack 最佳实践是创建一个 RootStack ，把 Tab Navigator 和所有共享页面包裹起来。这样，任何 Tab 都可以 push 共享页面，返回按钮会回到正确的 Tab。 步骤 1：定义 Root Stack import { createNativeStackNavigator } from '@react-navigation/native-stack'; import TabNavigator from './TabNavigator'; import ArticleScreen from './ArticleScreen'; const RootStack = createNativeStackNavigator(); export default function AppNavigator() { return ( <RootStack.Navigator> <RootStack.Screen name=\"Main\" component={TabNavigator} options={{ headerShown: false }} /> <Roo...

React Native Navigation Pattern: Global Stack for Shared Screens In many React Native apps, you’ll want to open a screen (like an Article or Details page) from multiple tabs, and have the back button return to the correct previous tab. If you simply nest your screen inside a stack for one tab, you’ll run into a common UX issue: the back button always returns to the root of that stack, not to the tab you came from. The Problem Suppose you have a tab navigator with Home , Study , and Mastery tabs. If you put ArticleScreen inside the Home stack, and navigate to it from Study or Mastery , the back button will always return to Home —not the tab you came from. This is because the navigation stack is local to the tab. The Solution: Use a Global Stack The best practice is to create a RootStack that wraps your tab navigator and any shared screens. This way, any tab can push the shared screen, and the back button will return to the correct previous tab...

Fix Android Emulator “Not Enough Space” Error (installDebug Failed) If you are running a React Native app and see this error when executing npm run android , you are not alone. Execution failed for task ':app:installDebug'. ... java.io.IOException: Requested internal only, but not enough space This error usually means one thing: 🚨 Your Android Emulator is out of storage 💡 Root Cause By default, Android Virtual Devices (AVD) are created with very limited internal storage (often 2GB–6GB). Over time, this space gets filled by: Debug APK installs Gradle build artifacts System updates and cache Eventually, there is no space left to install your app. ✅ My Fix (Works Immediately) The most effective solution is to increase the emulator storage size. Open Android Studio Go to Device Manager Edit your emulator (or create a new one) Click Show Advanced Settings Set Internal Storage to 16 GB Save and restart the emulator After inc...

解决 Android 模拟器空间不足导致 installDebug 失败问题 如果你在运行 npm run android 时遇到以下错误： Execution failed for task ':app:installDebug'. ... java.io.IOException: Requested internal only, but not enough space 那么问题通常很简单： 🚨 Android 模拟器空间不足 💡 问题原因 Android 虚拟设备（AVD）默认的内部存储空间通常只有 2GB–6GB，很容易被占满： 多次安装 Debug APK Gradle 构建缓存 系统更新和缓存文件 最终导致无法再安装应用。 ✅ 我的解决方法（最有效） 直接扩大模拟器存储空间： 打开 Android Studio 进入 Device Manager 编辑已有模拟器或创建新模拟器 点击 Show Advanced Settings 将 Internal Storage 设置为 16 GB 保存并重启模拟器 设置为 16GB 后，问题即可彻底解决。 ⚡ 临时解决方案 如果只是临时应急，可以： 清空模拟器数据（Wipe Data） 手动卸载应用： adb uninstall your.package.name 但这些只是短期解决方案。 🧠 开发建议 开发环境建议至少分配 12GB–16GB 存储 关闭 Snapshot（避免保存“满磁盘状态”） 定期清理构建： cd android ./gradlew clean ✅ 总结 如果看到错误： Requested internal only, but not enough space 这 不是代码问题 ，而是模拟器磁盘空间不足。 根本解决方案： 将 AVD 内部存储提升到 16GB。 这是最稳定、最彻底的解决办法。

真正的平安与敬拜 这个主日下午的讲道让我停下来，好好想一想。 我们常常谈论世界的和平，但历史告诉我们，人靠自己其实做不到。真正的平安不是从人来的，而是从神来的。 最触动我的是对“敬拜”的提醒。每个主日，我们不只是走一个流程，而是真正来到神面前，参与天上的敬拜。这一点我常常忽略。 这也让我反思：我来教会，是不是带着渴慕的心来听神的话，还是只是习惯而已？ 另外，福音带来的平安是真实的，不只是世界层面，也是在我们人与人之间。如果我有冲突，也需要先省察自己，回到神的话语中。 真正的平安只在基督里，并且将来会完全实现。愿我们继续来到神面前，行在祂的道中。

True Peace and Worship This afternoon's sermon really made me pause and rethink a few things. We often hear about peace in the world, but history shows us that human efforts alone can’t truly achieve it. Real peace doesn’t come from governments or plans—it comes from God. What impacted me most was the reminder about worship. When we gather on Sundays, we’re not just going through a routine. We are actually coming before God, joining in heavenly worship. That’s something I often forget. It also challenged me to think: do I truly come eager to hear God’s Word, or just out of habit? Lastly, I was reminded that the gospel brings real peace—not just in the world, but in our relationships. If there’s conflict in my life, I need to first examine my own heart and return to God’s Word. True peace is found in Christ, and one day it will be fully realized when He returns. Until then, may we keep coming to Him and walking in His ways.

真正的自由，在信靠神中得着安息 在当今社会，我们常常被教导，自由就是掌控自己的人生，按照自己的想法做决定，跟随自己的内心。然而，一篇关于创世记24章的讲道，让我重新思考“自由”的真正含义。 从表面来看，以撒和利百加的故事似乎并不“自由”。这是一个安排的婚姻，一个仆人通过祷告寻求指引，一个年轻女子离开一切去嫁给一个素未谋面的人。从现代角度来看，这甚至让人感到不安。 但这段经文所揭示的真理却非常深刻：人从来都不是完全独立的。即使我们认为自己在做决定，我们仍然是在依赖某些东西，比如自己的情绪、经验，或有限的认知。 亚伯拉罕信靠神的应许，而不是试图掌控一切；仆人通过祷告依靠神，而不是倚靠自己的聪明；利百加则以信心回应，愿意顺服神的带领。 这让我反思自己的生活。我常常在做决定时感到焦虑，害怕走错路。但这种压力，其实源于我认为一切都取决于自己。而创世记24章提醒我们，神早已在掌管，并且在日常生活的细节中引导我们。 另一个重要的提醒是：顺服神并不总是轻松的。我们有时以为，如果是神的旨意，就应该很顺利。但实际上，顺服往往是有代价的。然而，这样的顺服却带来更深的平安与喜乐。 最后，以撒爱上了利百加，并在失去母亲的痛苦中得到了安慰。这让我们看到，真正的喜乐不一定是先有感觉，而是在信心和委身中慢慢成长。 真正的自由，不是掌控一切，而是在神的手中安息。当我们愿意把生命交托给神时，我们不是失去自己，而是找到真正的自己。 愿我们学习更多地信靠神，更多地祷告，在祂的计划中得着真正的平安与喜乐。

Finding True Freedom in Trusting God In today’s world, we are constantly told that freedom means having complete control over our lives. We are encouraged to make our own choices, follow our hearts, and define our own truth. But as I listened to this Sunday morning's sermon on Genesis 24, I was challenged to rethink what true freedom really means. The story of Isaac and Rebekah does not look like freedom at first glance. It involves an arranged marriage, a servant praying for guidance, and a young woman leaving everything behind to marry someone she has never met. From a modern perspective, this can feel uncomfortable—even restrictive. But the deeper message of Genesis 24 reveals something powerful: we are never truly independent. Even when we think we are making our own decisions, we are still depending on something—our feelings, our past experiences, or our limited understanding. Abraham trusted God’s promises rather than relying on his own control. The servant depended o...

解决 React Native Modal 中 ScrollView 无法滚动的问题（最佳 Modal 结构） 在使用 React Native 开发应用时，一个很常见的问题是： 在 Modal 组件中放入 ScrollView ， 虽然滚动条显示出来了，但内容却无法正常滚动。 很多开发者会发现，Modal 打开后 ScrollView 看起来是可以滚动的， 但是手指滑动时内容却几乎不动，或者滚动非常困难。 这个问题通常是因为 Modal 的 Overlay 层拦截了触摸事件 。 如果 Overlay 使用 TouchableOpacity 或 Pressable 并包裹整个 Modal 内容， 那么滚动手势会被 Overlay 捕获，从而导致 ScrollView 无法接收到滚动事件。 问题示例 很多项目中的 Modal 结构通常像这样： <TouchableOpacity style={styles.overlay} onPress={onClose}> <TouchableOpacity style={styles.modal}> <ScrollView> ... </ScrollView> </TouchableOpacity> </TouchableOpacity> 在这种结构下，最外层的 TouchableOpacity 会捕获触摸手势。当用户尝试滚动时， 触摸事件会先被 Overlay 处理，从而阻止 ScrollView 的滚动行为。 结果就是： 滚动条存在，但滚动不流畅甚至无法滚动。 正确的 Modal 结构模式 正确的解决方案是： 不要用 Touchable 包裹整个 Modal ， 而是将 背景点击区域 与 Modal 内容区域 分离。 我们可以在背景上放一个独立的 Pressable， 用于点击关闭 Modal，而 Modal 内容本身保持普通 View。 <Modal visible={visible} transparent animationType="fade" onRequestClose={onC...

Fix React Native Modal ScrollView Not Scrolling (Best Modal Pattern) A common issue when building modals in React Native is that a ScrollView inside a Modal appears scrollable but does not actually scroll smoothly. The scrollbar may appear, but gestures don't move the content properly. This usually happens because the modal overlay is intercepting touch events. If the overlay is implemented using TouchableOpacity or Pressable wrapped around the modal content, it can capture scroll gestures before they reach the ScrollView . In this post, we'll look at the problem and the correct modal pattern used in production React Native apps. The Problem Many developers structure their modal like this: <TouchableOpacity style={styles.overlay} onPress={onClose}> <TouchableOpacity style={styles.modal}> <ScrollView> ... </ScrollView> </TouchableOpacity> </TouchableOpacity> The outer TouchableOpacity captures ...

God Is the One Who Keeps Us Today’s sermon was a good reminder for me as an ordinary Christian. Many times when life feels difficult, when I struggle with sin, or when I worry about the future, my first question is usually: “Can I handle this? Can I keep going?” But the message from Jude reminds us that the real question is not whether I am able , but whether God is able . And the answer is clear: He is able. The comfort of the Christian life is not that we are holding tightly onto God, but that God is holding onto us. Even when we feel weak, tired, or discouraged, God does not let go of His people. This does not mean that Christians never stumble. We still struggle and sometimes fall into sin. But God promises that He will not let us finally fall away. He continues to hold us and lead us forward. Another part of the sermon that really spoke to me was the reminder that one day we will stand before God. If I look at myself honestly, that thought can feel a little frightening...