每日新聞摘要 - 2026年07月31日

01

How I built an app to solve the "12 testers for 14 days" Google Play requirement

Dev.to Kotlin 作者：Gromas Tech 發布：07-31 12:00

How I built an app to solve Google Play’s “12 testers for 14 days” requirement

A community app where every user is both a tester and a developer.

重點摘要

Users list their own Closed Tests and test others in return

Reciprocity is enforced with reputation and credits on the server

The app verifies real daily launches using Android usage-access stats

Google now requires new Android developer accounts to recruit 12 real testers for a Closed Test lasting 14 consecutive days before production release, a hurdle many developers struggle to meet. To address this, the author built 12 Testers GT, a community app where every user is both a tester and a developer. People browse open Closed Tests and participate either as mutual swaps or solo requests, with reciprocity enforced through reputation and credits on the backend. The app also checks Android usage-access stats to confirm actual daily launches, making fake participation harder. The author is now using the app to help pass the requirement for the app that helps others pass it, and invites feedback on the reciprocity model, onboarding, and discovery.

我如何打造一款应用，解决 Google Play “12 位测试者连续 14 天” 的要求

一个让每位用户既是测试者也是开发者的社区应用。

重點摘要

用户可发布自己的 Closed Test，并互相测试

通过声誉分和 credits 在服务端强制互惠

利用 Android usage-access stats 验证每日真实启动

Google 规定新的 Android 开发者账号在发布正式版前，必须先招募 12 位真实测试者连续 14 天进行 Closed Test，这让许多开发者陷入停滞。为了解决这一问题，作者开发了 12 Testers GT，一个社区应用，让每位用户同时扮演测试者和开发者。用户可以浏览开放的 Closed Test，选择互换测试或单向请求，系统则在后端通过声誉分和 credits 维持互惠。应用还会读取 Android 的 usage-access 统计，确认用户当天是否真实打开过应用，以减少作弊。作者甚至正在用这款应用帮助自己通过该要求，并希望收到关于互惠机制、首次引导和测试发现功能的反馈。

我如何打造一款 App 來解決 Google Play「12 位測試者、14 天」的要求

一個讓每位使用者同時是測試者與開發者的社群 App。

重點摘要

使用者可上架自己的 Closed Test，並互相測試

以聲譽分數與 credits 在伺服器端強制互惠

透過 Android usage-access stats 驗證每日真實開啟

Google 規定新的 Android 開發者帳號必須先找到 12 位真實測試者，連續 14 天進行 Closed Test，才能發布到正式環境，這讓許多開發者卡關。作者因此打造了 12 Testers GT，做成一個社群 App，讓每位使用者同時扮演測試者與開發者。使用者可以瀏覽公開的 Closed Test，採互換或單向請求的方式參與，並由後端以聲譽分數與 credits 維持互惠機制。App 也會讀取 Android 的使用狀態資料，確認每天是否真的開啟過，避免虛假測試。作者目前甚至用這個 App 來幫自己通過門檻，並徵求對互惠模型、首次體驗與發現機制的回饋。

02

Building an Android Geofencing Engine: Balancing Battery Drain vs. Accuracy

Dev.to Kotlin 作者：Haseeb 發布：07-31 13:56

Building an Android Geofencing Engine: Balancing Battery Drain vs. Accuracy

I wanted something that just worked: a set-and-forget engine that respected local data and battery life.

重點摘要

Geofencing in Android must balance trigger speed against battery consumption.

Background execution limits and Doze mode can prevent system actions from running.

Reliability improved by using an accuracy buffer and accounting for indoor GPS weakness.

This article describes the author’s experience building Muffle, an Android geofencing-based app designed to mute a phone automatically in specific places. He explains the core challenge of choosing between accuracy and battery efficiency, why fast location updates can drain power, and how Android’s background limits and Doze mode can stop even correctly triggered geofences from changing audio settings. He also discusses indoor GPS unreliability and his fix: expanding the geofence radius based on confidence levels, with a possible future fallback using Wi‑Fi BSSIDs. The main lesson is that location automation must be designed for worst-case conditions, and reliability depends as much on permissions and OS behavior as on GPS logic.

构建 Android 地理围栏引擎：在耗电与精度之间平衡

我想要的是一个真正能用的工具：设置好后无需再管，同时还要尊重本地数据和电池续航。

重點摘要

Android 地理围栏需要在触发速度与电池消耗之间权衡。

Doze 模式和后台限制，可能让触发后的系统操作无法执行。

通过误差缓冲与应对室内 GPS 弱信号，可提升可靠性。

这篇文章讲述作者开发 Muffle 的经历，目标是在用户进入特定地点时自动让 Android 手机静音。实现过程中最核心的矛盾，是地理围栏的准确性与电池续航之间的取舍：高精度定位会迅速耗电，而低功耗方案又可能触发过晚。作者还发现，Android 的 Doze 模式和各厂商对后台执行的限制，可能导致地理围栏虽然触发，但音量设置却无法真正修改。由于室内 GPS 信号经常衰减，他加入了根据定位置信度调整围栏半径的误差缓冲。文章强调，位置自动化的可靠性不仅取决于 GPS，还取决于权限、后台限制和系统行为。

打造 Android 地理圍欄引擎：在耗電與精準之間取捨

我想要的是一個真正能運作的工具：能設定後就不必再管，還要兼顧本機資料與電池續航。

重點摘要

Android 地理圍欄必須在觸發速度與耗電之間取得平衡。

Doze 模式與背景執行限制，可能讓已觸發的事件無法真正執行。

透過誤差緩衝與考量室內 GPS 弱訊，可提升可靠度。

本文記錄作者開發 Muffle 的過程，目標是在使用者進入特定地點時自動將 Android 手機靜音。過程中最大的難題，是地理圍欄的精準度與電池耗電之間的拉鋸：高精度更新會快速耗電，低功耗定位又可能觸發太晚。作者也發現，Doze 模式與各家廠商的背景限制，會讓地理圍欄雖然觸發成功，卻無法順利修改音量設定。此外，室內 GPS 訊號衰減明顯，因此他加入依定位可信度調整半徑的誤差緩衝。整體來說，真正的可靠性不只來自定位 API，還取決於權限、背景限制與系統行為。

03

Kdrant 2.0: I removed the reason to use the official client

Dev.to Kotlin 作者：AS 發布：07-31 15:04

Kdrant 2.0: I Removed the Reason to Use the Official Client

Kdrant 2.0 adds a gRPC engine behind the same client, so REST and gRPC are now separate choices without changing the API.

重點摘要

REST and gRPC now share the same QdrantClient API

The gRPC engine adds no changes to kdrant-core and ships as a separate artifact

Shared Docker-backed tests caught a gRPC-only payload bug

Kdrant 2.0 introduces a gRPC engine behind the same QdrantClient used for REST, eliminating the earlier need to switch to the official client for higher throughput. The core API stays unchanged, while the new transport is delivered as a separate artifact with its own generated stubs and dependency set. A shared behavioural test suite running against real Qdrant in Docker validated both engines and uncovered a gRPC-only bug around scroll and retrieve payload defaults. The project remains multiplatform at the core, with JVM-only transports for now, and the upgrade path is straightforward: Gradle users mainly bump versions, while Maven users may need to move to the JVM artifact.

Kdrant 2.0：我移除了使用官方客户端的理由

Kdrant 2.0 在同一个客户端后面加入 gRPC 引擎，让 REST 和 gRPC 成为可自由选择的传输方式。

重點摘要

REST 与 gRPC 现在共享同一套 QdrantClient API

gRPC 引擎独立发布，且不会影响 kdrant-core

共享测试在 Docker 里发现了仅 gRPC 出现的 payload 问题

Kdrant 2.0 在原有的 QdrantClient 后方新增 gRPC 引擎，使过去为了高吞吐与流式传输而改用官方客户端的理由不再存在。核心 API 保持不变，新传输层以独立制品和自动生成的 stubs 提供，且不拖入 REST 用户不需要的 gRPC、protobuf 与 Netty 依赖。作者还建立了共享的行为测试套件，在 Docker 中连接真实 Qdrant，同步验证 REST 与 gRPC，并借此发现一个仅在 gRPC 上出现的 payload 默认值错误。核心模块继续支持多平台，但传输层目前仍限 JVM。

Kdrant 2.0：我不再需要官方客戶端的理由

Kdrant 2.0 在同一個客戶端後方加入 gRPC 引擎，讓 REST 與 gRPC 成為可自由選擇的傳輸方式。

重點摘要

REST 與 gRPC 共用同一套 QdrantClient API

gRPC 引擎獨立發佈，且不影響 kdrant-core

共享的 Docker 測試發現了 gRPC 專屬的 payload 問題

