使用设备配置文件

当今的移动 Web 应用程序有望在各种设备上工作，从最小的手机到最大的平板电脑。这些设备具有广泛的屏幕分辨率，并且以不同的方式使用。人们倾向于在家外使用手机应用程序来快速收集一些信息或执行某些操作 - 通常在很短的时间内。平板电脑应用程序更可能在更长的时间内使用，通常在家中或其他他们可以长时间坐着的地方。

所有这一切都意味着人们期望在不同的设备上获得不同的应用程序体验。但是，您的大部分应用程序逻辑和资产可以在不同的体验之间共享。为每个平台编写单独的应用程序既耗时又容易出错，而且很无聊。值得庆幸的是，设备配置文件为我们提供了一种简单的方法，可以在设备类型之间共享尽可能多的代码，同时可以轻松地为每个设备自定义行为、外观和工作流程。

设置配置文件

设备配置文件存在于 Application（应用程序）的上下文中，例如，如果我们想创建一个带有手机和平板电脑配置文件的电子邮件应用程序，我们可以定义我们的 app.js，如以下代码示例所示（如果不熟悉，请参阅 Intro to Apps guide（应用程序入门指南））

Ext.application({
    name: 'Mail',

    profiles: ['Phone', 'Tablet']
});

由于我们没有给我们的 Application（应用程序）一个 launch function（启动函数），目前它只会加载这两个配置文件。按照惯例，它希望在 app/profile/Phone.js 和 app/profile/Tablet.js 中找到它们。以下代码显示了 Phone（手机）配置文件

Ext.define('Mail.profile.Phone', {
    extend: 'Ext.app.Profile',

    config: {
        name: 'Phone',
        views: ['Main']
    },

    isActive: function() {
        return Ext.os.is('Phone');
    }
});

Tablet（平板电脑）配置文件遵循相同的模式。在 Phone（手机）配置文件中，我们只提供了三个信息 - Profile（配置文件）name（名称）、可选的附加 views（视图）集合，以便在此 Profile（配置文件）激活时加载，以及一个 isActive（是否活动）函数。

isActive（是否活动）函数确定给定的配置文件是否应在您的应用程序运行的设备上处于活动状态。到目前为止，最常见的方法是为 Phone（手机）和 Tablet（平板电脑）创建配置文件，使用内置的 Ext.os.is 方法（例如 Ext.os.is(Phone（手机）)）。您可以在 isActive（是否活动）函数中编写任何您喜欢的代码，只要它始终为在其上运行的设备返回 true（真）或 false（假）即可。

确定活动配置文件

加载配置文件后，将依次调用其 isActive（是否活动）函数。第一个返回 true（真）的配置文件是 Application（应用程序）启动时使用的配置文件。然后，此配置文件设置为 Application（应用程序）的 currentProfile（当前配置文件），并且 Application（应用程序）准备加载其所有依赖项 - 构成应用程序的模型、视图、控制器和其他类。它通过将其自身的依赖项与活动配置文件中指定的依赖项相结合来实现这一点。

例如，让我们修改我们之前的 Application（应用程序），以便它加载自己的模型和视图

Ext.application({
    name: 'Mail',

    profiles: ['Phone', 'Tablet'],

    models: ['User'],
    views: ['Navigation', 'Login']
});

最后，当我们在手机上加载应用程序时，Phone（手机）配置文件被激活，应用程序加载以下文件

• app/model/User.js
• app/view/Navigation.js
• app/view/Login.js
• app/view/phone/Main.js

前三个项目在 Application（应用程序）本身中指定 - User（用户）模型以及 Navigation（导航）和 Login（登录）视图。第四个项目由 Phone Profile（手机配置文件）指定，并遵循特殊形式。按照惯例，特定于 Profile（配置文件）的类应在与 Profile（配置文件）同名的子目录中定义。例如，Phone Profile（手机配置文件）中指定的 'Main'（主）视图从 app/view/phone/Main.js 加载，而如果我们在 Application（应用程序）中定义了 'Main'（主），则它将从 app/view/Main.js 加载。

这同样适用于在 Profile（配置文件）中加载的所有模型、视图、控制器和存储。这很重要，因为它使您能够轻松地在配置文件之间共享行为、视图逻辑等（请参阅下面的专门化视图和控制器部分）。如果您需要加载不符合此约定的类，您可以指定完整的类名

Ext.define('Mail.profile.Phone', {
    extend: 'Ext.app.Profile',

    config: {
        name: 'Phone',
        views: ['Main', 'Mail.view.SpecialView'],
        models: ['Mail.model.Message']
    },

    isActive: function() {
        return Ext.os.is('Phone');
    }
});

从此示例中可以看出，您可以混合和匹配完全限定的类名（例如 *'Mail.view.SomeView'*）和相对指定的类名（例如 *'Main'*（主），它变为 *'Mail.view.phone.Main'*）。请注意，为 Profile（配置文件）指定的所有模型、视图、控制器和存储都以这种方式处理。这意味着如果有些模型或存储您只想为平板电脑加载，但不想创建像 *Mail.model.tablet.User* 这样的类，则应指定完全限定的类名（例如，在本例中为 *Mail.model.User*）。

