Особенности разработки для Зауруса

При разработке программ для Зауруса нужно принимать во внимание некоторые особые соображения: начиная от ограничений на размер исполняемой программы и кончая использованием папки Documents.

Особенности КПК

Когда пользователи смотрят на КПК, они думают о двух вещах. Первая — это приложения, которые они используют, второе — это их документы. Им безразлично какая версия Линукс установлена или на каких языках программирования написаны приложения. Пользователи должны иметь возможность делать все, что им нужно, без необходимости искать нужные файлы в файловой системе или запускать программы из консоли. Помните, что файловый менеджер не поставляется, например, с Sharp Zaurus 5500 и его наличие в системе не может быть гарантировано.

Пользователь не должен иметь возможности просматривать всю файловую систему. Нужный ему документ должен находиться в одном из трех мест: CF-карточке, SD-карточке или в папке Documents. (Сеть может считаться четвертым местом, но мы сейчас говорим о просмотре содержимого самого КПК. Если приложение может подключаться к сетевым ресурсам, оно попадает в другую категорию, однако и в этом случае должны применяться все те же правила, а именно, чтобы не было возможности просматривать все, что существует на данной машине.)

Если только приложение не расчитано специально на разработчиков или опытных пользователей, нет никакой причины для создания специального файлового диалога для просмотра всей системы. Приложение, позволяющее просматривать/изменять документы, должно использовать встроенные классы qpe для работы с документами. Приложения, которые нуждаются в том, чтобы пользователь указал папку, должны предоставлять базовые средства просмотра. Возможно, сначала представляя пользователям список из трех возможных мест расположения данных, а затем показывая списки каталогов. Но и в этом случае предоставление им возможности просматривать каталоги начиная с “/”, будет считаться ошибкой.

Размер (исполняемого кода и экрана)

При разработке под Заурус нужно принимать во внимание размер приложения и размер экрана.

Большинству пользователей, использующих Заурус для повседневных нужд, не нужны разнообразные “примочки” и “фичи”, обычные для “больших” приложений. Им нужно, чтобы была возможность выпонять основную работу, чтобы была одна страница справки для приложения, и ничего более. Множество вещей может быть безболезненно убрано из приложения для уменьшения размера его кода: шаблоны, примеры использования, возможности печати, импорта, экспорта, дополнительные настройки, темы, вещи, связанные с обратной совместимостью, “исторический” код, весь этот ненужный багаж. Каждое приложение отличается от других, поэтому для каждого конкретного приложения нужно рассматривать вопрос о том, что есть лишнее в нем, и что может быть удалено. Уборка в доме всегда полезна, и может оказаться, что сокращая сложность и размер приложения, мы можем сильно выиграть в скорости его работы.

Приложения на Заурусе не могут претендовать на роскошный экран 1024×768, скорее им придется работать с 240×320. Многие диалоги придется переработать, чтобы они не вылезали за пределы экрана.

Обратите внимание на окна сообщений, появляющиеся на экране, удостоверьтесь, что они целиком помещаются на экране. Выкидывание лишней функуциональности — один из превосходных путей для того, чтобы уместить ваше приложение на экране и уменьшить размер исполняемого кода. Диалоги настроек — одна из самых сложных вещей для переделки, так как обычно они занимают гораздо больше места, чем доступно на экране Зауруса. Также постарайтесь уместить само главное окно приложения на экране.

Потому что это Линукс

Многие приложения для Зауруса разрабатываются Линукс-программистами. К сожалению, среди них все чаще считается в нормальным, когда приложение наполовину сломано, или когда настроить его можно исключитально из командной строки. (Заметьте, я не говорю наполовину не закончено, а именно сломано) Так быть не должно. Пользователи КПК ожидают нормальной работоспособности от приложений больше других групп, даже больше, чем пользователи Маков. Когда выходят приложения для OSX, они имеют полностью вылизанный интерфейс пользователя. Даже такие, как Apache. Разрабатывая приложение для Зауруса, старайтесь поступать так же. Выпущенный в свет ipk должен работать сразу после установки. Он должен иметь GUI, который работает. А если программе не требуется GUI, она должна быть автоматически запущена после установки, и корректно остановлена при удалении из системы. Пользователи никогда даже не должны задумываться об использовании командной строки. Командная строка может быть мощным инструментом для разработчиков, или “крутой фишкой”, чтобы показать приятелю, как выглядит vi на КПК. Но ее использование и даже просто наличие не может быть в числе требований для работы приложения.

Добродетель Пользовательского Интерфейса

Разрабатывая приложение, пожалуйста, старайтесь придерживаться общих правил разработки интерфейса пользователя. Если вы нигде этого не проходили, я бы порекомендовал найти какую-нибудь книгу, посвященную этому вопросу, например, GUI Bloopers, сесть и прочитать ее. Если же у вас уже есть опыт разработки пользовательских интерфейсов, потратьте десять минут, чтобы критически рассмотреть ваше приложение, или даже найти кого-нибудь еще, кто вам поможет в этом. Результаты могут вас удивить.