Kdrant 2.0 在既有的 QdrantClient 後方加入 gRPC 引擎，讓原本必須改用官方客戶端才能取得的高吞吐優勢，現在可直接在同一套 API 下選擇傳輸方式。核心程式未因新增 gRPC 而改動，相關實作則以獨立套件與自動產生的 stubs 提供。作者建立了共用的行為測試，透過 Docker 中的真實 Qdrant 同時驗證 REST 與 gRPC，並抓出一個只有 gRPC 會出現的 payload 預設值錯誤。核心模組也維持多平台設計，但目前傳輸層仍以 JVM 為主。

04

Beyond Semantics: How to Test Internal Compose State with snapshotFlow

ProAndroidDev 作者：Richa Sharma 發布：07-31 08:09

Beyond Semantics: Testing Internal Compose State with snapshotFlow

snapshotFlow bridges Compose State into Kotlin Flows, making internal UI state observable in tests.

重點摘要

Transforms Compose state into a cold Kotlin Flow

Useful when Semantics Tree cannot expose internal state

Avoids flaky tests caused by Thread.sleep() and polling

This article explains how snapshotFlow can help test internal Jetpack Compose state that is not exposed through the Semantics Tree. It shows how snapshotFlow observes Compose state changes, re-emits when values differ, and bridges UI state into coroutines. Using scroll position as an example, the author demonstrates how tests can wait for a specific internal condition before asserting, instead of relying on Thread.sleep() or unstable polling. The piece also clarifies that standard matchers should still be used when the state is already visible in semantics, while snapshotFlow is best for hidden state such as scroll offsets, pager state, or custom animatable values.

超越语义树：使用 snapshotFlow 测试 Compose 内部状态

snapshotFlow 可以把 Compose State 转换为 Kotlin Flow，让测试观察到内部 UI 状态。

重點摘要

将 Compose 状态桥接为冷 Kotlin Flow

适合测试语义树无法表达的内部状态

比 Thread.sleep() 和轮询更稳定，减少 flaky test

本文介绍了如何借助 snapshotFlow 测试 Jetpack Compose 中无法通过语义树直接访问的内部状态。snapshotFlow 会观察其代码块内读取的 Compose State，只要状态变化且新值与上次不同，就会重新发射，从而把 UI 状态桥接到协程世界。作者以滚动位置为例，展示了在测试中先等待特定条件成立，再继续断言的做法，以避免 Thread.sleep() 和不稳定的轮询。文章同时指出，如果状态已经体现在语义树中，应继续使用常规 matcher；snapshotFlow 更适合用于滚动偏移、Pager 内部状态或自定义 Animatable 值等隐藏状态。

超越語意樹：用 snapshotFlow 測試 Compose 內部狀態

snapshotFlow 能把 Compose State 轉成 Kotlin Flow，讓測試得以觀察內部 UI 狀態。

重點摘要

將 Compose 狀態轉為冷流以便在協程中處理

適用於語意樹無法直接表達的內部狀態

比 Thread.sleep() 與輪詢更穩定、較不易 flaky

本文說明如何利用 snapshotFlow 測試 Jetpack Compose 中無法透過 Semantics Tree 直接取得的內部狀態。snapshotFlow 會監聽其區塊內讀取的 Compose State，當值改變且與前次不同時便重新發射，讓測試能把 UI 狀態橋接到協程流程中。作者以捲動位置為例，示範如何在條件成立前等待再進行斷言，避免使用 Thread.sleep() 或不穩定的輪詢。文中也提醒，若狀態已能由語意樹表達，仍應優先使用一般 matcher；snapshotFlow 則適合用於捲動偏移、Pager 內部狀態等看不見的資料。

05

Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder

ProAndroidDev 作者：chanzmao 發布：07-31 08:56

Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder

Compose and Navigation 3 are redefining where state belongs rather than replacing ViewModel outright.

重點摘要

Compose changes the ownership model for state.

ViewModel is now framed as a business logic state holder.

Navigation 3 further separates navigation state from presentation logic.

The article argues that Android architecture is moving beyond treating ViewModel as the default owner of all state. Compose encourages developers to keep state as close as possible to where it is consumed, using remember, rememberSaveable, and rememberSerializable for UI and destination-local state. Google’s guidance now distinguishes between state holders in general and ViewModel specifically, describing ViewModel as a business logic state holder rather than a universal container. Navigation 3 further separates responsibilities by placing navigation state in NavKey and letting each destination own its own state. The result is a simpler model: UI state in the UI, navigation state in Navigation, persistent data in repositories, and presentation logic in ViewModel.

Android 架构正悄然超越将 ViewModel 作为状态容器

Compose 和 Navigation 3 并没有取代 ViewModel，而是在重新定义状态应该归谁所有。

重點摘要

Compose 改变了状态所有权的思路。

ViewModel 被重新定义为业务逻辑 state holder。

Navigation 3 让导航状态与呈现逻辑进一步分离。

文章认为，Android 架构正在逐步摆脱把 ViewModel 当作所有状态默认容器的做法。Compose 提倡把状态放在最接近使用处，并通过 remember、rememberSaveable、rememberSerializable 处理 UI 和目的地局部状态。Google 的官方指导也开始区分 state holder 与 ViewModel，本质上把 ViewModel 定位为承担业务逻辑的 state holder，而不是通用状态容器。Navigation 3 进一步将导航状态交给 NavKey，让每个导航条目拥有自己的状态。由此形成更清晰的分工：UI 状态留在 UI 中，导航状态交给 Navigation，持久数据交给 repository，呈现逻辑由 ViewModel 承担。

Android 架構正悄悄超越將 ViewModel 作為狀態容器

Compose 與 Navigation 3 並未取代 ViewModel，而是在重新定義狀態該屬於哪裡。

重點摘要

Compose 改變了狀態所有權的思維。

ViewModel 被重新定位為業務邏輯 state holder。

Navigation 3 讓導覽狀態與呈現邏輯分離。

文章指出，Android 架構正逐步擺脫把 ViewModel 當成所有狀態預設容器的做法。Compose 提倡將狀態放在最接近使用處，並以 remember、rememberSaveable、rememberSerializable 處理 UI 與目的地內的狀態。Google 的最新指引也把 state holder 與 ViewModel 區分開來，明確將 ViewModel 定位為承擔業務邏輯的 state holder，而非萬用容器。Navigation 3 進一步把導覽狀態交給 NavKey，每個目的地各自擁有自己的狀態。最終形成更清楚的分工：UI 狀態留在 UI、導覽狀態交給 Navigation、持久資料交給 repository、呈現邏輯由 ViewModel 處理。

06

十分鐘認識 Kotlin UUID

Medium Kotlin 作者：Andy Lu 發布：07-31 10:01

A 10-Minute Introduction to Kotlin UUID

Kotlin introduced UUID in 2.0.20, and it became a stable release in 2.4.0.

重點摘要

UUID was introduced as kotlin.uuid.Uuid in Kotlin 2.0.20.

It became a stable API in Kotlin 2.4.0.

The article aims to explain what UUID is and what it is used for.

Kotlin introduced UUID support as kotlin.uuid.Uuid in version 2.0.20, and it later became a stable API in 2.4.0. After this move to stable, many developers may still be unclear about what UUID is and why it matters. The article sets out to give a brief introduction to UUID and explain its purpose, helping readers understand the concept behind the new Kotlin feature.

十分钟认识 Kotlin UUID

Kotlin 在 2.0.20 推出 UUID（kotlin.uuid.Uuid）后，于 2.4.0 正式成为稳定版本。

重點摘要

UUID 以 kotlin.uuid.Uuid 的形式在 Kotlin 2.0.20 推出。

Kotlin 2.4.0 之后，UUID 进入稳定版本。

文章旨在介绍 UUID 是什么，以及它的用途。

Kotlin 在 2.0.20 版本推出 UUID（kotlin.uuid.Uuid）后，于 2.4.0 正式成为稳定版本。尽管已经进入稳定版，许多人对 UUID 的概念和用途仍不太清楚，因此这篇文章希望用简明方式带读者认识 UUID，说明它是什么、能做什么，并帮助理解 Kotlin 这项新功能的实际意义。

十分鐘認識 Kotlin UUID

Kotlin 在 2.0.20 推出 UUID（kotlin.uuid.Uuid）後，於 2.4.0 正式成為穩定版本。

重點摘要

UUID 以 kotlin.uuid.Uuid 的形式在 Kotlin 2.0.20 推出。

Kotlin 2.4.0 之後，UUID 進入穩定版本。

文章旨在介紹 UUID 是什麼，以及它的用途。

Kotlin 在 2.0.20 版本推出 UUID（kotlin.uuid.Uuid）後，於 2.4.0 正式成為穩定版本。即使功能已穩定，許多人對 UUID 的概念與用途仍不夠熟悉，因此這篇文章想帶讀者快速認識 UUID，說明它是什麼、能做什麼，幫助理解 Kotlin 新增這項功能的實際意義。

