每日新聞摘要

This article shows how to join database tables with JPA Criteria when entity relationships are not explicitly defined. It starts with a typical School–Student mapping that uses @OneToMany and shows how a regular criteria Join produces SQL with an ON clause. Removing the relationship causes attribute resolution errors, so the author demonstrates alternatives: a subquery that selects student.schoolId and uses an IN predicate on School.id; an explicit cross join by declaring two Roots and adding a join condition; and a tuple query to return both School and Student in one result. The tutorial also notes enabling hibernate.show_sql and hibernate.format_sql to inspect generated SQL and warns that cross joins can create large Cartesian products without restrictive predicates.

本文演示在 JPA Criteria 中，当实体类没有显式关系定义时，如何连接数据库表。以 School 与 Student 为例，先展示有 @OneToMany 时的 Join 与生成的 SQL，随后移除关系属性会引发找不到属性的异常。作者提出替代方案：利用子查询选取 Student 的 schoolId，再以 IN 将 School 结果筛出；通过声明两个 Root 来构造交叉连接，并以等值条件关联字段；以及使用 Tuple 查询在同一结果中返回 School 与 Student 两个实体。文章建议启用 hibernate.show_sql 与 hibernate.format_sql 以查看实际 SQL，并提醒交叉连接在数据量大时会产生巨量结果。

This article demonstrates why you should always use the object returned by Spring Data JPA’s save() method. Through unit-test examples it distinguishes two cases: persisting a new entity and merging a detached entity. For new entities, save() calls EntityManager.persist() and returns the same instance, so continuing to use the original object appears to work. For entities with an existing id, save() calls EntityManager.merge(), which creates and returns a different managed instance while the passed object remains detached. Managed instances participate in the current transaction, trigger SQL on flush, support lazy-loading and lifecycle callbacks (e.g., @PostPersist/@PostUpdate), and are tracked for changes—detached instances are not. Ignoring the returned instance can therefore cause subtle bugs; the article concludes that you should always use the returned instance to ensure correct persistence behavior.

本文通过单元测试示例说明在使用 Spring Data JPA 时，必须使用 repository.save() 返回的实例。对于没有 ID 的新实体，save() 会调用 EntityManager.persist() 并返回相同实例；但对于已有 ID 的 detached 实体，save() 会调用 EntityManager.merge()，创建并返回一个新的 managed 实例，传入对象仍为 detached。managed 实例会参与当前事务、在 flush 时触发 INSERT/UPDATE、支持延迟加载和生命周期回调（如 @PostPersist/@PostUpdate），而 detached 实例不具备这些特性。忽视返回值、继续使用 detached 实例会带来难以发现的持久化错误，因此应始终使用 save() 的返回实例以保证正确行为。

This tutorial introduces Apache IoTDB, a free, open-source time-series database built with IoT scenarios in mind and designed to be SQL compatible. IoTDB models data in a hierarchical timeseries structure (for example root.baeldung.turbine.device1.speed) and supports aligned timeseries for multiple measurements sharing a timestamp. Deployment can be standalone (combined Config and Data node) or clustered with multiple Config and Data nodes for high availability; optional AI nodes can provide real-time models. The article shows a Docker Compose quickstart, using the built-in CLI and JDBC driver for Java connections. It covers database and timeseries management (CREATE/SHOW/DELETE), inserting data (timestamps provided or auto-assigned), querying with SELECT, and notes that records cannot be updated in place. Examples are available on GitHub.

本文概述了 Apache IoTDB：一个为物联网场景设计的开源时序数据库，且兼容 SQL 以便集成。IoTDB 以分层 timeseries 结构组织数据（例如 root.baeldung.turbine.device1.speed），并提供 aligned timeseries，用于在同一时间戳记录多个相关测量。部署可为单机模式（Config 与 Data 合并）或高可用集群（多个 Config 与 Data 节点），还可选配 AI 节点用于实时模型处理。文章演示通过 Docker Compose 快速启动、使用容器内的 CLI 以及 Java 的 JDBC 驱动连接；并介绍创建/查看/删除数据库与 timeseries、插入数据（可显式或由系统使用当前时间戳）、查询与删除操作，且说明记录不能原地更新。示例代码可在 GitHub 获取。

