Я пользуюсь (с разной степенью регулярности) настольным компьютером, ноутбуком, смартфоном на базе MS Mobile и КПК на базе Palm OS 4. На всех устройствах стоит словарь, карта метро и программа для чтения электронных книг. Всем этим хозяйством я пользуюсь каждый день. Редко, когда одна и та же программа одного производителя, выполняющая одну и ту же функцию, установлена на нескольких устройствах. Обычно же на каждом устройстве своя, уникальная.
Каждое приложение занимает место в постоянной памяти. А перед тем, как его начать использовать, его необходимо установить. Для того, чтобы укомплектовать все устройства словарем, картой метро и читалкой, мне, например, установку придется запустить 12 раз (4 по 3)! Добавьте к этому время на поиск нужной программы, ее скачивание и оплату. Кроме этого, каждая требует изучения всей совокупности функций, своего уникального характера и нуждается в индивидуальном уходе. Это, кстати, останавливает многих от приобретения смартфонов: каждое новое устройство - это новый зоопарк программ.
Хотелось бы найти решение данной проблемы, так чтобы процедуры установки были сведены к минимуму, пользоваться полюбившейся программой можно было во всех доступных средах. И не нужно было на четырех устройствах иметь четыре разных словаря (каждый со своей базой).
До недавней поры не было технической возможности реализовать мои «хотелки» простым и доступным способом, однако времена меняются. Bluetooth, Wi-Fi и другие способы локальной связи уже не экзотика, и решение я вижу в создании гетерогенной среды, где приложение, хранящееся в одном месте (на одном устройстве) можно было запустить на другом устройстве, невзирая на различия в операционных системах устройств и индивидуальные физические особенности каждого из них. Почему я не могу запускать словарь на смартфоне, при этом сама словарная база находилась бы в КПК или в ноутбуке? Пользовательский интерфейс может быть независимой частью программы сродни драйверам устройств в современных операционных системах.
В принципе, данную идею можно реализовать на основе привычной веб-архитектуры. Представьте себе: на одном из устройств крутится веб-сервер с приложением, которое (с помощью браузера) могут использовать все ваши гаджеты со встроенным браузером. Связь между устройствами осуществляется посредством беспроводных коммуникаций. Если любое устройство может быть веб-сервером, то это еще лучше – среда получается гибкая, одно устройство может использовать приложение второго, и наоборот: если у второго есть уникальное приложение, то оно доступно первому. Если на КПК имеется словарь, то и на ноутбуке он также будет доступен.
Но веб-интерфейс даже в современном стероидном варианте (Ajax) имеет ограниченные возможности взаимодействия с пользователем: например, невозможно добавить поддержку управления словарем с помощью soft-keys (команд, связанных со специально выделенными кнопками) смартфонов. Или, например, сенсорный экран КПК подразумевает иную модель взаимодействия, нежели классическая (с применением мыши). Вы, наверное, поняли, к чему я клоню – необходимо полностью отделить программную логику от логики взаимодействия.
Решение я вижу в том, что ядро программы реализует ее внутреннюю логику. Это ядро крутится на устройстве-хозяине (являющееся сервером) и предоставляет внешним клиентам программный интерфейс. Клиенты реализуют пользовательский интерфейс и могут располагаться на устройстве-хозяине или на совершенно ином устройстве (с другой оперативной системой), которое связано с сервером. Логику пользовательских интерфейсов желательно максимальным образом реализовать на стороне сервера, так, чтобы клиентская часть, отвечающая за пользовательский интерфейс (ПИ), была легкой и загружалась на устройство-клиент по возможности незаметным способом. Можно реализовать такую иерархию дистрибуции: если модуль пользовательского интерфейса отсутствует на конечном устройстве, то производится поиск модуля на сервере, в некоей библиотеке готовых ПИ. Если и там его не оказалось, то гаджет ищет нужный модуль в интернете. Если модуль произвела третья компания, то пользователь может его скачать или купить. Кстати, в некоторых случаях вполне можно использовать «неродной» пользовательский интерфейс – пользователь, у которого имеется КПК с сенсорным экраном может довольствоваться ПИ с программными клавишами (то есть ПИ для смартфонов). Он сможет легко нажимать на программные клавиши, отрисованные на сенсорном экране, эмулируя тем самым работу со смартфоном. Когда для данной программы появится поддержка сенсорного экрана, то работа с приложением станет максимально комфортной.
Можно представить обратную ситуацию: под отлично реализованный пользовательский интерфейс создается несколько конкурирующих серверов реализующих необходимую функциональность. Еще одно преимущество отделения ПИ – упрощенная поддержка всеми программами пользователей-инвалидов.
Описанный принцип отлично подпадает под актуальную идею аренды программных продуктов, то есть превращение их в полноценные сервисы. Легко представить сеть беспроводных серверов, покрывающих целый город и предоставляющих пользователям доступ к приложениям независимо от устройств, на которых эти самые приложения запускаются. Но для мобильных устройств очень важна гибкость – при отсутствии сервера я должен иметь возможность самостоятельно легко устроить такой сервер из моего сотового телефона. Децентрализация удобнее.
Все это, насколько я понимаю, можно реализовать уже сейчас, например, с помощью .NET.
Но сначала придется решить массу проблем, вот их примерный список:
1. Создание единой инфраструктуры разработки приложений с отделенным ПИ. Модули с ПИ должны поддерживать максимальное количество способов взаимодействия: сенсорные экраны, мышь, клавиатура, программные клавиши, голосовой интерфейс и так далее. Необходимо соблюсти баланс между программной логикой и логикой пользовательского интерфейса.
2. Создание прозрачной дистрибуции всех частей программы: логической, интерфейсной, визуальной, с адаптацией под любое экранное разрешение. То есть, при каждом запуске приложения необходимо определять текущий контекст. Также прозрачной для пользователя должны быть система диагностики взаимодействия устройств и программ.
3. Создать новые правила лицензирования и оплаты использования программных продуктов.
4. Обеспечить безопасность выполнения таких сборных приложений на всех уровнях.
5. Обеспечить бесперебойную автоматическую маршрутизацию информационных потоков между устройствами и интернетом.
6. Создать гибкую систему энергопотребления устройств в случае, когда одно является сервером для другого (чтобы сервер неожиданно не заснул).
Но, в общем, все проблемы вполне решаемы уже сегодня. Остается следить за появлением описанных тенденций и ждать приложений нового типа.