07

GitHub Cruise: Production Android Architecture — Clean Layers, Offline-First, Type-Safe Errors

Medium Kotlin 作者：Dinakar Maurya 發布：07-31 10:01

GitHub Cruise: Production Android Architecture — Clean Layers, Offline-First, Type-Safe Errors

From code to leadership. Building, shipping, growing.

重點摘要

The provided content does not include the article body.

Only the title and author information are available.

No further facts can be verified from the excerpt.

The supplied text contains only the article title, author name, and a brief Medium teaser, but no substantive body content. As a result, there is not enough information to accurately summarize the article’s architecture guidance, implementation details, or conclusions. The title suggests a focus on production Android architecture with clean layers, offline-first design, and type-safe error handling, but these points cannot be confirmed from the excerpt alone.

GitHub Cruise：生产级 Android 架构——清晰分层、离线优先、类型安全错误

从写代码到领导力：构建、交付、成长。

重點摘要

所提供内容不包含文章正文。

目前只能确认标题与作者信息。

仅凭摘录无法核实更多事实。

这段原文仅包含文章标题、作者姓名和一段 Medium 简介，并没有正文内容，因此无法准确概括其架构思路、实现细节或结论。标题显示文章可能讨论生产级 Android 架构，包括清晰分层、离线优先与类型安全错误处理，但这些内容无法从当前摘录中得到确认。

GitHub Cruise：生產級 Android 架構——乾淨分層、離線優先、型別安全錯誤

從寫程式到領導：打造、交付、成長。

重點摘要

提供的內容沒有文章正文。

目前只能確認標題與作者資訊。

僅憑節錄無法驗證更多事實。

這份原文僅提供文章標題、作者名稱與一段 Medium 簡介，沒有實際正文內容，因此無法忠實摘要其架構設計、實作細節或結論。標題顯示本文可能聚焦於生產級 Android 架構，包含乾淨分層、離線優先與型別安全錯誤處理，但這些重點都不能從目前摘錄中直接確認。

08

Why We Chose KMP Over React Native: It’s an Architecture Bet, Not a Framework Preference

Medium Kotlin 作者：Yassine Beldi 發布：07-31 10:28

Why We Chose KMP Over React Native: It’s an Architecture Bet, Not a Framework Preference

Every mobile team eventually runs into the same headaches: maintaining two separate codebases for iOS and Android is expensive, slow, and…

重點摘要

The article argues the choice is about architecture, not personal framework preference.

Maintaining separate iOS and Android codebases is costly and slows teams down.

KMP is presented as an alternative for reducing duplicated mobile work.

The article frames the choice between KMP and React Native as an architectural decision rather than a simple framework preference. It begins from a common mobile-team pain point: keeping separate iOS and Android codebases is expensive and slow. On that basis, the author positions KMP as a way to reduce duplicated effort and make the codebase strategy more sustainable, emphasizing that the real question is how a team wants to structure its mobile architecture.

为什么我们选择 KMP 而不是 React Native：这是一场架构上的押注，而非框架偏好

每个移动团队最终都会遇到同样的麻烦：维护两套独立的 iOS 和 Android 代码库既昂贵、又缓慢，而且……

重點摘要

文章强调，这不是框架偏好，而是架构取舍。

分别维护 iOS 和 Android 代码库成本高、效率低。

KMP 被视为减少重复开发的一种方案。

文章将 KMP 与 React Native 的选择，上升为架构层面的判断，而不是单纯的框架偏好。作者先指出移动团队常见的痛点：iOS 和 Android 各自维护独立代码库，不仅成本高，也会拖慢开发速度。在此基础上，文章把 KMP 描述为一种减少重复劳动、让代码库策略更可持续的方案，核心在于团队如何设计自己的移动端架构。

為什麼我們選擇 KMP 而不是 React Native：這是一場架構上的押注，而非框架偏好

每個行動團隊最終都會遇到同樣的難題：維護兩套獨立的 iOS 與 Android 程式碼庫既昂貴又緩慢，而且……

重點摘要

文章主張，這不是框架喜好，而是架構選擇。

分別維護 iOS 與 Android 程式碼庫成本高、速度慢。

KMP 被視為減少重複開發的一種解法。

文章將 KMP 與 React Native 的選擇，定義為架構層面的決策，而不是單純的框架偏好。作者先指出行動團隊普遍會面臨的痛點：iOS 與 Android 各自維護一套程式碼庫，成本高且效率低。基於這個問題，文章把 KMP 描述為一種能減少重工、讓程式碼策略更可持續的方案，重點在於團隊如何規劃自己的行動端架構。

09

Why WorkManager exists (Part 1.1):

Medium Kotlin 作者：Abinash Dash 發布：07-31 12:54

Why WorkManager Exists (Part 1.1)

Android’s background processing used to be a highly fragmented, battery-draining nightmare.

重點摘要

Background work on Android was fragmented across many APIs.

Developers had to juggle multiple approaches to get tasks done.

WorkManager was created to simplify and unify background processing.

Android background processing was once fragmented and difficult to manage, with developers forced to coordinate multiple APIs and workarounds. This complexity often led to poor reliability and higher battery use. The article introduces the motivation behind WorkManager: to provide a unified, more dependable way to handle background tasks in Android apps.

为什么需要 WorkManager（第 1.1 部分）

Android 的后台处理过去一直是高度碎片化、耗电的噩梦。

重點摘要

Android 后台任务曾分散在多种 API 中。

开发者必须同时处理多种方案才能完成任务。

WorkManager 的目标是简化并统一后台处理。

Android 的后台处理过去非常碎片化，开发者不得不在多种 API 和变通方案之间来回切换，不仅实现复杂，也常常带来更高的耗电与不稳定性。文章说明了 WorkManager 存在的原因：它希望为 Android 应用提供一种更统一、更可靠的后台任务处理方式，减少开发负担并提升整体体验。

為什麼需要 WorkManager（第 1.1 部分）

Android 的背景處理過去一直是高度碎片化、又耗電的惡夢。

重點摘要

Android 背景工作曾分散在多種 API 之間。

開發者必須同時應付多種做法來完成任務。

WorkManager 的目的，是簡化並統一背景處理。

Android 的背景處理曾經非常碎片化，開發者不得不在多種 API 與替代方案之間來回切換，既複雜又容易造成耗電與不穩定。這篇文章點出 WorkManager 的出現背景：它旨在為 Android 應用提供更一致、可靠的背景工作處理方式，降低管理成本並改善整體體驗。

10

Android Offline Sync Done Right: Tested Migrations, Outbox Queue, and WorkManager

Medium Kotlin 作者：Ashutosh Kumar 發布：07-31 12:57

Android Offline Sync Done Right: Tested Migrations, Outbox Queue, and WorkManager

Part 2 of the Room series — prove your migrations with real fixtures, then push offline edits safely with an outbox and WorkManager.

重點摘要

Focuses on validating Room migrations with real test fixtures.

Describes safely syncing offline edits using an outbox queue.

Uses WorkManager to reliably process background sync tasks.

This article, Part 2 of the Room series, emphasizes practical ways to build reliable Android offline sync. It highlights testing database migrations with real fixtures so schema changes can be verified instead of assumed. The piece also outlines an outbox queue pattern for storing offline edits safely and then syncing them later. WorkManager is used to handle background processing, helping ensure queued work runs reliably when conditions allow.

Android 离线同步的正确做法：经过测试的迁移、Outbox 队列与 WorkManager

Room 系列第 2 部分——先用真实 fixtures 验证迁移，再通过 outbox 和 WorkManager 安全发送离线编辑。

重點摘要

用真实测试数据验证 Room 数据库迁移。

通过 outbox 队列安全保存离线编辑。

借助 WorkManager 可靠处理后台同步任务。

这篇文章是 Room 系列的第 2 部分，重点讨论如何实现可靠的 Android 离线同步。作者强调应使用真实的测试 fixtures 来验证数据库迁移，而不是只凭假设确认 schema 变更是否正确。文章还介绍了 outbox 队列模式，用来先安全保存离线状态下的编辑，再在合适时机同步出去。最后结合 WorkManager 处理后台任务，以提高同步流程的稳定性和可靠性。

Android 離線同步的正確做法：經過測試的遷移、Outbox 佇列與 WorkManager

Room 系列第 2 部分——先用真實 fixtures 驗證遷移，再透過 outbox 與 WorkManager 安全地送出離線編輯。

重點摘要

以真實測試資料驗證 Room 資料庫遷移。

使用 outbox 佇列安全保存離線編輯。

透過 WorkManager 可靠處理背景同步工作。

這篇文章是 Room 系列的第 2 部分，重點在於如何建立可靠的 Android 離線同步流程。作者強調要用真實的測試 fixtures 驗證資料庫遷移，避免只靠假設確認 schema 變更正確。接著介紹 outbox 佇列模式，先安全保存離線狀態下的編輯內容，再於適當時機同步出去。最後搭配 WorkManager 負責背景任務處理，提升同步工作的穩定性與可靠度。