I’m an Android engineer from Vietnam focused on Kotlin and native Android development. Recently I’ve expanded into super-app architecture, React Native, and Kotlin Multiplatform Mobile (KMM). I’m interested in mobile app architecture, building scalable and modular Android projects, Kotlin best practices, and learning real-world engineering lessons from product teams. I created this blog to share what I learn along the way, with the goals of sharpening my technical thinking, improving my English, and contributing useful insights to the developer community. If you’re also working in mobile engineering, I’m happy to connect and learn from you. Thanks for reading.

作者是一位来自越南的 Android 工程师，主要从事 Kotlin 与原生 Android 开发，最近也参与了超级应用架构、React Native 与 KMM 的工作。他關注移动应用架构、可扩展与模块化的 Android 项目、Kotlin 最佳实践，以及来自产品团队的实务经验。创建此博客以分享在工作中学到的内容，目标是提升技术思维与英文能力，并为开发者社区贡献有用的见解；如果你也从事移动工程，作者愿意交流与互相学习，感谢阅读。

Scope functions in Kotlin are constructs that let you run a block of code with an object as its context, enabling direct access to the object's members or treating the object as a parameter inside the block. They are useful for localizing operations on an instance, initializing or configuring objects, and chaining transformations without repeatedly referencing the object. Different scope functions differ in how they present the object to the block (for example, as a receiver or as an argument) and in what value they return, so selecting the right one affects readability and the resulting value. Used appropriately, scope functions reduce boilerplate and make intent clearer; misused, they can obscure control flow, so understanding their semantics is important.

Scope function 在 Kotlin 中是能够在某个对象的上下文中执行一段代码的函数，允许在代码块内直接访问该对象的成员或将对象作为参数使用。它们常用于对象的初始化、配置与链式转换，避免重复引用同一个对象。不同的 scope function 在如何将对象传入代码块（如作为接收者或作为参数）以及返回值上有所差异，选择合适的函数会影响可读性与最终结果。正确使用可以减少样板代码、明确意图；使用不当则可能使控制流程难以理解，因此理解其语义非常重要。

The author describes diagnosing intermittent Chromium crashes (SEGV_MAPERR 000000000000) when using Playwright to capture full-page screenshots of very tall pages. Although the Docker container had generous /dev/shm and no memory cap, the host VPS had only about 630MB available and no swap, so Chromium ran out of memory during compositing (e.g., a 1920×50,000×4-byte bitmap is ~384MB plus overhead). The fix was to add 2GB swap (fallocate, mkswap, swapon and fstab entry), after which large screenshots completed successfully. The post also reviews other mitigations considered—raising shm_size, Chrome memory flags, reducing JPEG quality, or capping height—and concludes that swap is a necessary safety net, checking host-available memory matters, and a Playwright screenshot service benefits from at least 4GB RAM and swap monitoring.

文章记录了在使用 Playwright 与无头 Chromium 捕获非常高的全页截图时出现的崩溃（SEGV_MAPERR 000000000000）并排查修复过程。尽管容器已配置 2GB /dev/shm 且无内存上限，主机实际只剩约 630MB 可用且没有交换空间，导致 Chromium 在合成大尺寸位图（例如 1920×50,000×4 bytes 约 384MB）时内存飙升并被内核 OOM 杀掉。作者通过创建 2GB swap（fallocate、mkswap、swapon，并写入 fstab）解决了问题。文中还讨论了其他方案（增加 shm、Chrome 内存标志、降低 JPEG 质量、限制高度），并总结务必在 VPS 上配置 swap、检查主机可用内存，以及为截图服务考虑至少 4GB 内存。

Veronica Putri Anggraini's article demonstrates how to build a glowing bottom navigation using AGSL (Android Graphics Shading Language) shaders. Building on a prior exploration of AGSL to create an immersive landing page, the piece focuses on applying shader techniques to navigation components so they emit a luminous, attention-grabbing effect. It outlines the motivation for using shaders in Android interfaces, discusses shader-driven visual enhancements at a conceptual level, and presents a practical approach to integrating these effects into app navigation while considering usability and performance. The article is aimed at Android developers interested in advanced UI styling who want to explore shader-based techniques to make interfaces more dynamic and immersive.

