Giới thiệu Dojo Mobile

Hầu hết các điện thoại di động trên thị trường hiện nay đều có các trình duyệt web đầy đủ tính năng mà hầu như không thể phân biệt được các trình duyệt web này với các trình duyệt của máy tính để bàn. Những trình duyệt web di động này có thể xử lý hầu hết các công nghệ web gần đây như HTML5, CSS3, JavaScript, xử lý DOM và Ajax.

Dojo Toolkit đã đang phát triển ứng dụng web cho máy tính để bàn và Dojo có thể chạy trên các trình duyệt web di động. Kể từ đó Dojo đã cung cấp rất nhiều tiện ích có ích, vậy chúng ta có thực sự cần một cái gì đó riêng cho các ứng dụng di động không? Có, vì nhiều lý do:

1. Thiết bị đầu vào khác nhau: Hầu hết các thiết bị di động không có chuột hoặc bàn phím vật lý. Thay vào đó, chúng có một màn hình cảm ứng hỗ trợ các hoạt động ngón tay. Những tương tác của người dùng trên các ứng dụng máy tính để bàn — các hoạt động kéo và thả, các hành động di chuột, các phím tắt trên bàn phím và chuyển hướng (đi ngang sử dụng phím TAB hoặc các phím mũi tên) và v.v.. — đặt ra một thách thức trên thiết bị di động. Bất kỳ các tiện ích (widget) giao diện người dùng nào cho di động cũng cần có khả năng cảm ứng.
   
   
2. Kích thước màn hình nhỏ hơn: Màn hình của thiết bị di động nhỏ và người dùng sử dụng một ngón tay trên màn hình cảm ứng. Điều rất quan trọng là thiết kế đúng giao diện người dùng cho di động. Ngoài ra, kích thước màn hình của một thiết bị máy tính bảng lớn hơn nhiều so với một màn hình của máy điện thoại thông minh. Các ứng dụng web di động cần một giao diện người dùng có thể thay đổi theo kích thước màn hình hoặc định hướng màn hình.
   
   
3. Các vấn đề hiệu năng: Trong khi sức mạnh của bộ xử lý của các thiết bị di động đang tăng lên nhanh chóng, các thiết bị di động vẫn có khả năng tính toán thấp hơn so với các máy tính để bàn. Ngoài ra, băng thông của mạng di động thấp hơn nhiều so với băng thông của một máy tính để bàn; đôi khi nó cực kỳ thấp. Các ứng dụng web di động có dung lượng vô cùng nhỏ và có khả năng trình diễn cao.

Dojo Mobile là một bộ tiện ích dựa trên Dojo để tạo ra các ứng dụng web di động. Nó đã được giới thiệu trong Dojo 1.5 là dojox.mobile để giải quyết các vấn đề trên. Tuy nhiên, thiết bị đầu vào và các vấn đề kích thước màn hình có thể được giải quyết bằng cách tiếp cận truyền thống, có nghĩa là, chỉ cần nâng cao các tiện ích Dojo hiện có bằng cách bổ sung sự hỗ trợ cho di động mà không cần tạo phiên bản các tiện ích mới cho di động. Nhưng rõ ràng là không thể giải quyết các vấn đề hiệu năng theo cách đó. Vì vậy, một trong những nhiệm vụ quan trọng nhất (và đầy thử thách) cho Dojo Mobile là giải quyết các vấn đề hiệu năng, đặc biệt là giảm thiểu kích cỡ mã.

Về đầu trang

Các tiện ích giao diện người dùng không dùng hình ảnh

Một trong những tính năng thú vị của Dojo Mobile là nó không sử dụng bất kỳ các hình ảnh nào để xây dựng các tiện ích giao diện người dùng. Các trình duyệt dựa trên-WebKit, là những trình duyệt phổ biến nhất trên các thiết bị di động, hỗ trợ CSS3. Các tính năng CSS3, ví dụ như các nền đổi mầu, các hộp có góc tròn và phép chuyển đổi của các phần tử DOM, có thể xử lý biểu diễn đồ họa mà không cần sử dụng các hình ảnh. Hình 1 cho thấy một số các tiện ích giao diện người dùng do Dojo Mobile cung cấp. Các tiện ích này không sử dụng các hình ảnh, thay vào đó, chúng sử dụng các phần tử DOM như <div> với các phong cách CSS để xây dựng giao diện người dùng của chúng. Việc sử dụng nhiều hình ảnh có thể làm tăng tổng dung lượng tải về và tăng số các yêu cầu HTTP đến máy chủ, gây ra sự suy giảm hiệu năng. Dojo Mobile tránh điều đó bằng cách sử dụng khả năng của CSS3 càng nhiều càng tốt.

Mặt khác, các ứng dụng người dùng có thể sử dụng các hình ảnh. Hình 2 cho thấy những ví dụ được cung cấp như là các tệp kiểm tra của Dojo Mobile. Như bạn có thể thấy, các nút thanh tab, các biểu tượng mục danh sách và các biểu tượng của thùng chứa biểu tượng là những hình ảnh. Việc sử dụng quá nhiều hình ảnh có thể làm suy giảm hiệu năng, nhưng đó là một sự lựa chọn cho ứng dụng. Chính Dojo Mobile không sử dụng các hình ảnh, nhưng cũng không bắt buộc ứng dụng người dùng không sử dụng hình ảnh. Hơn nữa, như bạn sẽ thấy sau này, Dojo Mobile cung cấp một số cơ chế có ích, chẳng hạn như các Nút ấn DOM và CSS sprite (một tập các hình ảnh đặt trong một hình ảnh đơn), có thể làm giảm nhu cầu về các hình ảnh và giảm số lượng các yêu cầu HTTP đến máy chủ.

Về đầu trang

CSS Sprite

Khi không thể tránh được việc sử dụng hình ảnh, có hai cách có thể giảm thiểu suy giảm hiệu năng. Một cách là làm giảm kích cỡ tệp các hình ảnh của bạn bằng cách giảm số lượng màu hoặc tăng tỷ lệ nén. Một cách khác là làm giảm số các yêu cầu HTTP đối với các hình ảnh bằng cách gộp chung nhiều hình ảnh nhỏ thành một hình ảnh lớn. Hình ảnh lớn đã gộp lại có thể được cắt bớt và điều chỉnh bằng các thuộc tính CSS sao cho có thể sử dụng nó như là một trong những hình ảnh nhỏ. Kỹ thuật này được gọi là CSS Sprite và Dojo Mobile hỗ trợ nó.

