最近，我遇到了一个问题，即我“构思良好”的视图设计没有合理缩小。我意识到，在Eclipse工作台窗口中以任意大小的堆栈排列视区的灵活性并不能完全简化吸引人的UI的开发。至少，如果您争取围绕列表，表或树进行的一系列操作之外，则要付出更多努力。

幸运的是，由于我们计划对codeaffine.com进行全面检查，因此我还花了一些时间进行响应式网页设计。从那时起，我想到了通过对大小调整做出更快速响应来“拯救” UI概念的想法。结果看起来很有希望，我决定分享经验（和GitHub gist的代码），尽管这些东西有些实验性¹ 。

搭建舞台

首先，您可能会观看这段简短的视频（10秒），该视频演示了我对“尺寸调整的响应”的含义：

该示例显示了一个虚构的任务管理视图，该视图由各种自定义控件组成。您可以看到一个用例选择，一个列表细节表示和一个操作栏。在开始时，这些控件是垂直排列的。但是随着宽度的扩大，对齐方式也会发生变化。选择栏显示在左侧，列表详细信息部分在中间，操作栏向右移动。

此外，控件会逐渐更改其外观。现在，选择栏显示可用用例的列表。操作栏将操作项目切换为垂直对齐，并且-随着空间的增加-还会显示每个项目的标签。最终，宽度扩展达到饱和，从这一点开始，布局将保持固定。

对我而言，最明显的起点是SWT Layouts 。但是基于我所知道的一种布局的直接解决方案似乎很困难。因此，我尝试了手工制作的运气。

想法是使用宽度范围的比例作为布局算法的度量单位。所有控件都与用于相关布局数据的单个存储关联。该存储允许为每个范围配置不同的设置。现在，算法可以为实际的合成宽度选择适当的配置，并相应地布置控件³ 。

鉴于此，调用自定义布局ScaleLayout以及枚举Scale和布局数据实现ScaleData似乎很自然。以下代码段显示了如何使用后者：

class ViewContentScaleConfig {

  private final ScaleData selectorData;
  private final ScaleData seperatorData;
  private final ScaleData detailData;

  [...]

  void configure() {
    layoutSuperCompact();
    layoutCompact();
    [...]
  }
  private void layoutCompact() {
    selectorData.on( Scale.COMPACT )
      .setMargin( 5, 3, 0, 0 );
    seperatorData.on( Scale.COMPACT )
      .setWidth( 1 ).setMargin( 5, 0, 0, 0 );
    detailData.on( Scale.COMPACT )
      .setMargin( 3, 3, 2, 2 );
  }

  private void layoutSuperCompact() {
    selectorData.on( Scale.SUPER_COMPACT )
      .tie( seperatorData ).setMargin( 3, 0, 3, 0 );
    seperatorData.on( Scale.SUPER_COMPACT )
      .tie( detailData ).setHeight( 1 );
    detailData.on( Scale.SUPER_COMPACT )
      .setMargin( 0, 8, 0, 0 );
  }
}

ScaleData有助于流畅的属性配置，我想这是不言而喻的。更加值得注意的是tie调用，它为给定的Scale值连接布局数据，因为这定义了ScaleLayout如何在特定范围内排列控件。

布局算法

无需任何约束，所有控件在水平行中无缝对齐，每个控件均以可用的客户区域高度及其首选宽度作为大小。最后一行抓住了客户区域的剩余宽度。

要更改此控件，可以将其绑定到另一个控件。请注意，每个Scale和ScaleData只允许一个领带。实际上，这会将控件组织在一个或多个不连续的列表中。

现在，列表头控件将水平排列。另外，特定列表的控件将随后安排在head控件下方。通过将列表控件显示为列的方式来完成此操作。这种列的宽度由具有最大优选宽度的控件确定。不同列控件的高度计算遵循与上述宽度⁴相同的规则。

如示例片段中所示，控件的默认大小计算可以被提示覆盖。但是，即使有了这些信息，细心的读者也会想知道这种具有固定比例枚举的构造如何在嵌套的UI组合中工作。

规模提供商

使ScaleLayout实际起作用的缺失部分是参考点。比例必须与UI的特定组合相关。更改此“基础”组合的宽度可能会更改“比例”中的位置。并且该信息必须在整个合成结构中传播。视图部件的根组合显然是用作参考点的不错选择。

为此，有一个名为ScaleProvider的类，该类将复合物（参考点）用作构造函数参数，而ScaleLayout实例又将ScaleProvider用作构造函数参数。这就是布局算法如何获得其参照系的方法。

此外， ScaleProvider还提供了侦听器注册的可能性。例如，这可以将控件的外观模式映射到Scale值。上面的视频中的用例选择器说明了该原理。选择器实现可以在两种模式之间切换： STANDARD和COMPACT 。以下代码段显示了如何通过比例更改事件触发模式更改：

class SelectorModeUpdater implements ScaleListener {

  private final InfoSelector selector;

  SelectorModeUpdater( InfoSelector selector ) {
    this.selector = selector;
  }

  public void scaleChanged( ScaleEvent event ) {
    if( Scale.SUPER_COMPACT == event.getNewScale() ) {
      selector.setMode( Mode.COMPACT );
    } else {
      selector.setMode( Mode.STANDARD );
    }
  }
}

类似的映射用于触发操作栏的外观更改。

结论

响应式UI方法现已采用不同的尺寸，从而极大地改善了我的视图设计的外观。但是，我必须指出ScaleLayout具有一些缺点，在可以用作通用解决方案之前，应该先解决这些缺点。首先，布局算法可能有点过于简单。其次，固定比例尺方法是僵化的，并引起一种语义耦合。第三， ScaleData配置趋于冗长……

但是事情可能会在随后的迭代中发展，对于有创造力的灵魂，这可能是一个很好的灵感或起点。顺便说一下，在这方面，我非常好奇Holger和Jordi将在EclipseCon 2014上的 RAP / Tabris演讲中使用RAP创建响应式SWT应用程序。特别是因为它们还介绍了资源处理，因此在本文中我将其完全省略。

对于喜欢玩的人，我以GitHub的要点提供ScaleLayout实现的代码： https : ScaleLayout