Мобільне програмування: Рекомендації щодо створення адаптуються користувальницьких інтерфейсів за допомогою Mobile Internet Toolkit

У статті даються рекомендації щодо створення мобільних Web? Додатків і фільтрів пристроїв за допомогою набору Microsoft Mobile Internet Toolkit, що адаптується під дисплеї багатьох мобільних пристроїв типу PDA (Personal Digital Assistants), в тому числі Pocket PC, стільникових телефонів з підтримкою Web, пейджерів і т. д.


Введення

Microsoft® Mobile Internet Toolkit (MIT) надає інструменти для створення додатків, орієнтованих на мобільні пристрої. Цей інструментальний набір дозволяє розробити додаток, здатне адаптуватися до дисплеїв найрізноманітніших мобільних пристроїв – персональних цифрових помічників (Personal Digital Assistants, PDA), наприклад Pocket PC, стільникових телефонів з підтримкою Web, пейджерів і т. д. Додаткові кошти надає Microsoft. NET, яка спрощує розгортання мобільних додатків на окремих серверах або великих серверних фермах.

Ці рекомендації допоможуть вам створювати ефективні фільтри пристроїв та мобільні Web? Програми, однак їх не слід розглядати як вичерпне керівництво і як щось обов'язкове без урахування контексту розв'язуваної вами завдання. Дотримуючись даних рекомендацій, ви зможете створювати мобільні Web? Програми світового класу.

Архітектура та особливості розгортання мобільних додатків

Мобільними називаються програми, до яких можуть звертатися мобільні пристрої. Мобільні пристрої характеризуються широкою різноманітністю розмірів і якості дисплеїв, смуг пропускання і підтримуваних протоколів. Mobile Internet Toolkit знімає з вас велику частину тягаря з відображенням інформації на мобільних пристроях. Однак, крім проблем з дисплеями, в мобільному додатку потрібно враховувати і ряд інших факторів, які відрізняють його від звичайних Web-додатків.

Приймайте до уваги наступні обмеження мобільних пристроїв і відповідних мереж.


Планування: цілі розробки

На стадії планування будь-якої програми важливо правильно визначити цілі розробки, від яких залежить вибір найбільш ефективної стратегії його розгортання.

Більша частина відомостей з документації Microsoft. NET Framework застосовна і до розробки мобільних додатків.

Розробка мобільного застосування

При розподілі завдань між клієнтом і сервером слід пам'ятати про два цілях. По-перше, ви повинні звести до мінімуму обмін даними по HTTP-з'єднання (Hypertext Transfer Protocol). Яким би швидким воно не було, обробка на клієнті завжди швидше. Пересилати інформацію між клієнтом і сервером потрібно лише в разі крайньої необхідності.

По-друге, клієнтові повинні бути доступні тільки ті серверні ресурси, які є абсолютно необхідними йому для виконання свого завдання. Кожен запит повинен повністю ідентифікувати клієнт, щоб сервера не доводилося звертатися до нього за додатковою інформацією, збільшуючи число обмінів даними по з'єднанню.