11

The Pillars of Robust Android Applications : Part 3

Medium Kotlin 作者：Pratistha Sinha 發布：07-31 13:16

The Pillars of Robust Android Applications: Part 3

In this part, we are going to continue the series on building robust Android applications.

重點摘要

Continues a series on robust Android app design.

Builds on the security-focused second part.

Introduces the next topic in the series.

This article is the third part of a series on building robust Android applications. The excerpt notes that the previous installment covered how to design a secured Android application, and this part continues the discussion by moving on to the next topic in the series. Based on the provided text, the post serves as an introduction to the continuation of the broader Android architecture and design series rather than presenting detailed technical content in the excerpt itself.

稳健 Android 应用程序的支柱：第 3 部分

本篇将继续这一系列，探讨如何构建稳健的 Android 应用程序。

重點摘要

延续稳健 Android 应用设计系列。

承接第 2 部分的安全性主题。

引出本系列的下一项内容。

这篇文章是《The Pillars of Robust Android Applications》系列的第 3 部分。文中说明，前一部分已经讨论了如何设计安全的 Android 应用程序，而本篇则会继续该系列，展开下一个主题。根据目前提供的内容，这段文字主要起到承上启下的作用，用于衔接前文并预告后续内容，并未在摘要片段中给出具体的技术细节。

穩健 Android 應用程式的支柱：第 3 部分

本篇將延續系列內容，探討如何打造穩健的 Android 應用程式。

重點摘要

延續穩健 Android 應用設計系列。

承接第 2 部分的安全性主題。

引出本系列的下一個議題。

這篇文章是〈The Pillars of Robust Android Applications〉系列的第 3 部分。內文提到，前一部分已探討如何設計具安全性的 Android 應用程式，而本篇則將延續該系列，進入下一個主題。根據目前提供的內容，這是一篇承上啟下的導言，主要用來銜接前後文，並預告後續將展開的 Android 應用設計討論，而非在摘要片段中直接呈現具體技術細節。

12

Basic Android Anatomy

Medium Kotlin 作者：Cureerel 發布：07-31 13:16

Basic Android Anatomy

An Android application starts from the AndroidManifest.xml file.

重點摘要

The app begins with AndroidManifest.xml.

The Android system reads the manifest first.

The manifest provides key app information.

This article introduces the basic structure of an Android app by focusing on the AndroidManifest.xml file. It explains that an Android application starts from the manifest, and that the Android system reads this file first to determine essential information about the app. Although the provided excerpt is brief, it points to the manifest as the entry point for understanding how Android applications are identified and managed by the system.

Android 基础结构解析

Android 应用程序从 AndroidManifest.xml 文件开始。

重點摘要

应用程序从 AndroidManifest.xml 开始。

Android 系统会先读取 manifest。

manifest 提供应用程序的重要信息。

本文围绕 AndroidManifest.xml 介绍 Android 应用程序的基础结构。内容指出，Android 应用程序从 manifest 文件开始，而 Android 系统会先读取该文件，以确定应用程序的相关信息。虽然原文摘录很短，但已经明确说明 manifest 是理解 Android 应用如何被系统识别与管理的起点。

Android 基礎結構解析

Android 應用程式從 AndroidManifest.xml 檔案開始。

重點摘要

應用程式從 AndroidManifest.xml 開始。

Android 系統會先讀取 manifest。

manifest 提供應用程式的重要資訊。

本文以 AndroidManifest.xml 為核心，介紹 Android 應用程式的基本結構。內文指出，Android 應用程式是從 manifest 檔案開始，而 Android 系統也會先讀取這個檔案，以判斷應用程式的相關資訊。雖然原文節錄很短，但已明確點出 manifest 是理解 Android 應用程式如何被系統辨識與管理的起點。

13

ProGuard in Multi-Module Android Apps: What It Is, How It Works, and How to Debug Production…

Medium Kotlin 作者：Kamaldeep Kakkar 發布：07-31 13:31

ProGuard in Multi-Module Android Apps: What It Is, How It Works, and How to Debug Production…

Continue reading on DroidStack »

重點摘要

The provided body contains only a paywall prompt.

No article content is available to summarize.

Only the original title and author information are present.

The supplied content does not include the article text itself. It only shows a membership prompt to continue reading on DroidStack, along with the original title and author name. As a result, there are no substantive details about ProGuard, multi-module Android apps, or debugging production issues that can be extracted or summarized from the provided body.

多模块 Android 应用中的 ProGuard：它是什么、如何工作，以及如何调试正式环境…

继续在 DroidStack 阅读 »

重點摘要

提供的正文只有付费墙提示。

没有可用的文章内容可供摘要。

目前仅有原标题与作者信息。

所提供的内容并未包含文章正文，只显示要求成为会员后才能继续在 DroidStack 阅读的提示，以及原标题与作者信息。因此，无法从这段文字中提取关于 ProGuard、多模块 Android 应用或正式环境调试的实质细节，也无法据此生成忠于原文事实的摘要。

多模組 Android 應用中的 ProGuard：它是什麼、如何運作，以及如何除錯正式環境…

繼續在 DroidStack 閱讀 »

重點摘要

提供的內文只有付費牆提示。

沒有可用的文章內容可供摘要。

目前僅有原始標題與作者資訊。

所提供的內容並未包含文章正文，只顯示要求成為會員後才能繼續在 DroidStack 閱讀的提示，以及原始標題與作者資訊。因此，無法從這段文字中萃取出關於 ProGuard、多模組 Android 應用或正式環境除錯的實質細節，也無法據此產生忠於原文的內容摘要。

14

WorkManager (Part 1.2): OneTimeWorkRequest vs PeriodicWorkRequest

Medium Kotlin 作者：Abinash Dash 發布：07-31 13:57

WorkManager (Part 1.2): OneTimeWorkRequest vs PeriodicWorkRequest

WorkManager handles all background tasks as WorkRequest objects.

重點摘要

WorkManager represents background work as WorkRequest objects.

The article focuses on comparing OneTimeWorkRequest and PeriodicWorkRequest.

The provided excerpt contains only a brief introduction, with the full explanation on Medium.

This article introduces WorkManager’s model for handling background tasks through WorkRequest objects and sets up a comparison between OneTimeWorkRequest and PeriodicWorkRequest. Based on the provided excerpt, the post appears to be an introductory piece in a larger series, but the full technical details are not included here. The visible text only states that WorkManager handles background tasks as WorkRequest objects and directs readers to continue on Medium.

WorkManager（第 1.2 部分）：OneTimeWorkRequest 与 PeriodicWorkRequest

WorkManager 会将所有后台任务作为 WorkRequest 对象来处理。

重點摘要

WorkManager 使用 WorkRequest 对象来表示后台工作。

本文重点比较 OneTimeWorkRequest 和 PeriodicWorkRequest。

当前提供的内容只有简短引言，完整说明需前往 Medium 查看。

本文介绍了 WorkManager 通过 WorkRequest 对象来处理后台任务的方式，并引出 OneTimeWorkRequest 与 PeriodicWorkRequest 的比较。从目前提供的片段来看，这篇文章应是系列文章中的入门内容，但完整的技术细节并未包含在内。可见文字只说明 WorkManager 会将后台任务视为 WorkRequest 对象，并提示读者继续前往 Medium 阅读。

WorkManager（第 1.2 部分）：OneTimeWorkRequest 與 PeriodicWorkRequest

WorkManager 會將所有背景任務視為 WorkRequest 物件來處理。

重點摘要

WorkManager 以 WorkRequest 物件來表示背景工作。

本文重點在比較 OneTimeWorkRequest 與 PeriodicWorkRequest。

目前提供的內容僅有簡短導言，完整說明需前往 Medium 閱讀。

本文介紹 WorkManager 以 WorkRequest 物件來處理背景任務的方式，並引出 OneTimeWorkRequest 與 PeriodicWorkRequest 的比較。就目前提供的片段來看，這篇文章應屬於系列文章中的入門內容，但完整技術細節未包含在內。可見文字僅說明 WorkManager 會將背景任務視為 WorkRequest 物件，並引導讀者到 Medium 繼續閱讀。

15

Android 17 Is Coming: Is Your Smartphone Ready?

Medium Kotlin 作者：Navas Khan 發布：07-31 14:17

Android 17 Is Coming: Is Your Smartphone Ready?

Google is preparing to roll out Android 17, bringing a smarter, faster, and more secure Android experience.

重點摘要

Google is preparing to roll out Android 17.

The update is described as smarter, faster, and more secure.

AI-powered features are part of the upcoming experience.

