About

<#TEMPLATE_INCLUDE_NINEPAGE_ABOUTME#>
  • Nov

    17

    任意新建一个 MXML 组件继承自 spark 版本 TextInput  组件,不添加任何扩展代码: 

    <?xml version="1.0" encoding="utf-8"?>
    <s:TextInput xmlns:fx="http://ns.adobe.com/mxml/2009" 
                 xmlns:s="library://ns.adobe.com/flex/spark" 
                 xmlns:mx="library://ns.adobe.com/flex/mx"
                 >

        <fx:Declarations>
            <!-- 将非可视元素(例如服务、值对象)放在此处 -->
        </fx:Declarations>

    </s:TextInput>

    当把这个组件应用到项目中去时,会遇到这样的 Bug 提示: 

    “String”类型的默认属性“text”有多个初始值设定项值。

    但如果把 spark 的前缀 s 换成 mx 的 TextInput  组件则完全正常。但如果样式已经经过自定义,换成 mx 则不通用。

    解决方法:

    第一种:采用纯 AS 语法继承 TextInput  ,放弃使用 MXML 语法。

    第二种:继续使用 MXML 语法,但插入任意一个已知属性,以 visible 属性为例(也可以是类似 alpha 等这样的属性):

    <?xml version="1.0" encoding="utf-8"?>
    <s:TextInput xmlns:fx="http://ns.adobe.com/mxml/2009" 
                 xmlns:s="library://ns.adobe.com/flex/spark" 
                 xmlns:mx="library://ns.adobe.com/flex/mx"
                 >

        <s:visible>true</s:visible>

        <fx:Declarations>
            <!-- 将非可视元素(例如服务、值对象)放在此处 -->
        </fx:Declarations>

    </s:TextInput>

    Nov

    11

    在 Flex 开发应用时如果选择使用 spark 组件,默认它的字体比较丑,所以一般把它设为“微软雅黑”或其它无衬线字体。但 spark 组件种类又不像 mx 那么丰富,类似 MenuBar、Menu、Tree、AdvancedDataGrid  等带有字体显示的组件在 spark 中都没有的,所以很多时候就需要 spark 与 mx 混合使用。

    混合使用时设置一个默认的全局字体 fontFamily 必须要带引号,否则只会对 spark 组件起作用而不会对 mx 组件起作用。

    比如我们这么写,它只会让 spark 组件的字体变成微软雅黑,并不会让 mx 组件的字体产生变化:

    global
    {
        fontFamily: 微软雅黑, Microsoft YaHei;
        fontSize:12;
    }

     但如果我们对字体的名称加上引号,它会让 spark 与 mx 的组件的字体同时变成微软雅黑:

    global
    {
        fontFamily: "微软雅黑""Microsoft YaHei";
        fontSize:12;
    }

    Mar

    8

    开发者们在开发桌面应用时往往不需要考虑性能问题,可以选择 Flex 组件框架中 MX 或 Spark 包中的控件,因为它们功能强大(只要业务逻辑不是死循环或,基本上就不会有什么大问题)。但由于移动设备性能较低,所以开发者们在开发 Adobe AIR 应用时总是会选择更为轻量级的 UI 框架。

    比如基于 Starling 的 Feathers UI 组件,但 Starling 是基于 Stage3D 的,所以 Feathers 也是基于 Stage3D 的,这意味着如果项目中本身有传统显示对象,那么需要同时刷新 Stage3D 层和传统显示对象层,并却需要保持通信与渲染的同步,最终这有可能导致项目的性能并不能很好的发挥,甚至还可能导致更差的效果,所以在使用 Feathers 开发移动项目时往往不得不避开传统显示对象的使用。

    再比如选择 Flex Spark 移动主题(注意:Spark 主题和 Spark 移动主题并不是完全一样的,Spark 移动主题是针对移动设备优化后的主题,类库并不完全相同,并且每个类的功能或多或少的也并不相同),这是个不错的选择(我喜欢),它能支持所有传统显示对象,包括复杂功能的 Flex 显示控件(但并不推荐使用太过复杂的控件或较占资源的控件)。

    另一种选择是 MadComponents,这套 UI 组件其实并不仅限于 Adobe  AIR 移动开发,包括纯 AS 的 WEB 应用也可以,它采用 XML 布局,所以可以像在 Flex 中使用 MXML 布局那样进行快速的开发。

    Spark 移动主题与 MadComponents 比较: 

    1、MadComponents 在 AS 中采用 XML 布局,并不能真正的可视化的布局控件,对于已经习惯 MXML 布局的开发者,可以忽略这一点。

    2、MadComponents 相比于 Spark 移动主题更加轻量级,轻量级意味着它会相对少一些功能,开发的时候成本可能会更高。

    a、比如 MadComponents 没有像 Spark 移动主题那样拥有持久化机制;

    b、比如 MadComponents 采用的是 AS 语法,所以设置样式时没有像 Spark 移动主题使用 CSS 语法那么方便。

    c、比如当项目本身涉及大量的位图资源的时,MadComponents 无法像 Flex 中 Spark 移动主题那样使用强大的 @media 规则。

    d、比如当界面设计中矢量元素较多的情况下,Adobe 设计类软件生成的 FXG 资源文件与 Flex 的软件接力强大功能也体现出来了。

    e、MadComponents 并没有中文支持,甚至在 Google 上的 swc 文件往往也不是最新的,它的更新地址在 Facebook,国内用户你懂的(当然对于技术人员而言,这一点也可以忽略)。

    其它无法一一例举,作为快速和轻量级(相对于 Spark 移动主题)UI 组件开发,MadComponents 已经非常棒了。

    以下为 MadComponents 相关链接

    https://code.google.com/p/mad-components/

    https://www.facebook.com/groups/madcomponents/

    Jul

    2

    一般意义上来说,自定义创建 Spark 组件分两个部份。两个部份分别指两个具体的类,一个业务逻辑类,一个皮肤类(下文中所有术语如“外观状态”、“外观部件”等全部采用A DOBE 官方中文手册资料中的术语为准)。

    业务逻辑类:

    在该类中,除了具体的业务逻辑外,需要实现以下几步:

    1、定义对应的皮肤。

    2、通过 [SkinState] 元标签定义组件支持的外观状态的。

    3、通过 [SkinPart] 元标签标识皮肤的部件(外观部件)。

    皮肤类:

    1、使用 [HostComponent] 元标签指定对应的组件。

    2、声明与业务逻辑类中对应的每个外观状态,并定义每个外观状态的实际外观。

    一般为 MXML 文件,可以含有从设计类软件中导出的 FXG 文件数据

    3、定义皮肤部份在舞台上的显示方式(即 id 属性对应业务逻辑类中的外观部件)

    More...

    Jul

    22

    1、如果需要使用 MXML 语言,则自定义的列表类组件需扩展自 ListBase 类。支持 dataProvider, labelField, labelFunction,requiresSelection, selectedIndex, selectedItem, 和 useVirtualLayout 这些标签。

    2、如果只扩展 SkinnableDataContainer 类,那么仍然可以使用上面这些属性,但不能再使用 MXML 语法。

    3、Spark 命名空间的列表类组件中,包括自定义列表类组件中,如果使用 MXML 语法直接添加集合类数据(实现了 ICollectionView  类的数据)至控件,默认会包装在 dataProvider 中(也就是可以省略 <s:dataProvider/> 标签)。

    4、自定义列表类组件时,需要将皮肤和状态抽象为一个单独的类;从外部获得数据;项渲染器抽象为单独的类。

    5、labelFunction 以循环遍历的方式处理所有标签字段,如果一个列表类对象(包括自定义列表类对象)使用了 labelFunction 并不断的更新数据,这将可能会引发性能问题。