Liệt kê 1 cho thấy một ví dụ về các mục danh sách, mỗi mục sử dụng một biểu tượng riêng. Hình 3 cho thấy kết quả. Ví dụ này tạo ra ba yêu cầu HTTP cho các hình ảnh.

<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-1.png" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-2.png" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-3.png" moveTo="bar">Store</li>
</ul>

Mặt khác, Liệt kê 2 cho thấy một ví dụ có sử dụng một hình ảnh gộp chung (i-icon-all.png), được các mục danh sách chia sẻ. Bằng cách chỉ rõ các giá trị được phân cách bằng dấu phẩy (top, left, width, height) cho đặc tính iconPos của các tiện ích ListItem, bạn có thể sử dụng lại bất kỳ vùng hình chữ nhật nào của hình ảnh gộp chung. Như thể hiện trong Hình 4, có kết quả tương tự, nhưng nó chỉ tạo ra một yêu cầu HTTP với hình ảnh gộp chung đó.

<ul dojoType="dojox.mobile.RoundRectList" iconBase="i-icon-all.png">
  <li dojoType="dojox.mobile.ListItem" iconPos="0,0,29,29" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,29,29,29" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,58,29,29" moveTo="bar">Store</li>
</ul>

Cũng có thể sử dụng CSS Sprite cho các biểu tượng của thùng chứa biểu tượng (Hình 5) hoặc các nút ấn của thanh tab (Hình 6).

Về đầu trang

Nút ấn DOM

Dojo Mobile cung cấp các nút ấn đơn, các biểu tượng, các dấu/các mũi tên kiểm tra cho một mục danh sách và v.v.., như trong Hình 7. Chúng được tạo ra từ các phần tử <div> có áp dụng các phong cách CSS mà không dùng hình ảnh nào và được gọi là các Nút ấn DOM (DOM Button).

Lý tưởng là các Nút ấn DOM nhỏ hơn kích cỡ (tính theo) byte, do chúng được tạo ra từ CSS mà không dùng các hình ảnh nào. Bảng 1 so sánh các kích cỡ byte của các Nút ấn DOM và các hình ảnh khi sử dụng nút DomButtonGreenCircleArrow (nút thứ tư từ trên xuống, cột đầu tiên trong Hình 7) làm một ví dụ. Bạn có thể nhìn thấy một Nút ấn DOM có kích cỡ byte nhỏ hơn nhiều so với kích cỡ byte của một hình ảnh.

Các Nút ấn DOM có thêm lợi thế là không cần phải thực hiện thêm các yêu cầu HTTP, vì chúng có thể được tích hợp vào một tệp CSS chủ đề bằng công cụ xây dựng. Trong tình huống này, dung lượng của một Nút ấn DOM nhỏ hơn nhiều. Bảng 2 cho thấy một kích cỡ byte của Nút ấn DOM trong một tệp CSS gộp chung. Bạn có thể thấy việc thêm tệp DomButtonGreenCircleArrow.css chỉ làm tăng thêm 155 byte mà thôi.

Cấu trúc của Nút ấn DOM

Nút ấn DOM gồm có các phần tử <div> lồng nhau có áp dụng phong cách CSS. Như đã đề cập, bạn có thể đạt được một loạt các biểu diễn đồ họa nhờ sử dụng các khả năng phong phú của CSS3, ví dụ như các nền đổi mầu, các hộp có góc tròn và phép chuyển đổi của các phần tử DOM. Thậm chí bạn có thể vẽ một vòng tròn bằng cách điều chỉnh bán kính đường viền của một phần tử <div> vuông. Hình 8 cho thấy một ví dụ về cấu trúc của Nút ấn DOM.

Cách sử dụng Nút ấn DOM

Nút ấn DOM chỉ đơn giản là một bộ sưu tập các phong cách CSS. Nó không đòi hỏi mã JavaScript. Có thể hiển thị nó chỉ bằng cách đặt các phần tử <div> lồng nhau và áp dụng các phong cách CSS cho chúng. Liệt kê 3 cho thấy mã mẫu tối thiểu và Hình 9 cho thấy kết quả.

<html>
  <head>
    <link href="themes/common/domButtons/DomButtonBlueCircleMinus.css" rel="stylesheet">
  </head>
  <body>
    <div class="mblDomButtonBlueCircleMinus">
      <div><div><div></div></div></div>
    </div>
  </body>
</html>

Trong Liệt kê 3, tôi đã chuẩn bị 4 mức các DIV lồng nhau bao gồm cả nút gốc của Nút ấn DOM, có một tên lớp. Tuy nhiên, số lượng các DIV, mà bạn cần chuẩn bị, sẽ thay đổi theo kiểu Nút ấn DOM. Để tự động tạo ra số lượng các DIV cần thiết, hãy sử dụng hàm dojox.mobile.createDomButton() của Dojo Mobile, như minh họa trong Liệt kê 4.

<div id="btn1" class="mblDomButtonBlueCircleMinus"></div>
----
var node = dojo.byId("btn1");
dojox.mobile.createDomButton(node);

Tuy nhiên, Liệt kê 3 và Liệt kê 4 thường không được sử dụng. Tôi giới thiệu chúng với mục đích minh họa để cho thấy cơ chế của Nút ấn DOM. Thay vào đó, một số các tiện ích Dojo Mobile hỗ trợ các Nút DOM như dưới đây. Bạn có thể quy định các Nút ấn DOM ở vị trí của các biểu tượng hình ảnh hoặc các nút ấn.

• ListItem: đặc tính icon, rightIcon, rightIcon2, arrowClass và checkClass (Hình 10)
• TabBarButton: đặc tính icon1 and icon2 (Hình 11)
• ToolBarButton: đặc tính icon (Hình 12)
• TabBarButton: đặc tính icon (Hình 13)

Cách tạo một Nút ấn DOM tùy chỉnh

Bạn có thể tạo các Nút ấn DOM tùy chỉnh riêng của mình. Dưới đây là một số mẹo nhỏ.