Якщо клієнт здатний повністю описати свої можливості при запиті до сервера (наприклад, ідентифікувати себе як PDA з кольоровим дисплеєм), сервер негайно відправить відповідь, відповідний можливостям клієнта, і не стане запитувати додаткові відомості (щоб, наприклад, з'ясувати, чи підтримує дисплей клієнта кольорові зображення). Ця концепція застосовна і до розробки Web? Додатків, що надають доступ до бази даних. Так, при перевірці статусу замовлення клієнт повинен використовувати запит MyDatabase.Recordset, щоб отримувати інформацію тільки у цій замовлення, а не всі записи в таблиці замовлень.

Визначення інтерфейсу

Створюючи додаток, продумайте, яка його цільова аудиторія. Якщо програма розрахована на користувачів як настільних комп'ютерів, так і мобільних пристроїв, введіть у його версію для настільних систем функціональність, що дозволяє налаштовувати мобільну версію.


Створення компонентів для користувача інтерфейсу

Інтерфейс користувача (UI) може містити меню, а також форми для введення і відображення інформації, які можуть звертатися до наборів даних. Хороший підхід – написати детальні сценарії застосування додатки (storyboard). Кожен такий сценарій стає формою, а кожен його розділ – сторінкою. Продумайте наступні компоненти UI:


Інші методи доступу до даних

Ще один метод доступу до даних – відключити стан відображення (view state) і зберігати локальну копію даних. Тоді при кожному запиті дані пов'язуються з локальною копією. Наприклад, у папці вхідної пошти можуть зберігатися локальні копії листів.

У багатьох сценаріях доступу до даних використовується кешування. Як розробник, ви можете організувати користувальницький кеш. Наприклад, це дозволяє повністю обробляти лише перший запит на поточні новини. Всі подальші запити перенаправляються локального кешу.

Інтеграція з сайтами, розрахованими на взаємодію з настільними системами

Перенаправляйте користувачів з однієї сторінки Web Forms на іншу, більш придатну для браузера даного користувача. Припустимо, у вас є сайт, призначений для взаимодейсвтия з настільними системами (Desktop site), і ви хочете створити його мобільну версію з тим же URL. Для цього можна створити мобільний. Aspx? Файл і помістити в обробник завантаження сторінки наступний код:


if (Device.IsMobileDevice)
RedirectToMobilePage(“MyMobilePage.aspx”);
else
Response.Redirect(“MyDesktopPage.aspx”);

Приклади поєднання мобільних і "настільних" сайтів див. на Web? Сайті IBuySpy (http://www.ibuyspy.com/).

Настроювані подання

Можливість налаштування зовнішнього вигляду програми підвищує зручність роботи користувачів, не заважаючи рендеринга за замовчуванням. Як правило, при створенні настроюваних уявлень не слід використовувати елементи, порушують модель UI. Замість цього:


Продуктивність

При створенні адаптуються UI розробники повинні брати до уваги ті ж параметри, що і для звичайних Web? Додатків:

Більш докладну інформацію див Collecting Performance Data на Duwamish Online.

Універсальні способи підвищення продуктивності

Підвищити продуктивність програми можна наступними способами.


Можливості тестування

Розробляючи адаптуються UI для мобільних пристроїв, завжди включайте підтримку перегляду "найменшого спільного знаменника" ("lowest common denominator" browsing capability), щоб ви могли контролювати зовнішній вигляд свого застосування.

По-справжньому протестувати свій додаток ви можете лише на реальних пристроях, на які вона розрахована. Список пристроїв наведено в розділі "Requirements and Supported Devices" онлайнової документації.

По можливості опублікуйте додаток в Інтернеті, щоб на практиці перевірити його взаємодія з мобільними пристроями.

Глобалізація і локалізація

Глобалізованому додаток підтримує локалізовані UI і регіональні стандарти.

Можливо, вам буде потрібно налаштовувати кодування за замовчуванням для певних пристроїв та мовні параметри. Основний спосіб задати тип кодування – налаштувати параметри в розділі <globalization> файлу machine.config. Два головних параметри, що дозволяють змінювати кодування за замовчуванням:

Ось приклад установки цих параметрів у machine.config:


<globalization
requestEncoding=”utf-8″
responseEncoding=”utf-8″
/>

Ці параметри впливають на весь комп'ютер. Якщо ви хочете модифікувати їх тільки для одного Web? Програми, внесіть зміни до розділу <globalization> конфігураційного файлу (web.config), який знаходиться в кореневому каталозі додатку.

Більш детальну інформацію про розробку глобальних додатків див Building. NET Framework Applications в Microsoft. NET Framework Developer "s Guide.

Рендеринг

Детальний опис рендеринга засобами Mobile Internet Toolkit наводиться в онлайновій документації і може бути порушено у майбутніх документах. А тут даються рекомендації по кешуванню виведення і рендерінг на різних пристроях.

Кешування виведення

Сторінки Web Forms в Microsoft ASP.NET включають автоматичну підтримку кешування виведення. Сторінка кешується директивою @ OutputCache.

У мобільних сторінках Web Forms вміст кешу виведення потрібно варіювати залежно від цільового пристрою. Наприклад, якщо сторінка запитується пристроєм з Microsoft Internet Explorer для Pocket PC, то отримана інформація повинна міститися в кеш і передаватися тільки іншим пристроям з Internet Explorer для Pocket PC.

За умовчанням вміст кешу мобільних сторінок Web Forms розрізняється по рядку HTTP? Агента користувача. Однак деякі пристрої можуть відрізнятися додатковими властивостями виводу. Так, пристрій з єдиною рядком агента користувача може мати різні властивості відображення і розміру екрану, кожне з яких здатне впливати на виведену інформацію. Щоб врахувати ці відмінності, адаптер сторінки повинен перевизначати властивість CacheVaryByHeaders.

Елементи управління Web Forms в ASP.NET також підтримують директиву OutputCache для незалежного кешування їх виведення. Цей механізм називається роздільним кешуванням (partial caching). Проте для користувача елементи керування в мобільних сторінках Web Forms не підтримують цю директиву. Мобільні сторінки Web Forms не підтримують роздільне кешування, оскільки висновок від призначеного для користувача елемента управління може змінюватись в залежності від вмісту іншої частини сторінки.

Апаратно-залежний рендеринг

Хоча мобільні сторінки Web Forms здатні автоматично виконувати рендеринг під різні пристрої, вони надають масу засобів для налаштування відображення контенту під конкретний пристрій або клас пристроїв, що дозволяє розробнику задіяти переваги специфічної функціональності даного пристрою.

Рекомендації по фільтрах пристроїв

При створенні та управлінні фільтрами пристроїв враховуйте наступне.


Введення даних

Проектуючи введення даних, подумайте над способами ефективного методу введення / вибору даних.

У мобільних пристроях (особливо телефонах) слід застосовувати покроковий метод введення інформації і не користуватися HTML? Сторінками, що відображають всі поля введення відразу. Такі сторінки припускають наявність у користувача позиціонує пристрою, що дозволяє вибирати поля і вводити дані в будь-якому порядку. Для мобільних клієнтів потрібно більш прямолінійний підхід. На початковій сторінці може бути поле для введення імені, а під ним – кнопка пошуку. У мобільному додатку може знадобитися розмістити таке поле або елементи управління пошуком на першій із серії форм введення.

Також не забувайте про те, що обсяг даних на сторінці він впливає на кількість звернень до сервера.

Для організації вводу даних використовуйте елемент управління SelectionList наступним способом.


Навігація в мобільних додатках

У цьому розділі описуються обмеження і особливості навігації в додатках для мобільних пристроїв, а також рекомендації щодо адаптації існуючих додатків до цих вимог.

Наприклад, при адаптації існуючого HTML? Програми виникає спокуса перетворити кожну кнопку панелі інструментів (toolbar) в посилання на формі. Але краще створити елемент управління List і представити кожну таку кнопку як посилання в цьому списку.

При перегортуванні багатосторінкового списку використовуйте властивість Form.CurrentPage, щоб позначати потрібну сторінку і переходити на неї.

Питання безпеки

. NET Framework надає модель захисту з прав доступу коду (code access security model), що дозволяє адміністраторам настроювати політику безпеки відповідно до потреб. Неправильна політика безпеки може призвести до появи уразливих місць. Більш докладну інформацію див Code Access Security Model в Microsoft. NET Framework Developer "s Guide.

Елементи управління Mobile Web Forms залежать від. NET Framework і можуть виявитися непридатними через будь-яких змін до них. NET Framework. Тому версія мобільних елементів управління і версія. NET Framework повинні збігатися.

Захист ресурсів

Переконайтеся, що у сеансах не використовуються cookie. Вони не годяться для управління сеансами на мобільних пристроях просто тому, що не всі такі пристрої їх підтримують. На Web? Фермах застосовуйте стан сеансу SQL (SQL session state), якщо тільки ви не використовуєте стан відображення і стану сеансу.

Завжди використовуйте MobileFormsAuthentication.RedirectFromLoginPage замість FormsAuthentication.RedirectFromLoginPage і MobileFormsAuthentication.SignOut замість FormsAuthentication.SignOut. У разі невірної сигнатури ви не зможете працювати з пристроями, не підтримують cookie і використовують UP.Link.

MobileFormsAuthentication взаємодіє з FormsAuthentication з ASP.NET. Для аутентифікації користувачів можна задіяти розділ <credentials> в web.config або організувати нестандартне аутентифікацію.

Наприклад, можна автентифікувати користувачів по іменах і паролів з бази даних або за допомогою служби каталогів Microsoft Active Directory ™. Після аутентифікації слід викликати метод FormsAuthentication.SetAuthCookie, поміщає аутентифікаційні cookie в набір HttpResponse.Cookies. Потім викличте MobileFormsAuthentication.RedirectFromLoginPage. Якщо пристрій не підтримує перенаправлення через cookie, MobileFormsAuthentication видалить відповідний набір. В обох випадках cookie аутентифікації додається до URL як строкова мінлива запиту. При повторних запитів з наданням cookie аутентифікації MobileFormsAuthentication більше не додає цей cookie до URL. А якщо cookie не надається (пристрій не підтримує cookie), він завжди додається до URL.

Нижче наведені приклади конфігураційних файлів і коду для виконання аутентифікації через MobileFormsAuthentication.

web.config


<authentication mode=”Forms”>
<Forms loginUrl = "login.aspx" name = "nameOfAuthCookie" timeout = "60"
path=”/” >
<credentials passwordFormat=”Clear”>
<user name=”username” password=”password”/>
</credentials>
</forms>
</authentication>

login.aspx


<%@ Page Inherits=”System.Web.UI.MobileControls.MobilePage”
Language=”c#” %>
<%@ Register TagPrefix=”Mobile”
Namespace=”System.Web.UI.MobileControls”
Assembly=”System.Web.Mobile” %>
<%@ Import Namespace=”System.Web.Security” %>
<%@ Import Namespace=”System.Web.Mobile” %>
<Mobile:Form id=”formA” runat=server Paginate=”True”>
<Mobile:Label Runat="server"> Enter username </ Mobile: Label>
<Mobile:TextBox Id="txtUsername" runat="Server" Text="username" />
<Mobile:Label Runat="server"> Enter password </ Mobile: Label>
<Mobile:TextBox Id="txtPassword" runat="Server" Text="password" />
<Mobile:Command runat=”Server” OnClick=”Login_Click”
SoftkeyLabel=”Login” ID=”Command1″
NAME=”Command1″>Go</Mobile:Command>
<Mobile:Label runat=”server” id=”lblError” />
</Mobile:Form>
<script language=”c#” runat=server>
void Login_Click(Object sender, EventArgs e)
{
if(IsAuthenticated(txtUsername.Text, txtPassword.Text))
{
FormsAuthentication.SetAuthCookie(txtPassword.Text, false);
MobileFormsAuthentication.RedirectFromLoginPage (txtPassword.Text, true);
}
else
{
lblError.Text = “Please check your credentials”;
}
}
bool IsAuthenticated(String user, String password)
{/ / Перевірка аутентифікації
if(FormsAuthentication.Authenticate(user, password))
{
return true;
}
else
{
return false;
}
}
</script>

Page1.aspx


<%@ Register TagPrefix=”mobile”
Namespace=”System.Web.UI.MobileControls”
Assembly=”System.Web.Mobile” %>
<%@ Page language=”c#”
Inherits=”System.Web.UI.MobileControls.MobilePage”
AutoEventWireup=”true” %>
<mobile:Form id=Form1 runat=”server”>
<mobile:Label id=label1 runat=”server”
Text=”Authenticated!”></mobile:Label>
</mobile:Form>

Додайте ці три файли до IIS? Додатком і відкрийте сторінку Page1.aspx. Ви будете перенаправлені на сторінку Login.aspx для реєстрації. Після успішної реєстрації ви повернетеся на сторінку Page1.aspx.

Документи на суміжну тематику

Перш ніж продовжити читання цього документа, рекомендується прочитати:


Рекомендації з розробки мобільних елементів управління

При розробці мобільних елементів управління дотримуйтеся наступних рекомендацій.


Універсальні процедури та рекомендації щодо використання дизайнера

При розробці програми за допомогою Mobile Internet Designer дотримуйтеся наступних рекомендацій.


Загальні рекомендації

Також при розробці враховуйте наступне.

При розміщенні елементів управління в шаблонах будь-які властивості цих елементів можуть бути пов'язані з якою-небудь структурою в сценарії, що дозволяє маніпулювати елементом не безпосередньо, а через цю структуру.

Проте пов'язання з даними не вирішує проблеми програмного керування сторінкою. Ви можете спростити рішення і його супровід, використовуючи метод HasCapability, оскільки він є частиною реалізації елемента <DeviceSpecific>.

Для WML-браузерів і пристроїв, здатних працювати з декількома формами в розмітці, можна об'єднувати форми в групу і не звертатися до сервера для запиту кожної форми окремо. Форма, що містить навігаційні елементи, які активізують іншу форму без звернення до сервера, називається зв'язаною (linked form).

Наприклад, форма B пов'язана з формою A, якщо виконуються наступні умови:

Якщо елемент керування містить посилання формату # form1, метод ResolveFormReference шукає форму за значенням властивості id форми form1 з користувальницького елемента керування. Якщо форма не знайдена, метод ResolveFormReference переглядає вкладені елементи управління по ланцюжку вгору і шукає форму на сторінці.

Інформація з синтаксису

Область дії поширюється вгору, а не вниз по ієрархії. Якщо ви хочете послатися на форму, яка міститься в призначеному для користувача елементі управління, ідентифікуйте її так:


#mc1:form4

У цьому виразі mc1 – ідентифікатор користувача елемента керування. Двокрапка відділяє посилання на форму.

Примітка Анкери елементів (URL типу page.aspx # element) не підтримуються, якщо page не є поточною сторінкою.

Оптимізація стану відображення для мобільних додатків

Для мобільних сторінок Web Forms важливо враховувати наступні аспекти.

Збереження стану відображення в сеансі високо оптимізовано. Якщо інформації для запису немає, нічого не зберігається, і ніякого ідентифікатора клієнтові не надсилається. Але якщо вам не потрібен механізм управління сеансами або якщо ви хочете створювати сторінки з високою пропускною здатністю, подумайте про повну відмову від використання стану відображення. У багатьох випадках (наприклад, при рендерінгу сторінки форматованого тексту) стан відображення не потрібно, і його краще вимкнути.

Окрім стану відображення, існують і інші види інформації про стан сторінки, що зберігається в мобільній сторінці Web Forms. До її складу можуть входити відомості про активній формі або про розбивку форми на сторінки. Така інформація не зберігається на сервері, а завжди відправляється клієнту і, як правило, оптимізується. Наприклад, якщо активна перша форма або відображається перша сторінка форми, відповідна інформація не зберігається, оскільки цей стан за замовчуванням. Подібна інформація називається приватним станом відображення (private view state). Всі елементи управління можуть перевизначати методи LoadPrivateViewState і SavePrivateViewState для читання і запису приватного стану відображення.

Обмеження

У цьому розділі розповідається про обмеження Mobile Internet Toolkit.

Обмеження середовища

Інтегроване середовище розробки (IDE) Mobile Internet Designer для Microsoft Visual Studio® . NET накладає кілька обмежень на маніпуляції з елементами управління. Вони проявляються, якщо ви, наприклад, помилково помістіть елемент у неприпустиме місце або невірно напишете слово в директиві @Register.

Обмеження елементів управління

Дизайнер не запобігає невірного розміщення елементів управління, а лише виводить повідомлення про помилку. Щоб уникнути таких помилок, дотримуйтеся наступних рекомендацій.

Завжди:

Ніколи:

Помилки, пов'язані зі сторінками

Такі помилки виникають при завантаженні мобільного сторінки Web Forms з мобільними елементами управління Web Forms в Visual Studio. NET IDE, якщо директива @ Register відсутній або некоректна.

Якщо в середу Visual Studio. NET завантажується сторінка з мобільними елементами управління і правильної директивою @ Register, але сама сторінка не належить до типу MobilePage, відображається наступне повідомлення про помилку:


“This control only works in pages of type MobilePage.”

Порушення правил розміщення

Якщо помістити елемент управління ASP.NET Web Forms на мобільний сторінку Web Forms за межами шаблону, з'являється повідомлення про помилку:

"This page can only support non-mobile controls in templates. Please delete this control or move it into a template." ("Немобільні елементи управління можуть бути розміщені на цій сторінці тільки в межах шаблону. Будь ласка, видаліть цей елемент або перенесіть їх у шаблон. ")

Щоб усунути цю помилку, перемістіть або видаліть цей елемент керування.

Обмеження контейнерів також забороняють розміщувати:


Обмеження за кількістю

Якщо на сторінку додається декілька елементів StyleSheet, другий елемент StyleSheet відключається, і при рендерінгу видається повідомлення про помилку. Якщо перший елемент StyleSheet видаляється, активним стає другий.

Якщо в контейнері розміщується кілька елементів DeviceSpecific, другий елемент відключається, і при рендерінгу видається повідомлення про помилку. Якщо перший елемент видаляється, активним стає другий.

Параметри налагодження

У цьому розділі описуються розділи конфігураційного файлу додатки (web.config), призначені для налагодження. В основному вам не доведеться їх змінювати, але ця інформація стане в нагоді для настройки середовища налагодження.

Динамічна налагоджувальна компіляція

Для налагодження. Aspx? Файлів встановіть параметр <compilation debug="true"/>:


<compilation defaultlanguage=”c#” debug=”true” />

Присвоєння йому значення false підвищує продуктивність програми. Цим параметром можна управляти індивідуально для кожної сторінки, поміщаючи в неї директиву @ Page:


<%@ Page ….. Debug=”True” %>

Нестандартні повідомлення про помилки

Ви можете визначити набір сторінок для повідомлень про помилки. При виникненні помилки ASP.NET визначає, чи налаштована додаток на відображення власних повідомлень про помилки і чи існує сторінка для даної помилки. Якщо така сторінка є, ASP.NET замінює стандартне повідомлення про помилку даною сторінкою, передаючи їй параметр з вихідним URL.

Якщо ви дозволяєте висновок нестандартних повідомлень про помилки, але не надаєте сторінки зі своїми повідомленнями, Mobile Internet Controls Runtime передає клієнтським WML-пристроїв реальну помилку. Щоб сторінки з повідомленнями про помилки коректно працювали на таких пристроях, додайте в розділ system.web файлу web.config наступний код:


<configuration>
<system.web>
<customErrors> defaultRedirect=”genericerror.aspx”
mode=”RemoteOnly”>
<error statusCode=”500″ redirect=”InternalError.aspx”/>
</customErrors>
</system.web>
</configuration>

Для мобільних пристроїв, що не підтримують переслані відповіді без повного URL, встановіть параметр useFullyQualifiedRedirectUrl = "true" (наприклад, його потрібно встановлювати для пристроїв i-mode):


<configuration>
<system.web>
<httpRuntime
useFullyQualifiedRedirectUrl=”true”
/>
</system.web>
</configuration>

Протоколювання трасування на рівні додатку

При трасуванні на рівні програми для кожної сторінки в додатку ведеться журнал. Щоб включити протоколювання трасування встановіть параметр trace enabled = "true". Якщо встановлено параметр pageOutput = "true", інформація про трасування відображається внизу кожної сторінки. При використанні цього методу налагодження необхідно, щоб браузером за замовчуванням у Visual Studio. NET був внутрішній браузер.

Якщо в процесі трасування ви хочете переглянути сторінку на емуляторі, встановіть параметр trace enabled = "true", як показано раніше:


<trace enabled="false" requestLimit="0" pageOutput="false" />

або


<trace enabled="true" requestLimit="40" pageOutput="true" />
traceMode=”SortByTime” />

Для перегляду журналу трасування відкрийте в Internet Explorer файл trace.axd з кореневого каталогу вашого Web? Програми.

Примітка У проектах Microsoft Visual C #®, За замовчуванням включений параметр Unmanaged Debugging, а в проектах Microsoft Visual Basic® – Параметр Managed Only Debugging.

Примітка Вам може знадобитися додати в змінну оточення DEVPATH шлях до зв'язуються бібліотекам (link libraries).

Розширюваність

Mobile Web Forms і мобільні елементи управління Web Forms мають ту ж розширюваністю, що і ASP.NET, але крім цього підтримують роботу з багатьма пристроями. Підтримуються наступні механізми розширюваності.


Портал і магазин IBuySpy

IBuySpy Portal Solution Starter Kit знаходиться за адресою www.IBuySpy.com / portal і демонструє, як створювати інтранет? та Інтернет? портали за допомогою ASP.NET і. NET Framework. IBuySpy надає всю функціональність типових порталів, включаючи:

Весь код порталу IBuySpy з комплекту для скачування дозволено безкоштовно використовувати у власних додатках. Але портал можна створити і без єдиної строчки коду. Він надає адміністративні сторінки для налаштування власного порталу, наповнення його інформацією та встановлення правил безпеки.

Крім того, на порталі IBuySpy розміщено безліч модулів, розроблених за допомогою Mobile Internet Toolkit і представляють функціональність порталів для мобільних пристроїв. Фактично на www.IBuySpy.com / portal розміщена і мобільна версія порталу для пристроїв, сумісних з Mobile Internet Toolkit.

Деталі реалізації IBuySpy Portal

Сторінка Default.aspx виконує просту перевірку типу браузера і перенаправляє запит до "настільної" або мобільної версії головної сторінки:


public void Page_Load(Object sender, EventArgs e)
{
if (Request.Browser[“IsMobileDevice”] == “true” ) {
Response.Redirect(“MobileDefault.aspx”);
}
else {
Response.Redirect(“DesktopDefault.aspx”);
}
}

Головна сторінка (default page) – в основному, статична: велика частина роботи виконується іншими компонентами. Так, заголовок, меню, і список "popular items" реалізовані окремими елементами управління, а на сторінку поміщені лише посилання на них.

Сама головна сторінка складається всього з декількох рядків коду для перевірки реєстрації користувача. Якщо користувач зареєстрований, з'являється привітання, яке можна персоналізувати. Персоналізація здійснюється в методі? обробнику Page_Load. Подія (Load) ініціюється на сервері при кожному зверненні браузера до сторінки. Воно дає зручний спосіб структурування серверної логіки, яку слід виконувати при доступі до сторінки. Нижче приведений код головної сторінки.

void Page_Load(Object sender, EventArgs e) {

/ / Налаштувати вітальне повідомлення, якщо є
/ / Відповідний cookie
if (Request.Cookies[“IBuySpy_FullName”] != null) {
WelcomeMsg.Text = “Welcome ” +
Request.Cookies[“IBuySpy_FullName”].Value;
}

}

Вітальне повідомлення генерується при отриманні від клієнта cookie (зберігається на клієнті в сторінках Login.aspx і Register.aspx). Якщо cookie виявлений, з нього витягується ім'я користувача та відображається через серверний елемент управління. Для докладного ознайомлення з генерацією такого cookie вивчіть сторінку Login.aspx.

Зауваження по продуктивності

Оскільки ця сторінка є стартовою для програми IBuySpy Store і використовується частіше за все, її продуктивності приділено особливу увагу. Ми вирішили не поміщати в кеш всю сторінку (на відміну від сторінок ProductDetails і ProductsList), оскільки хотіли зберегти можливість підстроювання сторінки під конкретного користувача.

Для більшої продуктивності були виключені звернення до бази даних при кожному запиті. Замість цього ми зберігаємо всю персональну інформацію (в даному випадку – ім'я користувача) в необов'язковому cookie, зберігається на клієнті.

Користувальницькі елементи управління Menu і PopularItems, навпаки, отримують інформацію з бази даних. Але вони використовують роздільне кешування виведення для зберігання цієї інформації та оновлюють дані всього один раз на годину.

Додаткові відомості про продукт

Для підвищення продуктивності інформація зі сторінки розміщується в кеші. Для цього служить директива @ OutputCache на початку сторінки.


<% @ OutputCache Duration = "60" VaryByParam = "ProductID"%>

У даному випадку ми вирішили встановити період оновлення кешу рівним одній хвилині (60 секундам). ASP.NET автоматично зберігає окремі елементи кешу для кожного значення рядка запиту і витягує інформацію для кожного з наступних запитів.

Інформація, що міститься в цьому документі, відбиває погляд Microsoft з обговорюваної тематики на момент публікації. Оскільки Microsoft повинна реагувати на зміни ринкової кон'юнктури, цю інформацію не слід розглядати як певне зобов'язання з боку Microsoft, і Microsoft не гарантує точність даних відомостей після дати публікації.

Цей документ має виключно інформаційний характер. MICROSOFT НЕ ДАЄ ЖОДНИХ ПРЯМИХ АБО НЕПРЯМИХ ГАРАНТІЙ ЩОДО ІНФОРМАЦІЇ В НЬОМУ.

Користувач зобов'язаний виконувати всі закони про авторські права, застосовні до даного документа. Повне або часткове відтворення документа, зберігання або завантаження, а також передача в будь-якій формі та будь-якими засобами (електронними, механічними, фотокопіюванням, записом та ін) з будь-якою метою без письмового дозволу Microsoft Corporation є порушенням авторського права.

Microsoft може володіти патентами, патентними додатками, товарними знаками, авторськими правами або іншими правами на інтелектуальну власність, пов'язаної з тематикою даного документа. За винятком спеціального письмового ліцензійної угоди з Microsoft, цей документ не дає вам права користуватися будь-якими патентами, товарними знаками, авторськими правами або іншими видами інтелектуальної власності.

Приклади компаній, організацій, продуктів, фізичних осіб і подій, які можуть зустрічатися в даному документі, є вигаданими. Будь-які збіги з реальними компаніями, організаціями, продуктами, особами чи подіями носять випадковий характер.

© 2001 Microsoft Corporation. Всі права захищені.

Microsoft, Visual Studio. NET, Mobile Explorer, Visual Basic і Windows є товарними знаками Microsoft Corporation, зареєстрованими в США і / або в інших країнах.

Назви реальних компаній і продуктів, згадані в документі, можуть бути товарними знаками відповідних власників.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*