为什么小部件中不支持自定义视图？

Question

我不明白，为什么Google在设计小部件时决定不实现对自定义视图的支持，甚至不支持对支持库中捆绑的视图的支持，而是决定依赖RemoteViews

小部件是用户与应用程序交互的重要组成部分，我敢肯定，由于这一限制，许多开发人员发现自己不得不更改计划

是否有特定的原因，也许与表演有关？

例如，现在我想在一个小部件中实现一个回收站视图，但我不能实现，而且我不明白为什么要设计一个这么多的样板代码必须如此困难

Answer 1

  

小部件是用户与应用程序互动的重要组成部分

很少有应用实现应用小部件。

  

是否有这样做的特定原因

应用小部件的宿主（例如主屏幕/启动器）和应用小部件的发布者都需要就可以使用哪些UI元素以及如何配置它们达成一致。

例如，您似乎想使用RecyclerView。很好，但是您的应用程序不呈现应用程序小部件。主机是需要呈现应用程序小部件的UI的主机。因此，如果您使用RecyclerView，则您的应用程序小部件将在所有缺少RecyclerView对应用程序小部件的支持的主机上失败。这包括：

• 自引入RecyclerView以来尚未更新的所有主机（例如，旧设备上的主屏幕）

• 所有不费事地捆绑在其应用程序中的RecyclerView中的主机

• 所有不费吹灰之力地捆绑在一起的主机将导致应用程序小部件渲染支持RecyclerView

在成百上千的主机以及成千上万的应用程序小部件之间，这种协调变得非常复杂。

加上，它在哪里停止？您认为使用RecyclerView是合理的，而下一个人会认为使用Facebook的Litho是合理的，此后的人会认为使用Android Arsenal上的一些晦涩的自定义View是合理的。

确保此协议的简单方法是在框架类中使用通用定义，例如RemoteViews，因此在主机和应用程序小部件提供程序之间有一个保证一致的定义。但是，RemoteViews很难以向后兼容的方式进行更改，这就是Google迄今为止仅进行一次（API级别11，引入了基于AdapterView的选项，例如{ {1}}）。框架类对库一无所知，例如那些提供ListView或Litho的库。