search

luojilab / DDComponentForAndroid

一套完整有效的android组件化方案，支持组件的组件完全隔离、单独调试、集成调试、组件交互、UI跳转、动态加载卸载等功能
MIT License
3.34k stars 570 forks source link

大佬，跳转的时候，如何附带 Intent.FLAG？ #105

Open zomll opened 6 years ago

zomll commented 6 years ago

大佬，跳转的时候，如何附带 Intent.FLAG？

xiaojinzi123 commented 5 years ago

大佬，跳转的时候，如何附带 Intent.FLAG？

建议使用 Component,这个库很久不维护了 Component 库中附带 Intent.FLAG 可以使用如下的 intentConsumer 去拿到 intent,你也可以使用自定义跳转,那样子你也可以拿到 Intent,具体请看 Component

Router.with(this).host(xxx).path(xxx).intentConsumer(ccc).....
leobert-lan commented 5 years ago

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题

:octocat: From gitme Android

xiaojinzi123 commented 5 years ago

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题

:octocat: From gitme Android

当初我是学习的态度来看代码的,然后仿造这个项目写,最终一年过来了,我发现这里面其实好多个点有些问题的,当然了可能每个人看法不同,我对那些有问题的要不就是修复了,要不就是去掉了,然后我看到 美团和其他路由框架有页面拦截器这个概念我也吸收进来了,然后我还支持了自定义跳转,通过RxJava 方式拿 onActivity 数据,路由手动和自动取消,具体的我还是希望大佬您能去看下 Component

YummyLau commented 5 years ago

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题

:octocat: From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。 但是我一直的想法是 “路由的方案真的是最好的吗？” 通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。 无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

xiaojinzi123 commented 5 years ago

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题 :octocat: From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。 但是我一直的想法是 “路由的方案真的是最好的吗？” 通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。 无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

实现组件化, 其实最关键是解决跨组件的调用. 一个纯跨组件调用的框架是 CC, 它没有路由的概念. 就是帮助你实现跨组件调用 另外的就是路由方面的框架了

等等都是基于 URI 设计的路由框架. 跨组件调用采用的是 SPI 的思想.

而你说的, 接口不需要下沉就可以实现调用, 除非你像 CC 利用字符串去跨组件. 否则你怎么可能不引用到具体的接口.

调用一个其他模块的具体功能, 你总得给这个功能起个别名或者直接接口暴露给人家, 否则我实在想不出, 这两种都不用可以实现调用另一个模块的功能

最后一点, 我实现想不出你为何说路由没有必要, 你是做何种考虑。你请求后台接口还是写死的 path 呢, 这其实就是一种解耦的方式. 配合配套的插件其实也不会有维护难的问题. 况且, 基于 URI 我看来为什么比其他方案好,

我个人感觉, 技术没有错, 但是我觉得很多时候要考虑的大一点. 有兴趣的话你可以去抓包一下很多 App 的接口. 你会发现他们下发的 path 很多都是基于 URI 的.

leobert-lan commented 5 years ago

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题 :octocat: From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。 但是我一直的想法是 “路由的方案真的是最好的吗？” 通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。 无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

实现组件化, 其实最关键是解决跨组件的调用. 一个纯跨组件调用的框架是 CC, 它没有路由的概念. 就是帮助你实现跨组件调用 另外的就是路由方面的框架了

* Component

* ARouter

* WMRouter

* ActivityRouter

等等都是基于 URI 设计的路由框架. 跨组件调用采用的是 SPI 的思想.

而你说的, 接口不需要下沉就可以实现调用, 除非你像 CC 利用字符串去跨组件. 否则你怎么可能不引用到具体的接口.

调用一个其他模块的具体功能, 你总得给这个功能起个别名或者直接接口暴露给人家, 否则我实在想不出, 这两种都不用可以实现调用另一个模块的功能

最后一点, 我实现想不出你为何说路由没有必要, 你是做何种考虑。你请求后台接口还是写死的 path 呢, 这其实就是一种解耦的方式. 配合配套的插件其实也不会有维护难的问题. 况且, 基于 URI 我看来为什么比其他方案好,

* 是因为 URI 是一个跨语言、跨平台的概念. 如果有一天 IOS 团队也基于 URI 来设计组件化, 那么两端的表现可以是一样的

* URI 天然和 H5 能结合

* URI 这种形式对于后台的配置也更为简单, 只要保存对应的字符串就可以了