作者 Veronica Putri Anggraini 演示如何使用 AGSL（Android Graphics Shading Language）着色器来构建发光的底部导航组件。文章在此前利用 AGSL 创造沉浸式 Landing Page 的基础上，聚焦于将着色器技术应用到导航元素，使其呈现发光且引人注目的视觉效果。内容阐述了在 Android 界面中使用着色器的动机、视觉增强的概念以及实用的整合思路，强调在兼顾可用性与性能的前提下提升界面表现，面向希望通过着色器提升 UI 美感与动态效果的 Android 开发者。

The article examines why Kotlin extension functions feel attractive initially—offering concise syntax, non-invasive API augmentation and convenient reuse—yet can become a maintenance burden over time. It explains how widespread or ad-hoc extension use can hide behavior away from the declaring class, complicate discoverability, blur ownership, introduce naming conflicts, and make refactoring or testing harder. The author warns that extensions can increase the surface area of an API and produce surprising runtime interactions when multiple extensions or imports collide. The piece advocates cautious use: prefer member functions or composition when appropriate, document extensions clearly, limit their scope, and review them as API design decisions rather than quick fixes. Concrete examples and patterns help teams adopt them sensibly.

文章探讨为何 Kotlin 的 extension functions 起初很吸引人──提供简洁语法、非侵入式扩展与重用便利──但随着时间可能成为维护噩梦。作者指出，滥用或随意添加 extension 会将行为隐藏在原始类之外，降低可发现性、模糊责任归属、引发命名冲突并增加重构与测试的难度。扩展方法还会扩大 API 表面，并在多个扩展或导入冲突时产生意外行为。文章建议谨慎使用：必要时优先成员方法或组合，清晰记录并限定作用域，把扩展视为设计决策而非临时方案，以避免长期负担。

The article argues that separation of concerns is a foundational practice for building reliable Android applications. By partitioning responsibilities—UI handling, business logic, and data access—developers reduce complexity, make components easier to reason about, and limit the scope of changes when features evolve. The piece highlights practical benefits: improved maintainability, straightforward unit and integration testing, faster onboarding for new team members, and reduced risk of regressions. It explains how Android-specific constructs (Activities and Fragments for UI, ViewModels for state, repositories for data) and architectural patterns like MVVM or Clean Architecture support clear boundaries, while dependency injection and modularization further enforce decoupling. The author recommends designing small, focused components, writing tests for business logic separate from UI, and keeping data layers clean to improve scalability and long-term productivity.

本文主张在 Android 应用中落实职责分离（Separation of Concerns）是提升质量与开发效率的基础做法。通过将用户界面、业务逻辑与数据存取分层，能降低复杂度、缩小变更范围并提高可读性与可维护性。文章说明 Android 常见构件（例如 Activity/Fragment、ViewModel、Repository）与 MVVM、Clean Architecture 等架构如何建立清晰边界，以及依赖注入和模块化如何强化松耦合。作者建议设计小而专注的组件、把业务逻辑与 UI 测试分离，并保持数据层简洁，以利扩展性、测试与团队协作。

Maintaining an Android app over multiple years is often unglamorous work: libraries and platform changes introduce dependency conflicts, Android API migrations require continuous updates, and decisions made in year one tend to persist and shape future effort. The article emphasizes that longevity brings recurring technical debt, frequent compatibility work, and careful trade-offs between shipping features and refactoring. Teams must balance short-term delivery with investments in architecture, testing, and upgrade paths to reduce friction later. Rather than dramatic rewrites, long-term survival usually means incremental migrations, vigilant dependency management, and accepting that early choices will influence maintenance costs and developer velocity for years to come.

长期维护 Android 应用通常并不光鲜：库和平台的变化会引发依赖冲突，Android API 的迁移需要持续更新和验证，而第一年做出的架构决策往往会长期影响后续工作量。文章强调，长期运行会带来重复的技术债、兼容性修复和权衡，团队需要在推出新功能与投入重构、测试和升级路径之间找到平衡。实际维护更多靠渐进式迁移、认真管理依赖关系，并接受早期决策对未来维护与开发效率的持续影响。

