BREW MIME机制与Android Activity Intent机制的比较

首先两个不同的平台的这两个机制，都是非常棒的设计理念，解耦了各个组件/模块间的运行时交互。相比而言，Android的Activity/Intent机制更加优美，以Mash Up（搭积木）的编程方式，真正做到了面向组件编程和组件的动态化。

 

首先来看看BREW的MIME机制， Server注册某个Mime Type，成为相应的Handler， Client在不需要了解Server任何信息的情况下，可以通过向ISHELL请求，完成某个功能，ISHELL运行时动态的查询出符合要求的Target，将相应的Request转发给Target。

 

BREW中的MIME机制更多的被用在应用上，从而可以避免事件的泛滥，并且透明的复用其他应用的功能，这是通过ISHELL_Post/SendURL来实现的。将原本应用间的多对多的复杂关系，转变为多对一（App->IShell）的关系，这很明显是一个中介者（Meditor）模式。但是BREW中的这种复用模式，还是有局限的，主要是：

a。 透明的复用只限于App层次，不能深入到组件层次， 虽然，对于组件，仍然可以基于MIME机制查询后动态创建，但是，Client必须引用一个组件的接口，即Client至少需要知道不同组件的不同接口。 比如，虽然可以使用基于MIME Type的方式查询出image/jpg对应的handler的clsid，从而动态的创建它。 但是，Client必须事先清楚创建后的是一个IImage接口实例。

 

b。App级别的功能复用，没有标准的反馈机制， 比如 ISHELL_SendURL/PostURL都只是单向的，并不能从Server处获取操作的结果。 这使得各个App，OEM不得不自己定义相应的机制来实现。

 

c。 App级别功能复用时，传递的信息很有限， 只能是单字节流，即char*， 如果是复杂数据类型的话，必须进行BASE64编码转换

 

 

再来看看Android， 那才是真正的Mash Up式编程， Android中没有显式的应用概念，只有组件的概念。 所以， Android是真正意义上的面向组件编程。 当你将UI上的一个个独立界面实现为一个个独立的Activity，并关联上相应的Action即可。  运行上，当需要请求/复用一个现有功能时，你只需将相应的需求整合成一个Intent对象，然后调用系统的StartActivity（Intent）即可，系统会自动的根据Intent中包含的Action等信息，查询符合的Activity组件（相应的Activity组件在AndroidManifest.xml配置文件中声明），然后创建之（如果不存在实例的话），并将Intent转交给它（通过GetIntent，或者OnNewIntent），Target Activity响应之。  这里，我们也来对比BREW中的3点，看看Android的优势所在

 

a。 透明的功能复用（Mash Up式编程）基于组件层次，而不是应用层次。 当基于Intent请求系统启动一个Activity时，可能是自己应用的一个Activity，或者是另外一个应用的Activity，都可以， 对于Android而言，一切都是组件。 复用的粒度是组件，而不是应用。 这绝对是一个开创， 之前应该几乎没有平台可以这样来编程

 

b。 组件的功能复用存在反馈机制， 可以使用StartActivityForResult来显式的启动一个Activity并等待反馈

 

c。 组件及的功能复用时，传递的信息很广泛，从基本的Action，Group，Data，Extra，甚至可以传入一个Bundle对象来指代任意的对象。

 

 

总而言之，两个平台都实现了模块间的运行时动态，透明的功能复用，  只是Android实现的更棒，更彻底~~~