我个人感觉, 技术没有错, 但是我觉得很多时候要考虑的大一点. 有兴趣的话你可以去抓包一下很多 App 的接口. 你会发现他们下发的 path 很多都是基于 URI 的.

组件化和路由机制是两个范畴但经常联系在一起谈的东西，组件化研究的是业务的划分解耦，组件的拆分归纳，组件的独立部署和被集成，组件间交互；路由研究的是服务分发、服务注册、以及分发环节中的拦截、降级、错误处理；

如你所说，组件间交互确实是很重要的一环，但基于URI的路由机制并不是解决这一个环节的必要条件，而是一个很成熟、能够避免一些问题的解决方案，理论上，一套能解决服务注册+服务发现+服务调用的解决方案是必要条件。这样的一种机制我们可以广义的、笼统的、不严谨的都称之为路由方案，但不一定是基于URI的，在以前，我习惯称之为：一种IoC容器。

那么基于URI的路由方案有啥特殊好处呢：

有好处当然也有坏处，坏处就是你要维护你可能写死的、hardcode的语法式（URI）

按照伟大的神棍卡尔-马克思的想法，这玩意只要能解决我们的问题，那就可以拿来用，至于里面用不着的东西，爱扔扔

@YummyLau @xiaojinzi123

YummyLau commented 5 years ago

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题 :octocat: From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。 但是我一直的想法是 “路由的方案真的是最好的吗？” 通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。 无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

实现组件化, 其实最关键是解决跨组件的调用. 一个纯跨组件调用的框架是 CC, 它没有路由的概念. 就是帮助你实现跨组件调用 另外的就是路由方面的框架了

  • Component
  • ARouter
  • WMRouter
  • ActivityRouter

等等都是基于 URI 设计的路由框架. 跨组件调用采用的是 SPI 的思想.

而你说的, 接口不需要下沉就可以实现调用, 除非你像 CC 利用字符串去跨组件. 否则你怎么可能不引用到具体的接口.

调用一个其他模块的具体功能, 你总得给这个功能起个别名或者直接接口暴露给人家, 否则我实在想不出, 这两种都不用可以实现调用另一个模块的功能

最后一点, 我实现想不出你为何说路由没有必要, 你是做何种考虑。你请求后台接口还是写死的 path 呢, 这其实就是一种解耦的方式. 配合配套的插件其实也不会有维护难的问题. 况且, 基于 URI 我看来为什么比其他方案好,

  • 是因为 URI 是一个跨语言、跨平台的概念. 如果有一天 IOS 团队也基于 URI 来设计组件化, 那么两端的表现可以是一样的
  • URI 天然和 H5 能结合
  • URI 这种形式对于后台的配置也更为简单, 只要保存对应的字符串就可以了

我个人感觉, 技术没有错, 但是我觉得很多时候要考虑的大一点. 有兴趣的话你可以去抓包一下很多 App 的接口. 你会发现他们下发的 path 很多都是基于 URI 的.

你没有好好看 https://github.com/YummyLau/ComponentPlugin 的文档。确实是不需要下沉就能解决。你说的没错，但是对于组件来说router确实是非必要的。 leobert-lan 的回答很对。

YummyLau commented 5 years ago

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

xiaojinzi123 commented 5 years ago

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

上面说了, 组件化的核心其实就是解决跨组件调用的都可称为组件化. 侧重点不同, 我们基于 URI 的是更多的关注路由方面. 跨组件调用也是支持的. 而你们可能是把跨组件调用做的更好.

另外你加我 347837667, 我和你聊一下你的这个项目. 我觉得我会给你一些好的建议了, 这里我就不回复了

YummyLau commented 5 years ago

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

上面说了, 组件化的核心其实就是解决跨组件调用的都可称为组件化. 侧重点不同, 我们基于 URI 的是更多的关注路由方面. 跨组件调用也是支持的. 而你们可能是把跨组件调用做的更好.

另外你加我 347837667, 我和你聊一下你的这个项目. 我觉得我会给你一些好的建议了, 这里我就不回复了

嗯嗯 ，一起交流 :blush: :blush:

YummyLau commented 5 years ago

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

上面说了, 组件化的核心其实就是解决跨组件调用的都可称为组件化. 侧重点不同, 我们基于 URI 的是更多的关注路由方面. 跨组件调用也是支持的. 而你们可能是把跨组件调用做的更好.

另外你加我 347837667, 我和你聊一下你的这个项目. 我觉得我会给你一些好的建议了, 这里我就不回复了

加了你微信呢～ 你留意下哈，我木有扣扣