baodan/adapt.native.md at master

#	问题	修复	文件
1	前端构建失败（引号错误）	size="small type=" → size="small" type="	PosterHistoryPage.vue
2	migrate_014 ORM vs 缺失列	全部改为原始 SQL，不再引用 ORM 模型	migrate_014.py
3	cleanup 字段名错误	output_path → ppt_path	cleanup.py
4	文案生成 case 越权	添加 case.user_id != user_id 校验	poster/service.py
5	存储路径未接通持久化卷	全部改用 get_storage_root()（默认 /app/api/storage/insurance）	config.py, ppt/routes.py, poster/service.py, poster/tasks.py
高风险问题修复
#	问题	修复	文件
6	migrate_019 rollback 撤销成功字段	每个 ALTER 后立即 commit，失败只回滚当前语句	migrate_019.py
7	迁移锁 Windows 不兼容 + 句柄未持久化	全局变量保存锁句柄，支持 Windows msvcrt	api/insurance/db/__init__.py
8	PDF 校验异常时放行	异常返回 False（文件损坏）	security.py
9	健康检查始终返回成功	缺少关键资源时返回 503 + missing 列表	poster/routes.py
10	短密钥掩码泄露原值	≤4 字符返回 ****	ppt_admin_service.py
11	设置无键名白名单	添加 _ALLOWED_SETTING_KEYS 白名单	ppt_admin_service.py
12	容器重启任务永久 stuck	添加 recover_stale_tasks() 启动恢复函数	poster/tasks.py, ppt/parse_worker.py

2026-07-27 13:52:09 +08:00

3.8 KiB

Raw Permalink Blame History

Additional context needed: target platforms/devices and usage contexts.

Adapt an existing native design (ios / android / adaptive) to a different context: another device class, orientation, platform, or origin. The trap is treating adaptation as scaling. The job is rethinking the experience for the new context, inside the platform conventions of ios.md / android.md; read the target platform's reference before planning if Setup hasn't already.

Assess Adaptation Challenge

Source context: what was it designed for, and what assumptions did it make? (Phone-only? Portrait-only? One platform's idioms? A website?)
Target context: which device class (phone, tablet, foldable), orientation, platform, and usage posture (one-handed on the go vs two-handed at rest)?
What breaks: navigation that doesn't fit the target, layouts that stretch instead of restructure, gestures or controls that don't exist there?

Adaptation Strategies

Phone → Tablet (iPad / large screens)

Restructure, don't stretch. A scaled-up phone UI on a tablet is the failure mode. Use size classes (iOS) / window size classes (Android) to switch structure.
Navigation changes shape: tab bar stays or becomes a sidebar on iPad; Android navigation bar becomes a rail or drawer on expanded width.
Use the width: split view / master-detail (list + detail side by side), multi-column grids, popovers where phones used sheets.
Multitasking is a size, not an edge case: iPad Split View and Android multi-window can hand you a phone-width window on a tablet; size-class-driven layout handles both for free.

Orientation & foldables

Landscape restructures (side-by-side panes, repositioned controls); never clip or letterbox. Lock orientation only when the task truly demands it.
Foldables (Android): react to posture and hinge via window size classes; test folded, unfolded, and tabletop.

Platform → platform (iOS ↔ Android)

Translate idioms; never transplant them:

iOS	Android
Tab bar	Navigation bar / rail / drawer
Edge-swipe back, back chevron	Predictive Back gesture / button
Switch, segmented control, system pickers	Material switch, chips, Material pickers
Action sheet	Bottom sheet / Material dialog
SF Symbols, SF Pro, Dynamic Type	Material Symbols, Roboto, sp scaling
Semantic system colors, materials	Material color roles, tonal elevation
System push/sheet transitions	Container transform, shared-axis, fade-through

Rebuild navigation and controls in the target's vocabulary; carry over the brand's expressive layer (palette intent, type accent, motion personality) through the target's theming system.

Web → native (porting a website or web app)

Reconform, don't reflow. Replace web navigation with the platform's model, HTML-shaped controls with platform controls, hover affordances with touch-first ones, and px-based type with Dynamic Type / sp. Then treat the result to the full platform reference; the slop test there is the acceptance bar.

Implement & Verify

Drive structure from size classes / window size classes, never from device-model checks.
Respect safe areas and window insets in every new configuration (notch, hinge, status bar, keyboard).
Test on simulators for breadth, then real hardware for truth: at least one phone and one tablet per shipped platform, both orientations, split-screen where supported.

When the adaptation feels native to each context, hand off to /impeccable polish for the final pass.

NEVER:

Ship a stretched phone layout on a tablet
Port one platform's controls or navigation onto the other
Hide core functionality on smaller devices (if it matters, make it work)
Lock orientation to dodge a layout bug
Trust simulators alone (posture, gestures, and performance need hardware)

3.8 KiB Raw Permalink Blame History