• Tên lớp của một Nút ấn DOM PHẢI bắt đầu bằng "mblDomButton". Dojo Mobile kiểm tra tên lớp để xác định xem nó có phải là một Nút ấn DOM hay không. (Mặt khác, bạn có thể chọn một tên tệp CSS và nơi đặt nó).
• Quy định chiều rộng và chiều cao của Nút ấn DOM cho nút gốc của nó. Chúng sẽ có kích cỡ của toàn bộ Nút ấn DOM.
• Các phần tử <div> lồng nhau, không có phần tử anh chị em. Vì vậy, bạn có thể cần áp dụng các phong cách CSS cho một nút liên quan đến nút cha mẹ của nó.
• Để áp dụng các phong cách CSS cho một phần tử <div> cụ thể trong hệ thống phân cấp <div>, bạn có thể sử dụng một bộ chọn con (>).
• Nếu bạn muốn hỗ trợ các trình duyệt của máy tính để bàn không theo-CSS3, bạn nên tạo ra một hình ảnh tương đương và một tệp compat css (*-compat.css).

Liệt kê 5 và Liệt kê 6 hiển thị một ví dụ về Nút ấn DOM tùy chỉnh. Hình 14 cho thấy kết quả.

/* === Red Check Button ==*/
.mblDomButtonMyCheck {
  position: relative;
  width: 29px;
  height: 29px;
}
.mblDomButtonMyCheck > div {
  position: absolute;
  left: 0px;
  top: 8px;
  width: 16px;
  height: 6px;
  font-size: 1px;
  -webkit-transform: scaleX(0.7) rotate(135deg);
  border-width: 3px 4px 0px 0px;
  border-style: solid;
  border-color: red;
}

/* === Red Check Button ==*/
.mblDomButtonMyCheck {
	background-image: url(compat/mblDomButtonMyCheck.png);
	background-repeat: no-repeat;
}
.mblDomButtonMyCheck > div {
	display: none;
}

Về đầu trang

Mô đun tương thích

Dojo Mobile được tối ưu hóa cho các trình duyệt di động dựa trên-WebKit, nhưng nó cũng hỗ trợ cho các trình duyệt máy tính để bàn không theo-WebKit. Tuy nhiên, không ai muốn hy sinh hiệu năng trên các thiết bị di động để hỗ trợ cho các trình duyệt máy tính để bàn. Không cần nạp mã hỗ trợ giữa các trình duyệt khi một ứng dụng chạy trên các thiết bị di động.

Biên dịch có điều kiện

Một cách tiếp cận là biên dịch có điều kiện, cho phép bạn loại bỏ một số khối mã không cần thiết cho di động. Dojo cung cấp hai cách biên dịch có điều kiện là các pragma và has().

Các pragma là các chỉ dẫn đặc biệt, có thể được sử dụng để loại trừ/bao gồm một số phần mã như trong Liệt kê 7.

process: function(){
//>>excludeStart("marker1", kwArgs.noIE);
    if(dojo.isIE){
        ....
    }
//>>excludeEnd("marker1");
    ....
}

Trong ví dụ trên, nếu bạn xây dựng mã với tùy chọn có điều kiện noIE=true được quy định như sau, thì khối mã được bao quanh bởi excludeStart và excludeEnd được lấy ra khỏi quá trình xây dựng.

> build profile=myapp action=release noIE=true

Ngoài ra, nếu bạn sử dụng các pragma includeStart/includeEnd, khối mã bao quanh được đưa vào chỉ khi có các sự trùng khớp có điều kiện.

has() (hoặc dojo/has hoặc has.js) là một cơ chế phát hiện/kiểm tra tính năng, được giới thiệu trong Dojo 1.7. Như trong Liệt kê 8, bạn có thể sử dụng nó để kiểm tra xem có hay không có một tính năng đặc trưng tồn tại trong môi trường thời gian chạy hiện tại.

process: function(){
    if(has("ie")){
        ....
    }
    ....
}

Nếu bạn cấu hình mảng staticHasFeatures trong lược tả xây dựng của bạn như dưới đây, has("ie") được thay thế bằng 0 và sau đó trình tối ưu hóa của trình biên dịch phát hiện ra khối mã của nó là mã chết và khối đó được lấy ra khỏi quá trình xây dựng.

staticHasFeatures: {
  'ie': 0
}

Mô đun tương thích

Biên dịch có điều kiện cho phép bạn thực hiện một quá trình xây dựng được tối ưu hóa cho một nền tảng riêng. Tuy nhiên, quá trình xây dựng này có một vấn đề ở chỗ nó không hoạt động trên các nền tảng khác. Để hỗ trợ các nền tảng khác, bạn cần thực hiện các quá trình xây dựng khác. Để giải quyết vấn đề này, Dojo Mobile đưa ra một cách tiếp cận khác: mô đun tương thích (hoặc compat).

Mô đun tương thích (compat) bao gồm một số mã hỗ trợ các trình duyệt không theo-WebKit. Nếu mô đun tương thích được nạp, nó "ghi đè lên" một số các phương thức của tiện ích cần được sửa chữa. Việc ghi đè mã giữ cho các tên lớp của tiện ích ban đầu giống nhau và do đó không ảnh hưởng đến mã ứng dụng của người dùng. Mặt khác, việc ghi đè mã, bằng cách phân lớp con cho các tiện ích ban đầu, sẽ yêu cầu sử dụng các tên lớp của tiện ích mới được định nghĩa. Mô đun tương thích cũng tải các tệp *-compat.css, là các bản vá lỗi cho các tệp css ban đầu. Trong chế độ mô đun tương thích (compat), các kỹ thuật truyền thống được sử dụng để đưa ra các giao diện người dùng (UI) của tiện ích không theo CSS3, chẳng hạn như các hình ảnh động dựa trên JavaScript với dojo.fx, các hình ảnh nền và v.v.. Để sử dụng mô đun tương thích cho ứng dụng của bạn, hãy tải về "dojox.mobile.compat" bằng cách sử dụng dojo.require() hoặc API require (API yêu cầu).

Lưu ý rằng mô đun tương thích được chia thành hai đoạn mã là, compat.js và _compat.js. _compat.js gồm tất cả mã thực hiện và compat.js là một bộ tải của _compat.js. compat.js tải _compat.js chỉ khi trình duyệt hiện tại không dựa trên-WebKit. compat.js là một đoạn mã nhỏ không ảnh hưởng đến hiệu năng di động ngay cả khi nó đang trong quá trình xây dựng. Theo cách này, trên các trình duyệt dựa trên-WebKit, hiệu năng không suy giảm do _compat.js vẫn chưa bao giờ được nạp. Trên các trình duyệt không theo-WebKit, _compat.js được nạp tự động và Dojo Mobile hoạt động trong chế độ mô đun tương thích (compat). Bảng 3 cho thấy sự so sánh kích cỡ byte giữa một quá trình xây dựng di động không có mô đun tương thích và một quá trình xây dựng di động có mô đun tương thích. Như bạn có thể thấy, hiệu số nhỏ không đáng kể: 45 byte.