Google is preparing to roll out Android 17, positioning it as a smarter, faster, and more secure version of Android. The brief article says the update will include AI-powered features, suggesting a continued focus on improving user experience through intelligence and performance. No further details are provided, but the headline and preview indicate that Android 17 is being presented as an important next step for smartphone users to watch for.

Android 17 即将到来：你的智能手机准备好了吗？

Google 正在准备推出 Android 17，带来更智能、更快速且更安全的 Android 体验。

重點摘要

Google 正在准备推出 Android 17。

这次更新被描述为更智能、更快速且更安全。

预告中提到将加入 AI 驱动功能。

Google 正在准备推出 Android 17，主打更智能、更快速且更安全的 Android 体验。文章预告提到，这次更新将包含 AI 驱动功能，说明 Google 仍在持续强化智能化与性能表现。由于原文内容非常简短，并未提供更多细节；从标题和简介来看，Android 17 被视为智能手机用户值得关注的新版本。

Android 17 即將登場：你的智慧型手機準備好了嗎？

Google 正在準備推出 Android 17，帶來更智慧、更快速且更安全的 Android 體驗。

重點摘要

Google 正在準備推出 Android 17。

這次更新被描述為更智慧、更快速且更安全。

預告中提到將加入 AI 驅動功能。

Google 正在準備推出 Android 17，主打更智慧、更快速且更安全的 Android 體驗。文章預告指出，這次更新將加入 AI 驅動功能，顯示 Google 持續把智慧化與效能提升作為重點。不過內文僅有簡短介紹，未提供更多細節；從標題與摘要來看，Android 17 被視為值得智慧型手機使用者關注的下一個重要版本。

16

Know Kotlin? Ship It Everywhere and Win at Shipaton 2026

Kotlin Blog 作者：Ekaterina Petrova 發布：07-31 13:49

Know Kotlin? Ship It Everywhere and Win at Shipaton 2026

If you know Kotlin, your app idea is closer to the App Store than you think.

重點摘要

Shipaton 2026 runs from August 1 to September 30 as the world’s biggest mobile hackathon.

JetBrains’ Ship Kotlin Everywhere Award rewards Kotlin apps built for multiple platforms with KMP and Compose Multiplatform.

Winners share a $30,000 prize pool, and all entries can still compete for the $100,000 Grand Prize and other categories.

RevenueCat Shipaton 2026 runs from August 1 to September 30, giving Kotlin developers a chance to turn an app idea into a real submission. JetBrains is sponsoring a dedicated Ship Kotlin Everywhere Award for brand-new apps built with Kotlin Multiplatform and Compose Multiplatform across Android, iOS, desktop, and web. Participants do not need to support every platform; judges value effective cross-platform development. The award offers a $30,000 prize pool, while all entries remain eligible for the $100,000 Grand Prize and more than 20 other categories. Builders also get supporting resources such as IntelliJ IDEA Ultimate, Junie access, guides, livestreams, and Discord help.

会 Kotlin？把应用发往各平台，在 Shipaton 2026 取胜

如果你会 Kotlin，你的应用点子离 App Store 比你想象中更近。

重點摘要

Shipaton 2026 是全球最大的移动黑客松，时间为 8 月 1 日到 9 月 30 日。

JetBrains 设立 Ship Kotlin Everywhere Award，鼓励用 Kotlin Multiplatform 和 Compose Multiplatform 做跨平台应用。

奖项总奖金 3 万美元，作品还可继续角逐 10 万美元 Grand Prize 和 20 多个其他类别。

RevenueCat Shipaton 2026 将于 8 月 1 日至 9 月 30 日举行，为熟悉 Kotlin 的开发者提供把应用点子落地的机会。JetBrains 作为金牌赞助商，推出 Ship Kotlin Everywhere Award，鼓励使用 Kotlin Multiplatform 与 Compose Multiplatform 开发全新应用，并将其带到 Android、iOS、桌面和网页等多个平台。评审并不要求覆盖所有平台，而是看重有效的跨平台开发。该奖项总奖金为 3 万美元；与此同时，参赛作品仍可参与 10 万美元 Grand Prize 及 20 多个其他奖项，并可获得 IntelliJ IDEA Ultimate、Junie、指南、直播和 Discord 支持。

會 Kotlin？把作品送上各平台，在 Shipaton 2026 奪獎

如果你會 Kotlin，你的應用程式點子離 App Store 比你想像中更近。

重點摘要

Shipaton 2026 為全球最大行動黑客松，活動時間是 8 月 1 日到 9 月 30 日。

JetBrains 今年設立 Ship Kotlin Everywhere Award，鼓勵用 Kotlin Multiplatform 與 Compose Multiplatform 跨平台開發。

獎金池共 3 萬美元，作品還可同時競逐 10 萬美元 Grand Prize 與其他 20 多個獎項。

RevenueCat Shipaton 2026 將於 8 月 1 日至 9 月 30 日舉行，邀請熟悉 Kotlin 的開發者把點子實作成作品。JetBrains 今年贊助專屬的 Ship Kotlin Everywhere Award，鼓勵以 Kotlin Multiplatform 與 Compose Multiplatform 打造全新應用，並部署到 Android、iOS、桌面與網頁等平台。評審重視跨平台開發的效率與成果，不要求四個平台全數到齊。此獎項總獎金為 3 萬美元；同時，參賽作品也仍可角逐 10 萬美元 Grand Prize 與 20 多個其他獎項，並可獲得 IntelliJ IDEA Ultimate、Junie、指南與直播等資源。

17

A Guide to Short-Term Memory Sessions in Spring AI

Baeldung 作者：Yadier Betancourt 發布：07-30 23:16

A Guide to Short-Term Memory Sessions in Spring AI

Spring AI Session stores conversation history as turn-aware events and compacts it intelligently when it grows too large.

重點摘要

Sessions store immutable, timestamped events instead of a flat message list.

Compaction happens on turn boundaries to avoid breaking tool-call sequences.

SessionMemoryAdvisor connects sessions to ChatClient and supports several compaction strategies.

This tutorial explains Spring AI Session, a short-term memory layer that replaces naive message replay with event-sourced conversation storage. It introduces sessions as ordered streams of immutable SessionEvent objects grouped into turns, which prevents partial eviction of related messages such as tool calls and results. The article shows how to set up the library, create and inspect sessions through SessionService, and wire memory into a ChatClient with SessionMemoryAdvisor. It also compares the available compaction strategies, including sliding-window, turn-window, token-based, and recursive summarization, and demonstrates both automatic and manual compaction.

Spring AI 短期记忆会话指南

Spring AI Session 以按轮次感知的事件保存对话历史，并在内容过多时智能压缩。

重點摘要

会话用不可变、带时间戳的事件流来保存对话。

压缩按 turn 边界进行，避免打断工具调用及其结果。

SessionMemoryAdvisor 可将记忆透明接入 ChatClient，并支持多种压缩策略。

本文介绍了 Spring AI Session 这一短期记忆层，它以事件溯源方式保存对话，而不是简单重复发送全部历史消息。Session 会把 SessionEvent 按 turn 分组，因此当历史过长时，系统会在轮次边界进行压缩，避免将工具调用与其结果拆开。文章还演示了如何用 SessionService 创建和读取会话、通过 SessionMemoryAdvisor 将记忆接入 ChatClient，并比较滑动窗口、轮次窗口、按 token 计数与递归摘要等压缩策略，同时展示了自动压缩和手动压缩的使用方式。

Spring AI 短期記憶工作階段指南

Spring AI Session 以按輪次感知的事件來保存對話歷史，並在內容過多時智慧地壓縮它。

重點摘要

工作階段以不可變、具時間戳的事件串流保存對話。

壓縮會以 turn 為邊界，避免切斷工具呼叫與結果。

SessionMemoryAdvisor 可將記憶透明接入 ChatClient，並支援多種壓縮策略。

本文介紹 Spring AI Session 這個短期記憶層，它以事件來源方式保存對話，不再仰賴把所有訊息逐次重播。Session 以 SessionEvent 串流記錄內容，並依 turn 分組，因此在歷史過長時，系統會沿著輪次邊界壓縮，而不會把工具呼叫與其結果拆散。文章進一步示範如何用 SessionService 建立與查詢工作階段、將 SessionMemoryAdvisor 接到 ChatClient 上，以及比較 sliding window、turn window、token 計數與 recursive summarization 等壓縮策略，並展示自動與手動壓縮的用法。

18

A Guide to Ahead-of-Time Cache in the Java

Baeldung 作者：Bharath Ganesh 發布：07-30 23:21

A Guide to Ahead-of-Time Cache in Java

Ahead-of-Time caching lets the JVM reuse build output so later runs start faster.

重點摘要

JDK 24 introduced AOT cache through JEP 483 as part of Project Leyden.

The workflow can be recorded, created, and run, or simplified into one-step and two-step builds.