Sixtin warns that relying solely on crash rates creates an illusion of stability: low crash counts do not guarantee a healthy user experience. Many problems — background errors, partial feature failures, slow or degraded flows, and other non-crashing regressions — can impair usability and retention while remaining invisible to crash-focused monitoring. The piece argues teams should broaden their observability to capture real user impact by tracking ANRs, key-flow success rates, feature-specific errors, telemetry and user-centric signals, and by using controlled rollouts and experiments to correlate failures with behavior. Shifting measurement from raw crash numbers to metrics that reflect actual user experience helps detect regressions earlier and prioritize fixes that preserve usability and trust.

文章指出，仅看崩溃率会产生“稳定的错觉”：低崩溃率并不等于良好的使用体验。许多问题（如后台错误、功能部分失效、流程降级或性能问题）不会触发崩溃，但仍会损害可用性和留存。作者建议将可观测性从单一崩溃事件扩展到真正反映用户影响的指标，包括 ANR、关键流程成功率、功能级错误、遥测与用户中心信号，並通过受控发布与实验把错误与用户行为关联。以用户实际体验为核心的衡量方式，能更早发现问题并優先修復影响可用性的故障，避免被假象的稳定蒙蔽。

Andre at AndroidLab argues that Google Play’s enforcement rules influence Android app architecture more strongly than APIs do. Enforcement, distribution, and policy constraints force developers to make design choices—around permissions, background work, updates, and user data handling—that shape structure and component boundaries. For Kotlin and Jetpack this means practical engineering must accommodate Play’s policies even when APIs allow different patterns; compliance and predictable behavior across Play’s ecosystem often trump ideal technical designs. The article highlights why developers should treat Play policies as architectural requirements: they affect lifecycle decisions, modularization, and deployment strategies. Teams should evaluate how policy changes alter long-term maintainability, testing, and backwards compatibility, and prioritize patterns that reduce friction with Play’s rules. In short, successful Android architecture balances API capabilities with policy-driven constraints to ensure apps remain distributable, reliable, and compliant.

AndroidLab 的 Andre 提出：Google Play 的执法规则比任何 API 更深刻地影响 Android 应用架构。发布与政策限制迫使开发者在权限、后台任务、更新与用户数据处理等方面做出设计取舍，进而决定组件边界与模块化方式。对 Kotlin 与 Jetpack 而言，实践中必须将 Play 政策视为架构需求，优先考虑合规性、可预测行为与可部署性。团队应评估政策变更对维护性、测试与向后兼容性的长期影响，采用能降低与 Play 规范摩擦的设计模式。总之，成功的 Android 架构在 API 能力与政策限制之间取得平衡，确保应用可发布且稳定合规。

Android crash reports typically provide stack traces and error types but omit much of the runtime context that developers need to diagnose issues: network interactions, prior user actions, device state, and backend responses are often missing. Because those reports are fragmentary, crashes that look similar in a trace can have very different causes or be unreproducible in isolation. The article argues that relying solely on client-side crash reporting is insufficient and that teams should level up backend observability—centralized logs, correlated sessions or events, richer telemetry, and better server-side instrumentation—to reconstruct the full sequence of events. Improving backend debugging and telemetry helps narrow down root causes faster, reduces time to resolution, and makes fixes more reliable even when client reports are incomplete.

Android 的崩溃报告通常只包含堆栈追踪与错误类型，却省略运行时状态、网络或后端交互、用户操作和环境变量等关键信息，导致开发者难以重现或弄清真实根因。文章主张，仅依赖客户端报告不足以解决多数问题，团队应提升后端可观测性：集中日志、会话或事件关联、更丰富的遥测以及服务器端的监控与埋点，以还原错误发生前的完整上下文。增强后端调试能力可以加速定位问题、缩短修复时间，即使客户端报告不完整也能提供可靠线索。