Các lời khuyên về đánh giá hiệu năng

Như mô tả ở trên, trên các trình duyệt không theo-WebKit, Dojo Mobile chạy ở chế độ mô đun tương thích và tài nguyên bổ sung, chẳng hạn như các hình ảnh và/hoặc tệp * compat.css, được nạp. Vì vậy, nếu bạn muốn đánh giá các tệp nào và có bao nhiêu tệp được tải trong một thiết bị di động, bạn không nên sử dụng các trình duyệt không theo-WebKit như Firefox hay Internet Explorer. Các trình gỡ lỗi trên Google Chrome hay phiên bản máy tính để bàn của Safari là những công cụ tốt hơn để theo dõi lưu lượng truy cập mạng cho mục đích đó, do chúng dựa trên-WebKit.

Về đầu trang

Các phụ thuộc của mô đun

Dojo cung cấp rất nhiều các API có ích và chúng được đóng gói theo các mô đun, là các tệp JavaScript tương đối nhỏ. Có sẵn vô số các mô đun có ích. Tuy nhiên, việc lạm dụng chúng có thể dẫn đến một vùng lưu trữ rất lớn. Dojo Mobile được thiết kế cẩn thận để có càng ít các phụ thuộc mô đun càng tốt. Ví dụ, nó không cố ý sử dụng một số mô đun thường dùng, các mô đun có ích như dojo.query hoặc dijit._Templated. Ngoài ra, tất cả các tiện ích của Dojo Mobile kế thừa từ dijit._WidgetBase chứ không phải từ dijit._Widget. dijit._WidgetBase là một lớp cơ sở của dijit._Widget và không gồm một số mã không cần thiết cho di động, chẳng hạn như mã hỗ trợ bàn phím và nên nó nhẹ hơn dijit._Widget. Hơn nữa, nó không sử dụng dijit._base.manager, là một mô đun cần thiết cho đến Dojo 1.6; thay vào đó, nó sử dụng dijit.registry, là một tập con của dijit._base.manager.

Việc sử dụng các mô đun dojo như dojo.query hoặc dijit._Templated từ các ứng dụng người dùng dựa trên Dojo Mobile, tất nhiên, là sự lựa chọn của bạn. Tuy nhiên, bạn nên cẩn thận lựa chọn sử dụng các mô đun dojo/dijit nào dựa trên hiệu năng. Ví dụ, nếu bạn sử dụng dojo.query chỉ một lần trong ứng dụng của mình, bạn có thể thay thế nó bằng mã nhỏ hơn rất nhiều so với toàn bộ mã thực hiện của dojo.query.

Liệt kê 9 cho thấy các mô đun mà cơ sở Dojo Mobile phụ thuộc trực tiếp hoặc gián tiếp vào chúng. Bạn có thể nhận thấy nó có ít các phụ thuộc hơn trên các mô đun dojo/dijit so với các trường hợp sử dụng của máy tính để bàn điển hình. Nó chỉ phụ thuộc vào 11 mô đun dojo/_base trong số 25 mô đun và không có phụ thuộc nào vào các mô đun dijit /_base. Nếu bạn sử dụng các mô đun bổ sung không được hiển thị trong Liệt kê 9, việc đó sẽ làm tăng thêm vùng lưu trữ của ứng dụng của bạn. Khi bạn sử dụng các mô đun như vậy, bạn nên chọn chúng một cách cẩn thận.

dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic

Về đầu trang

Xây dựng

Để tối ưu hóa hiệu năng thời gian tải, xây dựng là một quá trình quan trọng. Dojo có một hệ thống xây dựng mạnh mẽ, trong đó nén tất cả các mã JavaScript và CSS vào số tệp ít hơn và tạo ra một phiên bản hiệu quả của ứng dụng của bạn để phát hành. Hình 15 và Hình 16 cho thấy sự so sánh các tệp được chuyển giao giữa một ứng dụng (mã nguồn) chưa xây dựng và ứng dụng đã xây dựng. Bạn có thể thấy có một sự khác biệt rất lớn giữa số lượng các yêu cầu và tổng kích cỡ được chuyển giao. Phần tiếp theo thảo luận xây dựng Dojo Mobile.

Xây dựng customBase

Xây dựng Dojo có một tùy chọn tên là customBase. Xây dựng Dojo tiêu chuẩn bao gồm hầu hết các mô đun cơ sở Dojo trong một quá trình xây dựng, do các mô đun cơ sở Dojo luôn có sẵn mà không cần yêu cầu rõ chúng. Tuy nhiên, nếu bạn thực hiện một quá trình xây dựng với tùy chọn customBase đã kích hoạt, chỉ các mô đun trong chuỗi phụ thuộc thực tế mới được đưa vào trong quá trình xây dựng đó. Dojo Mobile được thiết kế để có càng ít phụ thuộc của mô đun cơ sở Dojo càng tốt. Vì vậy, để được lợi từ thiết kế này, việc sử dụng tùy chọn customBase rất quan trọng. Liệt kê 10 cho thấy cách chỉ rõ tùy chọn customBase trong lược tả xây dựng của bạn.