Training quality matters: production and training must stay aligned for the cache to help startup time.

This article explains Java’s Ahead-of-Time (AOT) cache and how it can reduce JVM startup time by reusing previously prepared class-loading work. It traces the feature from JDK 24’s initial introduction through later improvements in JDK 25 and JDK 26, then walks through the classic three-phase workflow: record, create, and run. The piece also shows how to build the cache in one step or split the work when memory is limited, and stresses that the cache is only useful when training and production runs stay closely aligned. Finally, it offers practical guidance for building effective training runs, including smoke tests and JFR analysis, along with key best practices for validity, portability, coverage, and setup.

Java 中 Ahead-of-Time 缓存指南

AOT 缓存让 JVM 复用构建结果，从而让后续运行更快启动。

重點摘要

JDK 24 通过 JEP 483 引入 AOT 缓存，后续版本继续增强。

缓存可走记录、创建、运行三阶段流程，也可简化为单步或两步构建。

训练与生产必须尽量对齐，缓存才能真正改善启动时间。

本文介绍 Java 的 Ahead-of-Time（AOT）缓存如何通过复用先前准备好的类加载结果来缩短 JVM 启动时间。文章先回顾该特性自 JDK 24 引入，并在 JDK 25、JDK 26 中持续演进，然后以 record、create、run 三阶段流程展示缓存的生成与使用方式，同时说明可用单步构建缓存，或在内存受限时拆分为多阶段处理。作者强调，训练运行与生产运行必须尽量一致，缓存才会有效；并建议借助 smoke test 和 JFR 找出热点方法，确保训练覆盖真正重要的启动路径。

Java 中的 Ahead-of-Time 快取指南

AOT 快取可讓 JVM 重用建置成果，讓後續執行更快啟動。

重點摘要

JDK 24 透過 JEP 483 引入 AOT 快取，後續版本持續強化。

快取可用記錄、建立、執行三階段流程，或簡化為一階段／二階段建置。

訓練與正式環境需盡量一致，快取才會真正改善啟動時間。

本文介紹 Java 的 Ahead-of-Time（AOT）快取如何透過重用先前準備好的類別載入結果，來縮短 JVM 啟動時間。文章先說明此功能自 JDK 24 起出現，並在 JDK 25、JDK 26 持續演進，接著以三階段的 record、create、run 流程示範快取的運作方式，也說明可用單一步驟建立快取，或在記憶體有限時拆成多階段處理。作者強調，訓練環境與正式環境必須保持一致，快取才有意義；並建議透過 smoke test 與 JFR 找出熱點方法，確保訓練內容涵蓋真正重要的啟動路徑。

19

LLM Integration With Apache Camel OpenAI Component

Baeldung 作者：Burak Gökmen 發布：07-30 23:25

LLM Integration with the Apache Camel OpenAI Component

The Apache Camel OpenAI component, introduced in Camel 4.17, enables integration of Java applications with OpenAI or OpenAI-compatible LLM servers such as Ollama or vLLM.

重點摘要

Uses Camel routes to call LLMs and convert messages between Camel Exchanges and OpenAI requests.

Supports chat-completion and embeddings through the openai:operation URI pattern.

Can retain conversational memory and return structured JSON mapped to Java objects.

This article explains how to integrate Java applications with LLMs using the Apache Camel OpenAI component, introduced in Camel 4.17. It shows the basic URI format, how to send prompts through Camel routes, and how to configure headers or URI options for model selection and temperature. The tutorial also demonstrates switching to OpenAI-compatible endpoints such as a local Ollama server via baseUrl, preserving conversational memory by reusing the same Exchange and enabling conversationMemory, and requesting structured output that can be unmarshaled into a Java POJO. It concludes by noting additional capabilities such as streaming responses and multimodal inputs.

使用 Apache Camel OpenAI 组件集成 LLM

Apache Camel OpenAI 组件在 Camel 4.17 中引入，可让 Java 应用与 OpenAI 或兼容的 LLM 服务器（如 Ollama、vLLM）集成。

重點摘要

通过 Camel 路由与 LLM 交互，并在 Camel Exchange 与 OpenAI 请求之间转换消息。

支持 chat-completion 和 embeddings 两种操作，可通过 URI 或消息头配置模型与参数。

可切换兼容端点、保留对话记忆，并将结构化输出映射为 Java 对象。

本文介绍如何使用 Apache Camel OpenAI 组件将 Java 应用与 LLM 集成。文章从 Camel 4.17 新增的组件讲起，说明 openai:operation 的 URI 格式，以及如何通过 Camel 路由发送提示词、设置模型和温度等参数。随后示范如何把 baseUrl 指向本地 Ollama 等兼容端点，通过复用同一个 Exchange 并开启 conversationMemory 来保留对话上下文，以及利用 outputClass 和 Jackson 将模型响应转换为 Java POJO。最后还提到流式输出和多模态输入等扩展能力。

使用 Apache Camel OpenAI 元件整合 LLM

Apache Camel OpenAI 元件於 Camel 4.17 推出，可讓 Java 應用程式與 OpenAI 或相容的 LLM 伺服器（如 Ollama、vLLM）整合。

重點摘要

透過 Camel route 與 LLM 互動，並在 Camel Exchange 與 OpenAI 請求間轉換訊息。

支援 chat-completion 與 embeddings 兩種操作，可用 URI 或訊息標頭設定模型與參數。

可切換相容端點、保留對話記憶，並將結構化輸出映射為 Java 物件。

本文介紹如何使用 Apache Camel OpenAI 元件將 Java 應用程式與 LLM 整合。文章從 Camel 4.17 新增的元件開始，說明 openai:operation 的 URI 格式，以及如何透過 Camel route 傳送提示詞、設定模型與溫度等參數。接著示範如何把 baseUrl 指向本機 Ollama 等相容端點、透過重用同一個 Exchange 並開啟 conversationMemory 來保留對話上下文，以及用 outputClass 與 Jackson 將模型回應轉成 Java POJO。最後也提到串流輸出與多模態輸入等延伸能力。

20

CTE Support in Hibernate

Baeldung 作者：Graham Cox 發布：07-30 23:28

CTE Support in Hibernate

Hibernate 6.2+ adds CTE support in HQL, enabling named result sets and recursive queries.

重點摘要

CTEs are supported in Hibernate and HQL, not standard JPA.

Basic CTEs can simplify and optimize queries by naming reusable result sets.

Recursive CTEs can traverse hierarchical data such as employee-manager trees.

This article explains how to use Common Table Expressions (CTEs) in Hibernate 6.2+ with HQL. It first defines CTEs as named result sets that make complex queries easier to read and, depending on the database, potentially more efficient. The article then shows setup requirements, including the Hibernate and Spring Boot versions needed, and uses an employee table with a self-referencing manager relationship as the example dataset. It demonstrates basic CTE usage to filter employees by department and salary, then shows a grouped CTE for department average salaries. Finally, it introduces recursive CTEs to query hierarchical relationships, such as all subordinates under a given manager, while noting that UNION avoids duplicates in cyclic data.

Hibernate 中的 CTE 支持

Hibernate 6.2 及以上可在 HQL 中使用 CTE，创建可复用的命名结果集和递归查询。

重點摘要

CTE 是 Hibernate 和 HQL 的能力，不属于标准 JPA。

基础 CTE 能让查询更清晰，并复用中间结果。

递归 CTE 可用于员工-经理这类层级结构查询。

本文介绍如何在 Hibernate 6.2 及以上版本中使用 Common Table Expressions（CTE）。文章先说明 CTE 是可命名的结果集，能让复杂查询更易理解，并且在某些数据库中可能带来更好的执行效率。随后给出使用前提，包括所需的 Hibernate 与 Spring Boot 版本，并以带有自引用 manager 字段的员工表作为示例数据。文中演示了基础 CTE 如何筛选工程部门且薪资超过门槛的员工，也展示了按部门计算平均薪资的聚合 CTE。最后说明递归 CTE 如何查询某个主管之下的所有下属，并指出使用 UNION 而非 UNION ALL 可避免循环数据导致的重复结果。

Hibernate 中的 CTE 支援

Hibernate 6.2 以上可在 HQL 中使用 CTE，建立可重複引用的命名結果集與遞迴查詢。

重點摘要

CTE 是 Hibernate 與 HQL 的功能，不屬於標準 JPA。

基本 CTE 可讓查詢更易讀，並重用中間結果。

遞迴 CTE 可處理員工與主管的階層結構查詢。

本文介紹如何在 Hibernate 6.2 以上透過 HQL 使用 Common Table Expressions（CTE）。文章先說明 CTE 是可命名的結果集，能讓複雜查詢更易讀，且視資料庫最佳化器而定，可能帶來更好的執行效率。接著列出使用前提，包括 Hibernate 與 Spring Boot 版本，並以員工表與自我參照的 manager 欄位作為示例資料。內容示範了基本 CTE 如何篩選工程部門且薪資高於門檻的員工，也展示以部門平均薪資為基礎的彙總查詢。最後進一步說明遞迴 CTE 如何查出某主管底下的所有下屬，並提到使用 UNION 可避免循環資料造成重複列。