Заключительное правило

(Игры являются едва ли не единственным классом приложений, которые могут нарушать это правило. Но и в этом случае сначала хорошенько подумайте.)

Если вы думаете добавить некоторые “особенности”, такие как:

  • Все мое приложение будет в розовых тонах!
  • Мне нравится эта тема из KDE3, поэтому я буду требовать ее установки (в конце концов, что такое 22 мегабайта?)
  • Доморощенные закладки, расположенные вверх ногами!
  • Я сделал свой собственный диалог выбора файлов, который совершенно не похож ни на какой другой!
  • Full screen должен быть всегда включен!
  • Каждое третье нажатие на кнопку Ok переворачивает экран (разумеется, случайным образом) и не делает того, что ожидает пользователь.
  • и т.п.

Перво-наперво, сядьте и минутку подумайте вот о чем. Скорее всего, от вас потребуются большие усилия чтобы создать такое, непохожее на другие, приложение. При этом вы не сделате ровным счетом ничего полезного. По большому счету, это возможно даже повредит приложению. При использовании Qt, если приложению требуется перегрузить класс чтобы реализовать в нем какие-то особые возможности, сперва подумайте, сколько времени это отнимет, и нужно ли вообще это делать. Если требуется много работы чтобы в каждом окне была нарисована радуга, возможно, на это не стоит тратить свои силы. Главное правило заключается в следующем: если вы хотите сделать что-то особенное, не делайте этого.

Контрольный список для ipk

Перед тем, как выпускать ipk, пройдитесь по этим спискам и проверьте, что ваше приложение соответствует им. Это списки полезных вещей, которые помогут вам улучшить приложение и сделать его более дружественным к пользователю.

  1. Пакет ipk правильно и без ошибок устанавливается во внутренний флеш, SD и CF
  2. После установки появляется только одна запись в списке установленных пакетов
  3. Пакет удаляется (uninstall) правильно и не оставляет за собой мусора
  4. Файл control, находящийся в ipk, содержит правильное название, категорию и т.п.
  5. Если в файле control имеется параметр “Section”, он имеет наилучшее значение для приложения (из admin, base, comm, editors, extras, graphics, libs, misc, net, text, web, x11 settings)
  6. Все, что нужно установить дополнительно (другие ipk) должно быть перечислено в файле control
  7. Пакет не должен создавать новую закладку на рабочем столе, если только закладка не является категорией (т.е. пользователи не должны думать на каком языке написано то или иное приложение, т.е. никаких закладок типа Jeod или Python быть не должно; однако закладка Multimedia может быть создана, если ее до этого не было). Если пользователь не может сказать, почему приложение находится на закладке, значит, эта закладка не нужна.
  8. Файл справки должен быть установлен, если приложение поддерживает вызов справки (кнопка с “?” в верхнем правом углу окна)
  9. GUI-приложения не должны устанавливать приложения командной строки, но должны указывать их в списке зависимостей (Графический интерфейс к fdisk’у, например, должен требовать установки пакета с fdisk).
  10. Типы MIME (Mimetypes) должны определяться и удаляться скриптами установки/удаления, если нужно.
  11. Бинарные файлы должны быть очищены (stripped) для уменьшения размера
  12. Приложения, не нуждающиеся в сосбой “скорострельности” (как большинство GUI), должны быть откомпилированы с опцией -Os (оптимизация размера) или -O2.
  13. Исходный код доступен для приложений, распространяемых под GPL или другой подобной лицензией.
  14. Если приложение распространяется под GPL или аналогичной лицензией, исходный код можно получить из Интернета (или, в крайнем случае, имеется имя/адрес электронной почты лица, у которого можно получить исходники)
  15. Все установочные скрипты написаны в UNIX-формате, а не в формате DOS.
  16. Приложение не должно содержать симлинки, чтобы его можно было установить на устройства с FAT.

Контрольный список для приложения

  1. Для того, чтобы запустить приложение, не требуется выполнения действий из командной строки (т.е. не нужно устанавливать страницы руководства (man pages), файлы readme и т.п.
  2. Если это приложение командной строки, предназначенное для пользователя, а не программиста, оно должно иметь графический фронтенд (пусть даже очень простое). Например: samba-клиент, простой веб-сервер, и т.п. (Т.е. пакет boa считается правильным, так как пакет серверного менеджера (server manager) является фронтендом для него.
  3. Приложение не позволяет пользователю просматривать файловую систему целиком (т.е., например, видеть содержимое каталога /usr/bin)
  4. Приложение не пытается создать собственных цветовых схем/тем (игры являются единственным исключением)
  5. Любой диалог, имеющий кнопку “OK” должен отменять сделанные в нем изменения при нажатии на “X” (кнопка “Cancel”)
  6. Приложения работают и на 5000D, и на 5500 (т.е. не требуют 30M памяти…)
  7. Для реализации меню используется QPEMenu, так что кнопка “меню” работает.

Перевод http://oesf.org/index.php?title=Special_Considerations и http://oesf.org/index.php?title=Checklist с OESF

Trackback