dependencies = {
  stripConsole: "normal",

  layers: [
    {
      name: "dojo.js",
      customBase:
                    true,
      dependencies: [
        "dojox.mobile.parser",
        "dojox.mobile",
        "dojox.mobile.compat"
      ]
    },
  ....

Trình biên dịch đóng kín

Có hai trình biên dịch (hoặc trình nén), có thể được sử dụng để tạo thành công cụ xây dựng Dojo là Shrinksafe và Google Closure Compiler (Trình biên dịch đóng kín Google). Shrinksafe là trình biên dịch mặc định của Dojo. Hàm đóng kín (Closure) đã được đóng gói với Dojo kể từ phiên bản 1.7. Bảng 4 cho thấy sự so sánh kích cỡ xây dựng di động giữa Shrinksafe và Hàm đóng kín. Như bạn có thể thấy, tỷ lệ nén của hàm đóng kín tốt hơn so với tỷ lệ nén của Shrinksafe và kích cỡ của quá trình xây dựng Hàm đóng kín là thấp hơn 20% so với quá trình xây dựng Shrinksafe, ít nhất là trong ví dụ này.

Dojo Mobile đã được kiểm tra dựa vào những gì đã được xây dựng với Hàm đóng kín. Hàm đóng kín được khuyến nghị sử dụng với quá trình xây dựng di động, do đầu ra của nó nhỏ hơn.

Cách xây dựng Dojo Mobile

Dojo Mobile cung cấp hai tệp lược tả mẫu: mobile-all.profile.js và mobile.profile.js, trong thư mục dojo/util/buildscripts/profiles. Để dễ dàng xây dựng với các lược tả này, hãy sử dụng các tệp bó (batch) đơn giản có sẵn trong thư mục dojox/mobile/build.

Từ dòng lệnh, bạn có thể chạy tệp bó. Sử dụng build.bat cho Windows hoặc build.sh cho Linux.

  > build
  Usage: build separate|single [webkit]
    separate  Create mobile.js that includes only dojox.mobile
    single    Create a single dojo.js layer that includes dojox.mobile
    webkit    Enable webkitMobile=true option (Loses PC browser support)

separate (chia tách) sử dụng tệp mobile.profile.js và tạo ra tệp mobile.js CHỈ gồm các mô đun cơ sở dojox.mobile. Nó không có các mô đun cơ sở dojo hay cơ sở dijit. Tệp _compat.js cũng được tạo ra để hỗ trợ cho trình duyệt máy tính để bàn. Ngoài ra, tệp dojo.js được tạo ra, nhưng đó là một quá trình xây dựng cơ sở dojo bình thường, không phải là một quá trình xây dựng customBase.

Lưu ý rằng "cơ sở dojox.mobile" không gồm tất cả các tiện ích Dojo Mobile. Ví dụ, ScrollableView, Carousel, SpinWheel, các điều khiển dạng mẫu, v.v.. không có trong cơ sở đó. Nếu muốn có chúng trong quá trình xây dựng của mình, bạn có thể chỉ cần thêm chúng vào mảng các phụ thuộc trong một tệp lược tả. Liệt kê 12 cho thấy tất cả các mô đun được gói vào quá trình xây dựng cơ sở dojox.mobile, là mobile.js.

dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

single (đơn) sử dụng tệp mobile-all.profile.js và tạo ra một tầng dojo.js đơn có chứa cơ sở dojox.mobile và tất cả các mô đun dojo/dijit phụ thuộc. Tệp _compat.js cũng được tạo ra để hỗ trợ cho trình duyệt máy tính để bàn. Quá trình xây dựng này cho phép tùy chọn customBase. Vì vậy, chỉ có các mô đun cơ sở dojo/dijit tối thiểu có trong dojo.js kết quả. Liệt kê 13 cho thấy tất cả các mô đun được gói vào quá trình xây dựng đơn này.

dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic
dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/parser
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

webkit cho phép tùy chọn xây dựng webkitMobile=true, lấy ra các đoạn mã không cần thiết cho các trình duyệt di động dựa trên-Webkit. Ví dụ, loại bỏ mã riêng của Internet Explorer hay mã riêng của Firefox ra khỏi quá trình xây dựng này. Điều này làm giảm tổng dung lượng mã, nhưng mô đun đã xây dựng này sẽ không tiếp tục làm việc trên các trình duyệt của máy tính để bàn ngay cả với mô đun tương thích (compat.js).

Cũng lưu ý rằng tùy chọn này đã làm giảm một lượng mã đáng kể trong Dojo 1.6, nhưng trong Dojo 1.7, việc phát hiện/kiểm tra tính năng được chuyển cho dojo.has và nên tùy chọn webkitMobile không còn có nhiều tác dụng về giảm dung lượng mã nữa.

Về đầu trang

Gộp chung CSS

Dojo Mobile có một gói các tệp CSS trong thư mục themes (các chủ đề). Có một tệp CSS cho mỗi tiện ích và chúng có sẵn cho mỗi chủ đề, Android, Blackberry, Custom và iPhone. Ngoài ra, có các tệp CSS cho các Nút ấn DOM hoặc các hình ảnh động chuyển tiếp. Để giúp bạn dễ dàng đưa các tệp CSS cần thiết vào ứng dụng của mình, một số tệp CSS của điểm mục nhập sẽ gộp chung một số tệp CSS liên quan:

• Tệp chủ đề tất cả-trong-một (ví dụ: themes/iphone/iphone.css)
  Gồm tất cả các tệp CSS phổ biến và các tệp CSS chủ đề.
  
  
• Tệp chủ đề cơ sở (ví dụ: themes/iphone/base.css)
  Gồm các tệp CSS chủ đề cho các mô đun cơ sở dojox.mobile.
  
  
• Các Nút ấn DOM (themes/common/domButtons.css)
  Gồm tất cả các Nút ấn DOM.
  
  
• Các chuyển tiếp (themes/common/transitions.css)
  Gồm tất cả các hình ảnh động chuyển tiếp.
  
  

Việc sử dụng tệp chủ đề tất cả-trong-một là dễ nhất, vì nó bao gồm mọi thứ. Tuy nhiên, điều đó có nghĩa là có thể gồm cả các tệp CSS không sử dụng và điều đó có thể làm tăng dung lượng không cần thiết. Trong trường hợp đó, một cách tiếp cận là sử dụng tệp chủ đề cơ sở và các tệp CSS riêng lẻ không có trong tệp chủ đề cơ sở.

Các tệp CSS của điểm mục nhập nói trên là một bộ sưu tập chỉ dẫn @import (nhập khẩu@). Nếu bạn thực hiện quá trình xây dựng Dojo, các câu lệnh @import đều được nội tuyến và do đó các tệp CSS đã tham chiếu được kết hợp với nhau trong tệp CSS của điểm mục nhập. Vì vậy, việc sử dụng một tệp CSS điểm mục nhập chỉ đưa ra một yêu cầu HTTP, nếu nó được xây dựng. Tuy nhiên, nếu bạn đã liệt kê các tệp CSS trong ứng dụng của mình bằng cách sử dụng <link> hoặc @import như trong Liệt kê 14, các yêu cầu HTTP sẽ được tạo ra cho từng tệp CSS.

<head>
  <link href="../themes/iphone/base.css" rel="stylesheet">
  <link href="../themes/iphone/TabBar.css" rel="stylesheet">
  <link href="../themes/common/SpinWheel.css" rel="stylesheet">
  <link href="../themes/common/domButtons/DomButtonBlueCircleArrow.css" rel="stylesheet">
  ....

Để giảm số lượng các yêu cầu, hãy tạo tệp CSS của điểm mục nhập riêng của bạn, có các tài liệu tham chiếu đến các tệp CSS cần thiết tối thiểu bằng cách sử dụng chỉ dẫn @import như trong Liệt kê 15. Nếu bạn thực hiện một quá trình xây dựng Dojo, nó sẽ là một tệp CSS nội tuyến không cần tài liệu tham khảo bên ngoài. Bạn có thể sử dụng nó từ ứng dụng của mình như trong Liệt kê 16.

@import url("../themes/iphone/base.css");
@import url("../themes/iphone/TabBar.css");
@import url("../themes/common/SpinWheel.css");
@import url("../themes/common/domButtons/DomButtonBlueCircleArrow.css");

<link href="myStyles.css" rel="stylesheet">

Như mô tả ở trên, bạn có thể làm giảm số lượng các yêu cầu HTTP cho các tệp CSS bằng cách tạo ra tệp CSS của điểm mục nhập của bạn và thực hiện quá trình xây dựng Dojo.

Về đầu trang

Tạo động và tải rất chậm

Tải rất chậm — một kỹ thuật để tải các mô đun chỉ khi chúng được tham chiếu lần đầu tiên — cải thiện hiệu năng khởi động của ứng dụng. Chính Dojo Mobile sử dụng kỹ thuật tải rất chậm này ở bên trong.

Tạo một khung nhìn động

Với đặc tính url của _ItemBase, bạn có thể tạo động một khung nhìn mới ngay lập tức trước khi thực hiện một quá trình chuyển tiếp khung nhìn. Liệt kê 17 cho thấy một ví dụ sử dụng đặc tính url. Nội dung của khung nhìn có thể hoặc là một đoạn HTML (Liệt kê 18) hoặc là dữ liệu JSON (Liệt kê 19).

<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" url="view1.html">
    External View #1 (sync)
  </li>
  <li dojoType="dojox.mobile.ListItem" url="view2.json" sync="false">
    External View #2 (async)
  </li>
</ul>

<div dojoType="dojox.mobile.View">
  <h1 dojoType="dojox.mobile.Heading" back="Home" moveTo="foo">view1.html</h1>
  <ul dojoType="dojox.mobile.EdgeToEdgeList">
    <li dojoType="dojox.mobile.ListItem">
      Jack Coleman
    </li>
    <li dojoType="dojox.mobile.ListItem">
      James Evans
    </li>
    <li dojoType="dojox.mobile.ListItem">
      Jason Griffin
    </li>
  </ul>
</div>

{
  "dojox.mobile.View": {
    "dojox.mobile.Heading": {
      "@back": "Home",
      "@moveTo": "foo",
      "@label": "view1.json"
    },
    "dojox.mobile.EdgeToEdgeList": {
      "dojox.mobile.ListItem": [{
        "@label": "Jack Coleman"
      }, {
        "@label": "James Evans"
      }, {
        "@label": "Jason Griffin"
      }]
    }
  }
}

Một lựa chọn khác là tìm nạp nội dung khung nhìn theo lập trình và chèn nó vào khung nhìn đích. Liệt kê 20 cho thấy một ví dụ.

<li dojoType="dojox.mobile.ListItem" moveTo="#" onclick="myAction2(this)">
  Load and Move (async)
</li>
----
function myAction2(li){
   var view2 = dijit.byId("view2"); // destination view
   var listItem = dijit.byNode(li);
   var prog = dojox.mobile.ProgressIndicator.getInstance();
   dojo.body().appendChild(prog.domNode);
   prog.start();
   view2.destroyDescendants();

   var url = "http://..."; // or var url = listItem.url;
   dojo.xhrGet({
       url: url,
       handleAs: "text",
       load: function(response, ioArgs){
           var container = view2.containerNode;
           container.innerHTML = response;
           dojo.parser.parse(container);
           prog.stop();
           listItem.transitionTo("view2");
       }
   });
}

Xem dojox/mobile/tests/test_list-actions.html để biết các chi tiết và nhiều ví dụ hơn nữa.

Tải-rất chậm bằng IconContainer

IconContainer (Thùng chứa biểu tượng) có thể có nhiều biểu tượng, mỗi biểu tượng đại diện cho một ứng dụng con. Các ứng dụng con có thể có một hoặc nhiều tiện ích Dojo. Việc tải tất cả các mã ứng dụng con lúc khởi động có thể làm chậm thời gian khởi động của ứng dụng chính. Để cải thiện hiệu năng thời gian khởi động, bạn có thể chỉ rõ tham số lazy="true" trên các IconItem (các mục biểu tượng). Sau đó trình phân tích cú pháp bỏ qua việc tạo các tiện ích bên trong IconItem và IconContainer tải động các mô đun nội dung biểu tượng đó và chỉ tạo chúng khi lần đầu tiên mở một biểu tượng.

Liệt kê 21 là một ví dụ về việc tải rất chậm các nội dung biểu tượng. Lưu ý rằng bạn không phải yêu cầu rõ các mô đun nội dung biểu tượng (dijit.CalendarLite trong ví dụ sau). Cũng lưu ý rằng, trong Dojo 1.7, việc tải rất chậm chỉ được hỗ trợ trong chế độ bộ tải (loader) đồng bộ, do việc tải rất chậm được thực hiện đồng bộ khi sử dụng dojo.require.

<ul dojoType="dojox.mobile.IconContainer">
  <li dojoType="dojox.mobile.IconItem" label="Calendar" lazy="true">
    <div id="cal" dojoType="dijit.CalendarLite"></div>
  </li>
  ....

Tải rất chậm với TabBar

Nếu cần các ô cửa sổ tab có thể nạp rất chậm, bạn có thể sử dụng tiện ích TabBar và các kỹ thuật tương tự như được mô tả trong "Tạo một khung nhìn động." Đối với các ô cửa sổ tab, bạn cũng cần một thủ thuật nhỏ cho ô cửa sổ tab đầu tiên, vì không có quá trình chuyển tiếp khung nhìn nào lúc khởi động. Bạn cần tạo một quá trình chuyển tiếp khung nhìn theo lập trình từ một khung nhìn rỗng giả đến ô cửa sổ tab đầu tiên lúc khởi động để tải các nội dung bên ngoài vào ô cửa sổ tab đầu tiên. Liệt kê 22 và Liệt kê 23 cho thấy các ví dụ tương tự; Liệt kê 22 là một ví dụ đồng bộ, Liệt kê 23 là một ví dụ không đồng bộ.

  <script src="../../../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
    dojo.require("dojox.mobile");
    dojo.require("dojox.mobile.parser");
    dojo.require("dojox.mobile.compat");
    dojo.require("dojox.mobile.TabBar");
    dojo.ready(function(){
      setTimeout(function(){
        dijit.byId("tab1").onClick();
      }, 0);
    });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton" url="view1.html">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton" url="view2.html">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton" url="view3.html">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>

  <script src="../../../dojo/dojo.js" djConfig="async: true, parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
  require([
    "dojo/_base/kernel",
    "dijit/registry",
    "dojox/mobile",
    "dojox/mobile/compat",
    "dojox/mobile/parser",
    "dojox/mobile/TabBar"
  ], function(dojo, registry){
    dojo.ready(function(){
      setTimeout(function(){
        registry.byId("tab1").onClick();
      }, 0);
    });
  });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton"
        url="view1.html" sync="false">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton"
        url="view2.html" sync="false">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton"
        url="view3.html" sync="false">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>

Yêu cầu các mô đun động

Việc yêu cầu các mô đun động trong thời gian chạy là một ý tưởng tốt, vì nó có thể cải thiện hiệu năng thời gian khởi động. Nhưng có một vấn đề tiềm ẩn mà bạn cần phải biết rõ. Hãy xem trong Liệt kê 24; Liệt kê này hiển thị việc tải một mô đun Dojo theo lập trình. Nó vẫn hoạt động, nhưng nếu bạn xây dựng Liệt kê 24, thì công cụ xây dựng tự động sẽ chọn mô đun cần thiết và gói nó vào một quá trình xây dựng và do đó dojo.require không làm gì trong thời gian chạy kể từ khi đã tải mô đun đó lúc khởi động.

myHandler: function(e){
  dojo.require("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

Để tránh vấn đề đó, bạn có thể viết dojo["require"] thay vì dojo.require như trong Liệt kê 25.

myHandler: function(e){
  dojo["require"]("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

Nếu ứng dụng của bạn đang sử dụng bộ tải không đồng bộ, cú pháp sẽ khác như được hiển thị trong Liệt kê 26. Nhưng đây không phải là một ví dụ tốt, do công cụ xây dựng bất ngờ chọn mô đun đã quy định nếu bạn viết mã theo cách này.

myHandler: function(e){
  require(["dijit/CalendarLite"], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

Bạn có thể tránh các vấn đề xây dựng bằng cách gán tên lớp cho một biến như trong Liệt kê 27.

myHandler: function(e){
  var cls = "dijit/CalendarLite"; // assign to a variable so as not to be in the build
  require([cls], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

Về đầu trang

Chế độ không đồng bộ

Trong Dojo 1.7, một bộ tải AMD (Asynchronous Module Definition - Định nghĩa mô đun không đồng bộ) được cung cấp ngoài bộ tải truyền thống Dojo. Các tiện ích Dojo Mobile được viết bằng cú pháp AMD mới. Để tải bất kỳ các mô đun Dojo nào, bạn có thể sử dụng hoặc dojo.require truyền thống (Liệt kê 28) hoặc API require mới (Liệt kê 29).

<script src="../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
<script language="JavaScript" type="text/javascript">
  dojo.require("dojox.mobile");
  dojo.require("dojox.mobile.parser");
  dojo.require("dojox.mobile.compat");
</script>

<script src="../dojo/dojo.js" djConfig="async:true, parseOnLoad:true"></script>
<script language="JavaScript" type="text/javascript">
  require([
    "dojox/mobile",
    "dojox/mobile/parser",
    "dojox/mobile/compat"
  ]);
</script>

Liệt kê 28 tải đồng bộ các mô đun, trong khi Liệt kê 29 tải nó không đồng bộ. Trong các trường hợp ở đó tải rất nhiều các tệp JavaScript, hy vọng rằng việc tải không đồng bộ sẽ thực hiện tốt hơn so với tải đồng bộ. Tuy nhiên, nếu các tệp JavaScript được kết hợp lại với nhau thành một tệp xây dựng đơn lẻ, thì có thể không có nhiều sự khác biệt giữa tải đồng bộ và tải không đồng bộ.

Tuy nhiên, có một sự khác biệt lớn hơn mà bạn cần biết rõ. Hình 18 cho thấy các tệp được chuyển giao khi mở tệp test_iPhone Animation.html để tải các mô đun theo cách của Liệt kê 28 và Hình 19 cho thấy các tệp được chuyển giao khi mở tệp test_iPhone-Animation-async.html để tải mô đun theo cách của Liệt kê 29. Như hiển thị trong Bảng 5, ở chế độ đồng bộ, có nhiều hơn 17 tệp, với tổng dung lượng là 26KB, được tải thêm. Điều này là do chế độ đồng bộ làm việc trong chế độ tương thích ngược và do đó phải tải một số mô đun cần thiết để duy trì khả năng tương thích ngược. Dựa vào vào test_iPhone-Animation-async.html hoạt động mà không có các mô đun bổ sung đó, rõ ràng là chúng không được sử dụng và vẫn chưa được tải. Vì vậy, ngay cả khi bạn lựa chọn cẩn thận các mô đun cần sử dụng và tối ưu hóa quá trình xây dựng của mình bằng cách sử dụng tùy chọn customBase, việc sử dụng dojo.require() có thể làm hỏng nỗ lực của bạn. Bạn nên sử dụng API require chứ không phải là dojo.require() để tối ưu hóa hiệu năng ứng dụng của mình.

Ngẫu nhiên là, ngay cả khi bạn sử dụng cú pháp AMD như Liệt kê 29, nếu bạn không chỉ rõ async:true (giá trị mặc định là false), ứng dụng của bạn sẽ chạy trong chế độ tương thích và các mô đun bổ sung sẽ được nạp.

Về đầu trang

dojox.mobile.parser

dojox.mobile.parser là một tập con nhỏ của dojo.parser. Nó đã được phát triển chỉ để làm giảm kích cỡ mã. Nó không có các tính năng bổ sung đặc trưng di động nào so với dojo.parser, vì vậy không có lý do nào buộc bạn phải sử dụng dojox.mobile.parser để thay cho dojo.parser, bạn có thể chọn một cái bạn thích. Một số tính năng nâng cao của dojo.parser, chẳng hạn như <script type="dojo/method"> và <script type="dojo/connect">, không có trong dojox.mobile.parser. Nhưng dojox.mobile.parser có dung lượng nhỏ hơn.

Như hiển thị trong Bảng 6, dung lượng của dojox.mobile.parser khoảng 0,7KB (đã rút gọn và đã nén), trong khi dojo.parser (cộng với các mô đun phụ thuộc của nó mà cơ sở dojox.mobile không yêu cầu) là 6,5KB. Nếu dung lượng của dojox.mobile.parser là đủ cho ứng dụng của bạn, thì việc sử dụng nó có thể làm giảm dung lượng mã của ứng dụng của bạn.

Về đầu trang

Tóm tắt

Bài này đã cho thấy cách xây dựng các ứng dụng web di động nhẹ bằng cách sử dụng Dojo Mobile và cách áp dụng các kỹ thuật tối ưu hóa hiệu năng của nó cho các ứng dụng của bạn.

Tài nguyên

Học tập

• Tìm hiểu về các tính năng di động của Dojo.
  
  
• Đọc tài liệu hướng dẫn dojox.mobile mới nhất.
  
  
• Dùng thử các bài kiểm tra xây dựng trung lập tự động của Dojo Mobile 1.7 mới nhất .
  
  
• Trong Vùng phát triển Web trên developerWorks, tìm thấy hàng trăm bài báo hướng dẫn và các hướng dẫn khác, cũng như các bản tải về, các diễn đàn thảo luận và tài nguyên phong phú khác cho các nhà phát triển web.
  
  
• Xem các bản cập nhật di động trên blog phát triển di động của developerWorks.
  
  
• Bạn sẽ tìm thấy nhiều bài viết về các chủ đề di động, gồm các bài viết trên Dojo Mobile trên developerWorks.
  
  
• Theo sát với webcast và các sự kiện kỹ thuật của developerWorks được tập trung vào một loạt các sản phẩm của IBM và các chủ đề ngành công nghiệp công nghệ thông tin.
  
  
• Tham dự một lớp hướng dẫn developerWorks Live! miễn phí để tăng tốc độ nhanh chóng dựa trên các sản phẩm và các công cụ của IBM, cũng như các xu hướng của ngành công nghiệp công nghệ thông tin.
  
  
• Xem các trình diễn theo yêu cầu của developerWorks, trải rộng từ các trình diễn cài đặt và thiết lập sản phẩm cho người mới bắt đầu đến các chức năng nâng cao cho các nhà phát triển có kinh nghiệm.
  
  
• Theo dõi developerWorks trên Twitter.
  
  

Lấy sản phẩm và công nghệ

• Tải về Dojo 1.7 mới nhất từ trang tải Dojo Toolkit.
  
  
• Tải về và dùng thử Xem trước Công nghệ di động của IBM, một tập các mẫu mã và các dịch vụ để giúp bạn bắt đầu xây dựng các ứng dụng di động để mở rộng và tích hợp vào doanh nghiệp. Bài xem trước này gồm có một dịch vụ thông báo RESTful; PhoneGap, một khung công tác nguồn mở để xây dựng các ứng dụng di động lai; một thời gian chạy của WebSphere Application Server nhẹ; và mã mẫu để cho bạn xem tất cả hoạt động thế nào.
  
  
• Gói tính năng WebSphere Application Server cho Web 2.0 và Di động của IBM gồm có Bộ công cụ Dojo 1.7 của IBM, các khối xây dựng ứng dụng Internet phong phú (RIA) và di động mới và một thành phần biểu đồ dựa trên Dojo. Với các công cụ Rational kèm theo, Gói tính năng này giúp bạn nhận được các ứng dụng WebSphere ban đầu được phát triển cho các trình duyệt máy tính để bàn và thích ứng và triển khai chúng cho các thiết bị di động.
  
  
• Đánh giá các sản phẩm của IBM theo cách phù hợp với bạn nhất: Tải về nó để dùng thử, dùng thử nó trực tuyến, sử dụng nó trong một môi trường đám mây hoặc dành một vài giờ trong SOA Sandbox để tìm hiểu cách thực hiện kiến trúc hướng dịch vụ có hiệu quả.
  
  

Thảo luận

• Hãy tham gia vào cộng đồng developerWorks. Kết nối với những người dùng developerWorks khác trong khi khám phá các blog, các diễn đàn, các nhóm và các wiki dựa vào nhà phát triển.
  
  

Đôi nét về tác giả

Yoshiroh Kamiyama là một kỹ sư tư vấn phần mềm tại Phòng thí nghiệm phần mềm Yamato (YSL - Yamato Software Lab), Nhật Bản của IBM. Ông làm về Gói tính năng WebSphere cho Web 2.0 và di động (WebSphere Feature Pack for Web 2.0 and Mobile) và trước đó ông đã làm về một số dự án phát triển gồm Ứng dụng Mobile Mashup (hỗn hợp di động), Lotus iNotes và Rational Portfolio Manager (Trình quản lý danh mục Rational), nhiều dự án trong số đó sử dụng Bộ công cụ Dojo. Ông là một người đóng góp ban đầu của dojox.mobile và người đóng góp hàng đầu cho Bộ công cụ Dojo (Dojo Toolkit).

Chấm điểm bài này

Bình luận

Về đầu trang

Mục lục

• Giới thiệu Dojo Mobile
• Các tiện ích giao diện người dùng không dùng hình ảnh
• CSS Sprite
• Nút ấn DOM
• Mô đun tương thích
• Các phụ thuộc của mô đun
• Xây dựng
• Gộp chung CSS
• Tạo động và tải rất chậm
• Chế độ không đồng bộ
• dojox.mobile.parser
• Tóm tắt
• Tài nguyên
• Đôi nét về tác giả
• Bình luận