21

Building Intelligent Document Processing with Apache Camel, Docling and LangChain4j

Baeldung 作者：Olayemi Michael 發布：07-30 23:35

Building Intelligent Document Processing with Apache Camel, Docling, and LangChain4j

Docling converts documents into a structured format that can be efficiently parsed.

重點摘要

Use Docling to convert PDFs into Markdown for downstream AI use.

Orchestrate the workflow with Apache Camel routes and LangChain4j chat models.

Expose a simple POST Q&A API with embedded Undertow that reuses the converted Markdown.

This tutorial shows how to build an intelligent document processing pipeline with Apache Camel, Docling, and LangChain4j. Docling converts unstructured documents such as PDFs into Markdown, preserving structure that would otherwise be lost in plain text extraction. Apache Camel orchestrates the conversion and analysis workflow, while LangChain4j sends the converted content to an LLM for summarization and analysis. The article also adds an embedded Undertow-based POST API that reads the preprocessed Markdown from disk and answers questions using the document as context, avoiding repeated conversions for each request.

使用 Apache Camel、Docling 和 LangChain4j 构建智能文档处理系统

Docling 可将文档转换为可高效解析的结构化格式。

重點摘要

用 Docling 将 PDF 转为 Markdown，保留文档结构。

通过 Apache Camel 编排转换与分析流程，并接入 LangChain4j。

使用内嵌 Undertow 提供 POST 问答 API，复用已转换内容。

本文介绍如何结合 Apache Camel、Docling 和 LangChain4j 构建智能文档处理流水线。Docling 负责把 PDF 等非结构化文档转换为 Markdown，尽量保留标题、表格和其他语义结构；Apache Camel 用来编排文件转换与分析流程；LangChain4j 则将转换后的内容发送给 LLM 进行摘要和分析。文章还实现了一个基于 Undertow 的 POST 问答 API，直接读取磁盘中的预处理 Markdown 作为上下文，从而避免每次请求都重复转换文档。

使用 Apache Camel、Docling 與 LangChain4j 建立智慧文件處理系統

Docling 可將文件轉換為可高效解析的結構化格式。

重點摘要

用 Docling 將 PDF 轉成 Markdown，保留文件結構。

以 Apache Camel 編排轉換與分析流程，並串接 LangChain4j。

透過內嵌 Undertow 提供 POST 問答 API，重用已轉換內容。

本文示範如何結合 Apache Camel、Docling 與 LangChain4j 建立智慧文件處理流程。Docling 先將 PDF 等非結構化文件轉成 Markdown，盡量保留標題、表格與其他語意結構；Apache Camel 負責路由與檔案處理；LangChain4j 則把轉好的內容送入 LLM 進行摘要與分析。文章最後再加入一個以 Undertow 為基礎的 POST 問答 API，直接讀取磁碟中的預處理 Markdown 作為上下文，避免每次請求都重新轉檔。

22

Kotlin Coroutines: Part 4 — Asynchronous Streams with Kotlin Flows

Medium Kotlin 作者：Fachrizal Mursalin 發布：07-31 00:20

Kotlin Coroutines: Part 4 — Asynchronous Streams with Kotlin Flows

Continue reading on Medium »

重點摘要

The provided content only includes the article title.

No body text is available to extract substantive points.

The article appears to continue on Medium.

The supplied input contains only the article title and a brief prompt to continue reading on Medium, without the actual article content. As a result, no reliable summary of the technical discussion on Kotlin Flows, coroutines, or asynchronous streams can be generated from the provided text alone. Any detailed claims would risk inventing information that is not present in the source.

Kotlin 协程：第 4 部分 — 使用 Kotlin Flow 的异步流

请前往 Medium 继续阅读 »

重點摘要

当前提供的内容只有文章标题。

缺少正文，因此无法提炼具体要点。

原文引导读者到 Medium 查看完整文章。

目前提供的内容只有文章标题和“请前往 Medium 继续阅读”的提示，没有实际正文，因此无法依据原文内容整理出关于 Kotlin Flow、协程或异步流的可靠摘要。若仅凭现有信息生成更多细节，将有虚构事实的风险。

Kotlin 協程：第 4 部分 — 使用 Kotlin Flow 的非同步串流

請前往 Medium 繼續閱讀 »

重點摘要

目前提供的內容只有文章標題。

缺少正文，因此無法擷取具體重點。

原文指向 Medium 上的完整文章。

目前提供的內容只有文章標題與「請前往 Medium 繼續閱讀」的提示，沒有實際正文，因此無法根據原文內容整理出關於 Kotlin Flow、協程或非同步串流的可靠摘要。若僅依現有資訊作答，將難以避免推測或虛構細節。

23

Why Your Offline-First Chat App Duplicates Messages (And How to Actually Fix It)

Medium Kotlin 作者：Android Expert 發布：07-31 04:25

Why Offline-First Chat Apps Duplicate Messages—and How to Fix Them

A distributed systems deep dive into idempotency, transactional outboxes, and Kotlin patterns for reliable Android chat sync.

重點摘要

Explains why offline-first chat apps can create duplicate messages.

Focuses on idempotency and transactional outbox patterns.

Covers Kotlin techniques for reliable Android synchronization.

This article examines why offline-first chat apps can end up duplicating messages and frames the problem as a distributed systems challenge. It points to idempotency and transactional outbox patterns as core tools for preventing repeated sends and inconsistent sync behavior. The piece also discusses Kotlin patterns that help Android apps handle reliable chat synchronization, aiming to make offline-first messaging more robust and less error-prone.

为什么离线优先聊天 App 会重复消息——以及如何真正修复

深入探讨分布式系统中的幂等性、事务型 outbox 与 Kotlin 模式，打造可靠的 Android 聊天同步。

重點摘要

解析离线优先聊天 App 为何会出现重复消息。

聚焦幂等性与事务型 outbox 设计。

介绍提升 Android 同步可靠性的 Kotlin 实践模式。

本文探讨离线优先聊天 App 为什么会出现消息重复，并将其归结为分布式系统中的一致性问题。文章指出，幂等性与事务型 outbox 是避免重复发送和同步异常的关键思路，同时还提到可用于 Android 聊天同步的 Kotlin 模式，帮助开发者构建更可靠、错误更少的离线优先消息体验。

為什麼離線優先的聊天 App 會重複訊息——以及如何真正修正

深入探討分散式系統中的冪等性、交易式 outbox 與 Kotlin 模式，打造可靠的 Android 聊天同步。

重點摘要

解析離線優先聊天 App 為何會產生重複訊息。

聚焦冪等性與交易式 outbox 設計。

介紹提升 Android 同步可靠性的 Kotlin 實作模式。

本文探討離線優先聊天 App 為何會出現訊息重複，並將問題視為分散式系統中的一致性挑戰。文章指出，冪等性與交易式 outbox 是避免重送與同步錯亂的關鍵概念，同時也提到可用於 Android 聊天同步的 Kotlin 模式，協助開發者打造更可靠、較不易出錯的離線優先訊息體驗。

24

Chaos Wall — I turned chaos theory into a live wallpaper

Medium Kotlin 作者：TheAbbie 發布：07-31 05:41

Chaos Wall — I turned chaos theory into a live wallpaper

A live wallpaper built from chaos theory.

重點摘要

The article presents a live wallpaper inspired by chaos theory.

The project is titled Chaos Wall.

The provided text contains no further article details.

The post is titled “Chaos Wall — I turned chaos theory into a live wallpaper” by TheAbbie. Based on the provided content, the article appears to introduce a live wallpaper project inspired by chaos theory. However, the supplied excerpt does not include the body of the article, only a prompt to continue reading on Medium, so no additional technical details, implementation notes, or conclusions can be confirmed from the source text.

Chaos Wall —— 我把混沌理论做成了动态壁纸

一款以混沌理论为灵感的动态壁纸。

重點摘要

文章介绍了一款受混沌理论启发的动态壁纸。

项目名称为 Chaos Wall。

当前提供的内容没有更多正文细节。

这篇文章题为〈Chaos Wall —— I turned chaos theory into a live wallpaper〉，作者为 TheAbbie。根据现有内容，文章主要是在介绍一个以混沌理论为概念制作的动态壁纸项目。但所提供的正文只有“Continue reading on Medium »”提示，没有实际文章段落，因此无法从这份来源确认更多技术细节、实现过程或结论。

Chaos Wall —— 我把混沌理論做成了動態桌布

以混沌理論打造的動態桌布。

重點摘要

文章介紹一個受混沌理論啟發的動態桌布。