启动过程

使用配置文件的启动过程与不使用配置文件的启动过程几乎完全相同。基于配置文件的应用程序具有 3 个阶段的启动过程；加载所有依赖项后，会发生以下情况

1. 控制器被实例化；每个控制器的 init（初始化）函数被调用
2. 配置文件的 launch（启动）函数被调用
3. 应用程序的 launch（启动）函数被调用。

使用配置文件时，通常使用 Profile（配置文件）launch（启动）函数来创建应用程序的初始 UI。在许多情况下，这意味着 Application（应用程序）的 launch（启动）函数被完全删除，因为初始 UI 通常在每个 Profile（配置文件）中都不同（您仍然可以指定一个应用程序范围的 launch（启动）函数来设置分析或其他与配置文件无关的设置等项目）。

典型的 Profile（配置文件）launch（启动）函数可能如下面的示例所示

Ext.define('Mail.profile.Phone', {
    extend: 'Ext.app.Profile',

    config: {
        name: 'Phone',
        views: ['Main']
    },

    isActive: function() {
        return Ext.os.is('Phone');
    },

    launch: function() {
        Ext.create('Mail.view.phone.Main');
    }
});

请注意，Profile（配置文件）和 Application（应用程序）launch（启动）函数都是可选的 - 如果您未定义它们，则不会调用它们。

专门化视图

Profile（配置文件）实现的大多数专门化发生在视图和控制器中。让我们假设我们有以下平板电脑 Profile（配置文件）

Ext.define('Mail.profile.Tablet', {
    extend: 'Ext.app.Profile',

    config: {
        views: ['Main']
    },

    launch: function() {
        Ext.create('Mail.view.tablet.Main');
    }
});

当此应用程序在平板电脑设备上启动时，文件 app/views/tablet/Main.js 照常加载。以下代码示例是 app/views/tablet/Main.js 文件的内容

Ext.define('Mail.view.tablet.Main', {
    extend: 'Mail.view.Main',

    config: {
        title: 'Tablet-specific version'
    }
});

通常，当我们定义视图类时，我们会扩展 Sencha Touch 的内置视图之一，但在之前的示例中，我们扩展了 Mail.view.Main，我们自己的视图之一。以下代码示例说明了 Mail.view.Main 的外观

Ext.define('Mail.view.Main', {
    extend: 'Ext.Panel',

    config: {
        title: 'Generic version',
        html: 'This is the main screen'
    }
});

因此，我们有一个超类 (Mail.view.Main) 和一个 Profile（配置文件）特定的子类 (Mail.view.tablet.Main)，它可以自定义超类的任何方面。在本例中，我们在子类中将 Main（主）视图的标题从“Generic version”（通用版本）更改为“Tablet-specific version”（平板电脑特定版本），因此这是我们在应用程序加载时看到的。

由于这些是普通的类，因此可以使用灵活的配置系统轻松自定义超类的几乎任何部分。例如，假设我们也有一个手机版本的应用程序，我们可以按如下方式自定义其 Main（主）视图的版本（*app/view/phone/Main.js*）

Ext.define('Mail.view.phone.Main', {
    extend: 'Mail.view.Main',

    config: {
        title: 'Phone-specific version',

        items: [
            {
                xtype: 'button',
                text: 'This is a phone...'
            }
        ]
    }
});

共享子视图

虽然前面的示例很有用，但更常见的是共享视图的某些部分，并将它们以不同的方式拼接在一起以用于不同的配置文件。例如，想象一个电子邮件应用程序，其中平板电脑 UI 是一个分屏，左侧是消息列表，右侧是加载的当前消息。Phone（手机）版本是完全相同的消息列表和一个类似的消息视图，但这次是在 card layout（卡片布局）中，因为没有足够的屏幕空间同时显示两个视图。

为了实现这一点，我们必须创建两个共享的子视图 - 消息列表和消息查看器。在每种情况下，为了简洁起见，我们都省略了类配置

Ext.define('Mail.view.MessageList', {
    extend: 'Ext.List',
    xtype: 'messagelist'

    // config goes here...
});

和消息查看器

Ext.define('Mail.view.MessageViewer', {
    extend: 'Ext.Panel',
    xtype: 'messageviewer'

    // config goes here...
});

最终，为了实现包含两个视图的目标布局，平板电脑 Main（主）视图可能使用以下代码

Ext.define('Mail.view.tablet.Main', {
    extend: 'Ext.Container',

    config: {
        layout: 'fit',
        items: [
            {
                xtype: 'messagelist',
                width: 200,
                docked: 'left'
            },
            {
                xtype: 'messageviewer'
            }
        ]
    }
});

这会在左侧创建一个 200px 宽的消息列表，并使用设备屏幕空间的其余部分来显示消息查看器。现在让我们假设我们想要实现 Phone（手机）布局