This short article is an experience-led introduction to using a data store in Android, written by Satnam Singh. The author explains that the content comes from a real project and is intended to help other developers understand and apply DataStore in their own apps. Rather than being a theoretical overview, the piece is positioned as a practical account that shares lessons learned, implementation details, and tips gathered during actual development. Readers can expect a first-person recounting of setup and usage choices, common pitfalls encountered, and recommended approaches based on the author’s project work. The full article on Medium continues beyond the preview and offers the detailed walkthrough and examples referenced in this introduction.

本文由 Satnam Singh 分享他在一个 Android 项目中使用 DataStore 的亲身经验，目的是帮助其他开发者理解并在自己的应用中应用这一数据存储方案。作者强调内容来源于实际开发场景，提供基于项目实践的见解与体会，期望读者能从中获得实务上的参考与避免常见错误的方法。此为 Medium 文章的预览说明，完整篇幅在原文中包含更多细节、实现步骤与示例。

This article compares Kotlin's sealed classes and sealed interfaces, explaining their roles with simple examples and highlighting the key differences developers should consider. It outlines how each construct restricts and models types, and presents practical guidance on choosing between them in Android projects. The piece emphasizes understanding the semantic and structural distinctions so you can pick the more appropriate sealed construct for representing closed hierarchies, handling exhaustive control flow, and organizing implementations. By combining conceptual explanation with illustrative examples, the article aims to help Android developers decide when a sealed class or a sealed interface better fits their design needs, while clarifying trade-offs relevant to inheritance, implementation flexibility, and code organization.

本文对比了 Kotlin 的 sealed class 与 sealed interface，借助简明示例说明二者的作用与关键差异，并给出在 Android 项目中选择时的建议。文章强调理解语义和结构上的不同，以便在表示封闭类型层次或需要穷尽匹配的控制流时，选用更合适的封闭机制。通过理论说明与实例演示相结合，帮助开发者在继承限制、实现灵活性和代码组织等方面权衡利弊，从而决定在具体场景中使用 sealed class 还是 sealed interface。

This article is a developer-oriented guide to Android's Restore Credentials API, showing how to implement zero-tap authentication in Kotlin to remove friction during "New Phone" sign-ins. It explains how the API can automate credential restoration, reduce user churn, and streamline device migration, and provides practical guidance on integration steps, common pitfalls, and recommended practices for secure, user-friendly authentication flows. The author targets Android developers seeking to improve onboarding and reauthentication experiences, offering illustrative examples and explanations to accelerate implementation. The piece also discusses considerations such as user privacy, handling failed restorations or multiple accounts, API availability across Android versions, and balancing convenience with security when enabling automatic credential restores.

本文为开发者提供 Android Restore Credentials API 的实务指南，示范如何使用 Kotlin 实现“零点触发”验证，使用户在换机时可自动还原凭证，减少流失并简化登录流程。文章阐述了 API 的整合流程、常见问题与推荐做法，并讨论安全性、隐私和处理还原失败或多账户等边缘情形的策略，同时考虑不同 Android 版本的兼容性。目标读者为希望提升新机上手与重新认证体验的 Android 开发者，强调在兼顾便利性与安全性的前提下，利用 Restore Credentials 提供顺畅的无密码或自动还原体验。

Jetpack Navigation 3 is presented as a Compose-first navigation library for Android that emphasizes giving developers full control over the back stack and improved type-safety. By shifting focus toward Jetpack Compose, the library intends to align navigation primitives with Compose's paradigms, making navigation flows in Compose-based apps more explicit and type-checked. The brief announcement highlights control of the back stack and better type-safety as primary benefits, positioning Navigation 3 as an evolution of prior Jetpack navigation components for teams adopting Compose. While details are limited in the excerpt, the library is intended for Android developers building Compose UI who need predictable navigation behavior and stronger compile-time guarantees. Readers are directed to the original Medium post for the full article and technical specifics.

Jetpack Navigation 3 是一个以 Compose 为优先的新导航库，强调让开发者对回溯堆栈（back stack）拥有完整控制并提升类型安全性。通过以 Compose 为出发点，目标是将导航原语与 Jetpack Compose 的设计语义对齐，使得在 Compose 构建的应用中，导航流程更明确并在编译阶段获得更多检查与保障。摘录文字较短，仅点出对堆栈控制与类型安全的主要优势；欲取得完整示例与技术细节，请参阅原始 Medium 文章。