作品名稱為 Chaos Wall。

目前提供的內容未包含更多文章細節。

這篇文章標題為〈Chaos Wall —— I turned chaos theory into a live wallpaper〉，作者是 TheAbbie。依照目前提供的內容，文章主要是在介紹一個以混沌理論為概念的動態桌布專案。不過，所附內文只有「Continue reading on Medium »」的提示，沒有實際文章段落，因此無法從這份來源確認更多技術細節、實作方式或結論。

25

Hardening Android Apps: Secure Request Signing with EC Keys

Medium Kotlin 作者：Khizar Khan 發布：07-31 05:49

Hardening Android Apps: Secure Request Signing with EC Keys

Part 5 of the KNewsApp series — documenting the architecture decisions behind a modular, security-first Android news app.

重點摘要

Part of the KNewsApp series

Focuses on architectural decisions

Covers a modular, security-first Android news app

This article is the fifth part of the KNewsApp series and focuses on the architecture decisions behind building a modular, security-first Android news app. It specifically frames the topic around hardening Android apps and secure request signing with EC keys. The provided text does not include the full article content, so the available details only indicate the series context and the main security-oriented theme.

加固 Android 应用：使用 EC 密钥进行安全请求签名

KNewsApp 系列的第 5 部分——记录这款模块化、以安全为先的 Android 新闻应用背后的架构决策。

重點摘要

KNewsApp 系列的第 5 部分

聚焦架构决策

面向模块化、以安全为先的 Android 新闻应用

这篇文章是 KNewsApp 系列的第五部分，主要记录在构建一款模块化、以安全为先的 Android 新闻应用时所做的架构决策。标题表明文章讨论的是如何加固 Android 应用，以及如何使用 EC 密钥进行安全的请求签名。不过当前提供的内容只有简短说明，没有完整正文，因此能够确认的信息仅限于系列背景与安全主题。

強化 Android 應用程式：使用 EC 金鑰進行安全請求簽章

KNewsApp 系列的第 5 部分——記錄這款模組化、以安全為優先的 Android 新聞應用程式背後的架構決策。

重點摘要

KNewsApp 系列的第 5 部分

聚焦於架構決策

主題為模組化、以安全為優先的 Android 新聞應用程式

這篇文章是 KNewsApp 系列的第五部分，主題聚焦於打造一款模組化、以安全為優先的 Android 新聞應用程式時所做的架構決策。標題指出文章討論的是如何強化 Android 應用程式，並以 EC 金鑰進行安全的請求簽章。不過目前提供的內文只有簡短說明，未包含完整文章，因此可確認的資訊主要是系列脈絡與安全導向的主題。

26

Polishing the UI: Shared Element Transitions and Custom Shimmers

Medium Kotlin 作者：Khizar Khan 發布：07-31 05:54

Polishing the UI: Shared Element Transitions and Custom Shimmers

Part 6 of the KNewsApp series.

重點摘要

Part 6 of the KNewsApp series

Focuses on UI polish through transitions and loading effects

Continue reading on Medium

This article is Part 6 of the KNewsApp series and is titled “Polishing the UI: Shared Element Transitions and Custom Shimmers.” Based on the provided text, it appears to introduce a continuation of the series and points readers to the full post on Medium. The excerpt does not include further technical details, so the only confirmed information is that this installment belongs to the KNewsApp project and focuses on UI refinement topics mentioned in the title.

打磨 UI：共享元素转场与自定义 Shimmer 效果

KNewsApp 系列第 6 部分。

重點摘要

KNewsApp 系列第 6 部分

主题聚焦 UI 打磨、转场与加载效果

可前往 Medium 阅读完整内容

这篇文章是 KNewsApp 系列的第 6 部分，标题为《打磨 UI：共享元素转场与自定义 Shimmer 效果》。根据目前提供的内容，正文仅说明这是系列中的一篇，并引导读者到 Medium 继续阅读。由于摘录非常简短，没有更多技术细节可供整理，因此能够确认的信息只有：本文属于 KNewsApp 项目，并围绕标题所示的 UI 优化主题展开。

打磨 UI：共享元素轉場與自訂 Shimmer 效果

KNewsApp 系列第 6 部分。

重點摘要

KNewsApp 系列第 6 部分

主題聚焦 UI 打磨與轉場、載入效果

可前往 Medium 閱讀完整內容

這篇文章是 KNewsApp 系列的第 6 部分，標題為〈打磨 UI：共享元素轉場與自訂 Shimmer 效果〉。就目前提供的內容來看，內文僅說明這是系列文章的一部分，並引導讀者前往 Medium 繼續閱讀。由於摘錄篇幅極短，未包含更多技術細節，因此可確認的資訊只有：本文屬於 KNewsApp 專案，並聚焦於標題所提到的 UI 精緻化主題。

27

Android 16'ya Geçiş: targetSdkVersion 36 Öncesi Bilmemiz Gerekenler

Medium Kotlin 作者：Burak Barlık 發布：07-31 07:10

Android 16 Transition: What to Know Before targetSdkVersion 36

Starting August 31, 2026, Google Play will require apps to target Android 16 (API 36) for new submissions and updates.

重點摘要

Google Play will enforce Android 16 targeting from August 31, 2026.

New app submissions and updates must meet targetSdkVersion 36 requirements.

The article is a brief notice pointing developers to the upcoming policy change.

Google Play will require new submissions and updates to target Android 16 (API 36) starting on August 31, 2026. The article serves as a short notice for developers preparing for the targetSdkVersion 36 transition and emphasizes the policy deadline. No additional technical details are provided in the excerpt beyond the requirement itself.

迁移到 Android 16：在 targetSdkVersion 36 前需要了解的事

自 2026 年 8 月 31 日起，Google Play 将要求新提交和更新必须以 Android 16（API 36）为目标版本。

重點摘要

Google Play 将从 2026 年 8 月 31 日起强制目标版本为 Android 16。

新的应用提交和更新都必须满足 targetSdkVersion 36 要求。

文章摘录主要是在提醒开发者即将到来的政策变化。

Google Play 将从 2026 年 8 月 31 日起要求新提交和更新的应用必须以 Android 16（API 36）为目标版本。本文摘录是一则面向开发者的提醒，重点在于 targetSdkVersion 36 的切换期限与平台政策要求；除这项强制规定外，片段中未提供其他技术细节。

升級到 Android 16：targetSdkVersion 36 前必須知道的事

自 2026 年 8 月 31 日起，Google Play 將要求新提交與更新必須以 Android 16（API 36）為目標版本。

重點摘要

Google Play 將自 2026 年 8 月 31 日起強制目標版本為 Android 16。

新的應用提交與更新都必須符合 targetSdkVersion 36 要求。

本文摘錄主要是在提醒開發者即將到來的政策變更。

Google Play 將自 2026 年 8 月 31 日起，要求新提交與更新的應用必須以 Android 16（API 36）為目標版本。本文摘錄屬於開發者提醒，重點在於 targetSdkVersion 36 的切換期限與政策要求；除這項強制規定外，內文片段未提供其他技術細節。

今日總結

我如何打造一款 App 來解決 Google Play「12 位測試者、14 天」的要求

重點摘要

打造 Android 地理圍欄引擎：在耗電與精準之間取捨

重點摘要

Kdrant 2.0：我不再需要官方客戶端的理由

重點摘要

超越語意樹：用 snapshotFlow 測試 Compose 內部狀態

重點摘要

Android 架構正悄悄超越將 ViewModel 作為狀態容器

重點摘要

十分鐘認識 Kotlin UUID

重點摘要

GitHub Cruise：生產級 Android 架構——乾淨分層、離線優先、型別安全錯誤

重點摘要

為什麼我們選擇 KMP 而不是 React Native：這是一場架構上的押注，而非框架偏好

重點摘要

為什麼需要 WorkManager（第 1.1 部分）

重點摘要

Android 離線同步的正確做法：經過測試的遷移、Outbox 佇列與 WorkManager

重點摘要

穩健 Android 應用程式的支柱：第 3 部分

重點摘要

Android 基礎結構解析

重點摘要

多模組 Android 應用中的 ProGuard：它是什麼、如何運作，以及如何除錯正式環境…

重點摘要

WorkManager（第 1.2 部分）：OneTimeWorkRequest 與 PeriodicWorkRequest

重點摘要

Android 17 即將登場：你的智慧型手機準備好了嗎？

重點摘要

會 Kotlin？把作品送上各平台，在 Shipaton 2026 奪獎

重點摘要

Spring AI 短期記憶工作階段指南

重點摘要

Java 中的 Ahead-of-Time 快取指南

重點摘要

使用 Apache Camel OpenAI 元件整合 LLM

重點摘要

Hibernate 中的 CTE 支援

重點摘要

使用 Apache Camel、Docling 與 LangChain4j 建立智慧文件處理系統

重點摘要