Ext.define('Mail.view.phone.Main', {
    extend: 'Ext.Container',

    config: {
        layout: 'card',
        items: [
            {
                xtype: 'messagelist'
            },
            {
                xtype: 'messageviewer'
            }
        ]
    }
});

在这种情况下，我们使用带有 card layout（卡片布局）的 Container（容器）（一种一次只显示一个项目的布局），并将列表和查看器都放入其中。在这种情况下，我们仍然需要添加一些逻辑，告诉 Container（容器）在点击列表中的消息时显示消息查看器，但我们已经轻松地在基于当前加载的 Profile（配置文件）的不同配置中重用了我们的两个子视图。

与之前的示例类似，我们可以选择为每个 Profile（配置文件）自定义两个共享视图 - 例如，我们可以创建 Mail.view.phone.MessageViewer 和 Mail.view.tablet.MessageViewer 子类，这两个子类都扩展了 Mail.view.MessageViewer 超类。这使我们能够再次在这些类之间共享大量视图代码，同时呈现适合实际使用的设备的自定义。

专门化控制器

与视图类似，许多应用程序都有一些控制器逻辑可以在多个配置文件之间共享。在配置文件的情况下，最重要的区别通常与工作流程相关。例如，应用程序的平板电脑配置文件可能允许您在一个页面上完成工作流程，而手机配置文件则呈现一个多页向导。

在以下示例中，我们有一个简单的 Phone Profile（手机配置文件），它加载一个名为 Main（主）的视图和一个名为 Messages（消息）的控制器。与之前一样，此应用程序加载 app/view/phone/Main.js 和 app/controller/phone/Messages.js

Ext.define('Mail.profile.Phone', {
    extend: 'Ext.app.Profile',

    config: {
        views: ['Main'],
        controllers: ['Messages']
    },

    launch: function() {
        Ext.create('Mail.view.phone.Main');
    }
});

由于我们已经知道我们的手机和平板电脑特定控制器共享其大部分功能，因此我们在 app/controller/Messages.js 中创建了一个控制器超类

Ext.define('Mail.controller.Messages', {
    extend: 'Ext.app.Controller',

    config: {
        refs: {
            viewer: 'messageviewer',
            messageList: 'messagelist'
        },
        control: {
            messageList: {
                itemtap: 'loadMessage'
            }
        }
    },

    loadMessage: function(item) {
        this.getViewer().load(item);
    }
});

前一个示例中的 Controller（控制器）执行三个操作

1. 设置 refs（引用），引用我们关心的视图。
2. 监听消息列表上的 itemtap（项目点击）事件，并在触发 itemtap（项目点击）时调用 loadMessage() 函数。
3. 当调用 loadMessage() 时，将选定的消息项加载到 Viewer（查看器）中。

我们现在可以按如下方式创建特定于手机的 Controller（控制器）

Ext.define('Mail.controller.phone.Messages', {
    extend: 'Mail.controller.Messages',

    config: {
        refs: {
            main: '#mainPanel'
        }
    },

    loadMessage: function(item) {
        this.callParent(arguments);
        this.getMain().setActiveItem(1);
    }
});

此代码扩展了 Messages（消息）超类控制器，并提供以下功能

1. 1. 为手机 UI 的主面板添加另一个 ref（引用）2. 扩展 loadMessage 函数以执行原始逻辑，然后将主面板的活动项设置为消息查看器。

整个超类配置由扩展它的子类继承。在 refs（引用）等重复配置的情况下，配置会合并，因此手机 Messages（消息）控制器类有三个 refs（引用）- main（主）、viewer（查看器）和 messageList（消息列表）。与任何扩展另一个类的类一样，我们可以使用 callParent 来扩展超类中的现有函数。

请记住，*Mail.controller.Messages* 超类未被 Application（应用程序）或 Profile（配置文件）声明为依赖项。它是自动加载的，因为我们的 *Mail.controller.phone.Messages* 控制器扩展了它。

共享哪些代码

在前面的示例中，我们能够共享一些（但不是全部）我们的 refs（引用）。我们还能够通过使用 Controller（控制器）的 control（控制）配置来共享我们监听的单个事件。一般来说，应用程序在配置文件之间差异越大，您可以共享的 refs（引用）和 control（控制）配置就越少。

应该在不同配置文件之间共享的一个控制器配置是 routes。这些配置将 URL 映射到控制器操作，并提供后退按钮支持和深度链接。将 `routes` 配置保留在超类中非常重要，因为相同的 URL 应该映射到相同的内容，无论设备类型如何。

例如，如果朋友正在使用您应用的手机版本，并向您发送她当前所在应用页面的链接，您应该能够在平板电脑设备上点击该链接，并看到针对该 URL 的平板电脑特定视图。将所有路由保留在超类中使您能够保持一致的 URL 结构，无论设备类型如何都能正常工作。

专门化模型

模型相对于控制器和视图而言，按配置文件进行自定义的频率较低，因此通常不需要子类。在这种情况下，我们仅指定模型的完全限定类名

Ext.define('Mail.profile.Tablet', {
    extend: 'Ext.app.Profile',

    config: {
        models: ['Mail.model.Group']
    }
});