3个activity的故事

本文讨论了在Android应用中,从Activity A通过过渡Activity B向Activity C传递数据,并最终将数据回传给A的方法。介绍了如何使用startActivityForResult及setResult实现这一过程。

A,B,C三个activity,B是过度activity

点A进入B,B加载,加载完成后,进入C

起初方案,A进入B后,B在加载,加载完成,B startActivityForResult C,B finish,进入C

但是这样子C的数据无法回传给A

后来改为A startActivityForResult B,B startActivityForResult C,然后C 结束的时候把intent数据回传给B,B收到数据之后setResult(Result_ok,intent),然后B finish,达到了预期的效果。intent数据必须传2次,B在传给A之后才finish.

<think>嗯,用户想了解或参与软件开发和IT项目中的协作设计活动。首先,我需要明确协作设计活动的定义和关键要素。根据之前的引用,比如引用[2]提到了敏捷开发中沟通模板的重要性,这可能与协作设计中的沟通机制有关。 协作设计活动通常涉及多个角色,如开发人员、设计师、产品经理等。需要确保各方的需求被充分理解和整合。这里可能需要参考用户提到的敏捷开发中的沟通方法,比如使用用户故事或原型设计。比如引用[2]中的沟通模板,可能帮助团队成员有效协作。 接下来,用户可能想知道如何参与这样的活动。可能需要介绍常见的协作设计方法,比如设计工作坊、头脑风暴会议,或者使用协作工具如Miro、Figma。同时,用户可能关心最佳实践,比如如何促进有效沟通,避免误解,这可以引用敏捷中的每日站会或迭代评审会议。 另外,用户的问题可能还涉及协作设计中的挑战,比如如何处理不同意见或冲突。这时候可以提到利益相关者管理,或者使用决策矩阵等工具来达成共识。引用[1]中的业务需求,说明协作设计需要始终围绕业务目标展开,确保所有设计决策符合项目初衷。 最后,生成相关问题时要覆盖用户可能进一步想了解的内容,比如具体工具推荐、成功案例,或者如何衡量协作设计的效果。需要确保问题全面,帮助用户深入探索该主题。</think>### 协作设计活动(Collaborative Design Activity)解析 协作设计活动在软件开发和IT项目中指**多方利益相关者共同参与系统设计、需求分析和方案决策的过程**,强调跨职能团队通过结构化沟通达成共识[^2]。以下是关键要素和实践方法: --- #### 一、协作设计核心流程 1. **需求对齐阶段** - 使用可视化工具(用户旅程图、业务流程图)明确业务目标[^1] - 开展需求工作坊(Requirement Workshop)收集多方视角 - 示例工具: ```mermaid graph TD A[业务代表] -->|提供业务规则| B(需求白板) C[技术团队] -->|评估可行性| B D[用户体验师] -->|提出交互需求| B ``` 2. **方案共创阶段** - 采用设计思维(Design Thinking)方法: - 发散:脑暴会议生成$n\geq10$种设计方案 - 收敛:使用$Kano\模型$进行需求优先级排序 - 技术原型验证:通过$Mockup/线框图$快速验证可行性 3. **决策固化阶段** - 制定**决策日志(ADR, Architecture Decision Record)** - 使用$权重评分矩阵$量化评估方案: $$ Score = \sum_{i=1}^k (w_i \times s_i) $$ 其中$w_i$为权重,$s_i$为方案得分 --- #### 二、关键协作技术 | 技术类型 | 具体方法 | 适用场景 | |----------------|-----------------------------------|--------------------------| | 同步协作 | 实时结对编程、Miro在线白板 | 详细设计阶段 | | 异步协作 | Confluence文档评审、Git版本控制 | 分布式团队协作 | | 决策支持 | 多标准决策分析(MCDA) | 架构方案选择 | | 需求可视化 | C4模型、事件风暴(Event Storming)| 复杂系统边界界定 | --- #### 三、成功要素与挑战 1. **有效实践**: - 建立共享语义:例如统一领域驱动设计(DDD)术语表[^3] - 实施持续反馈:每日站会(Daily Standup)+迭代展示 - 使用AI辅助工具:如自动生成UML图的AI建模工具[^3] 2. **典型风险**: - 需求蔓延(Requirement Creep):通过$MoSCoW法则$控制范围 - 技术债务累积:在协作中强制加入技术可行性审查环节 --- #### 四、参与路径建议 1. **新手切入点**: - 参与开源项目的RFC(Request for Comments)讨论 - 在敏捷团队的Sprint Planning会议中观察设计决策过程 2. **能力进阶**: - 考取CSPO(Certified Scrum Product Owner)认证 - 学习TOGAF架构框架中的协作设计方法论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值