Руководство по параметрам приложений

Материал из AltecDocs

Перейти к:навигация, поиск

Настройка параметров системы

Диалоговое окно меню предоставляет доступ к разнообразным настройками приложения, включая вид элементов интерфейса, поведение при возникновении ошибок, а также различные другие аспекты работы с программой и её модулями.

Диалоговое окно вызывается из главного . В левой части окна располагается дерево, каждому узлу которого соответствуют настройки определённых параметров. При выборе узла этого дерева в правой части отображается представление: панель, с помощью элементов которой производится настройка необходимых параметров.

IconInfo.png Обратите внимание, что некоторые разделы изначально доступны только для администратора. Кроме того, администратор может скрыть некоторые узлы дерева настроек (см. Руководство по настройке: «Настройка прав доступа сотрудников»).
  • /Интерфейс
  • /Общие

Папка «Модули»

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

  • Параметры приложения/Asterisk
Заказы
Заказы конструкций

В подразделе выполняется настройка внешнего вида представления и заполнения некоторых полей при создании новых заказов конструкций (см. Конструкции#Окно заказа).

Рис. 1.75. Окно (представление )

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

В представлении производится настройка работы с дополнительными параметрами заказа.

Рис. 1.76. Окно (представление )

  • Производство
    •  — В программе ведется учёт заказов, которым был поставлено состояние . Для обнуления данного индекса можно воспользоваться этим флагом.
  • Дублирование заказов
    •  — переключатель, определяющий поведение при дублировании заказа. Если флаг активен, при дублировании заказа также будут скопированы и все вложения.
Импорт заказов

В представлении производится настройка поведения программы при импорте заказов.

  •  — статус, который присваивается заказу сразу же после его импорта в приложение; ссылка на элемент справочника .

Рис. 1.77. Окно (представление )

Пересылка

В представлении производится настройка электронной почты для отправления заказов конструкций (см. Построитель конструкций#Пересылка и получение заказов по почте).

Рис. 1.78. Окно (представление )

  • Параметры отправки заказов
    • Сервер исходящей почты
      •  — при отправке исходящих сообщений применяется шифрование по протоколу SSL.
  • Параметры приема заказов
    • Сервер входящей почты
      •  — при получении сообщений применяется шифрование по протоколу SSL, версия которого указывается в выпадающем списке.
    •  — флаговый переключатель, управляющий возможностью автоматического отслеживания доставки писем
    •  — периодичность, с которой будет производиться доставка/получение новых писем
    •  — флаговый переключатель, делающий возможным сохранение автоматически полученных заказов в базу данных.
    •  — папка, в которую будут перемещаться полученные заказы.
Формирование см. задания по трудоемкости

В представлении производится настройка автоматического создания сменных заданий при использовании мастера формирования сменных заданий;

Рис. 1.79. Окно (представление )

  •  — шаблон для автогенерации названия сменного задания.
  • .
  •  — максимальное время, после которого расчёт сменного задания будет остановлен.
  •  — флаг, управляющий возможностью распределения в сменные задания по отдельным изделиям изделиям.
Экспорт заказов

В представлении производится настройка параметров экспорта заказов.

Рис. 1.80. Окно (представление )

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

В представлении производится настройка параметров для экспорта стеклопакетов из заказов конструкций.

Рис. 1.81. Окно (представление )

  • Автогенерация наименований

При создании шаблонов наименований можно использовать теги, которые описаны в табл. 2.4 и табл. 2.5 (при этом тег index можно использовать для формирования наименования только стеклопакета). Помимо того могут использоваться специальные теги, их список можно получить, нажав кнопку BrowseButton.png.

  •  — выпадающий список, из которого необходимо выбрать значение, указывающее, каким образом будет проводиться экспорт:
    •  — все одинаковые экспортируемые стеклопакеты будут объединены в один (при этом общее количество одинаковых стеклопакетов будет указано в поле );
    •  — для описания свойств на каждый стеклопакет при экспорте будет выделяться отдельная строка (даже если свойства отдельных стеклопакетов будут совпадать);
    •  — отличается от тем, что если количество конструкций в заказе несколько, то одинаковые стеклопакеты из одинаковых конструкций объединяются.
  •  — флаг, позволяющий при экспорте выбрать артикулы, которые необходимо экспортировать.
  •  — флаг, отвечающий за то, что при экспорте стеклопакетов из представления или сменных заданий будет производиться объединение отдельных стеклопакетов из заказов конструкций в общий заказ стеклопакетов.
Заказы стеклопакетов

Содержание и назначение полей представлений:

  • ,
  • ,
  • ,
  • ,
  •  — полностью идентичны таковым, рассмотренным ранее для представлений подраздела (см. Параметры приложения#Заказы конструкций).
Экспорт элемента в DXF

В представлении настраиваются параметры экспорта элементов в формате DXF.

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

Рис. 1.82. Окно (представление /),

План работ

В представлении настраиваются параметры раздела (см. План работ).

Рис. 1.83. Окно (представление )

    •  — цвет
  •  — принудительно завершать процесс распределения по истечении отведённого времени.
    •  — время, по истечении которого процесс распределения сменных заданий будет прерван.
Предварительные расчёты

В представлении производятся настройки механизма предварительных расчётов (см. Предварительные расчёты).

Рис. 1.84. Окно (представление )

  • Автогенерация наименований
    •  — шаблон для автогенерации названия предварительного расчёта;
    •  — шаблон для автогенерации названия элемента предварительного расчёта;
    •  — шаблон для автогенерации названия варианта калькуляции предварительного расчёта;
  •  — ссылка на элемент справочника «Валюты».
  •  — ссылка на элемент справочника «Продавцы».
Проекты

В представлении настраивается поведение приложения при работе с подразделом проектов (см. Проекты).

Рис. 1.85. Окно (представление )

    • —
    • — наименование валюты проекта по умолчанию
    • — наименование валюты проекта по умолчанию, которое устанавливается глобально только под учётной записью администратора и применяется, если значение поля выше не было задано пользователем.
    • — шаблон для автогенерации названия проекта.
    • —
    • — шаблон для автогенерации названия элемента.
    • —
    • — папка в дереве заказов, куда будет производиться сохранение заказов, формируемых в рамках проектов.
    •  — управляет отображением нижней сноски таблицы представления ;
    •  — в дереве проектов показывает узлы состояний проектов, на которые у текущего пользователя есть права.
Расчёт

В представлении производится настройка различных опций расчёта.

  •  — управляет возможностью автоматического прерывания расчёта при нехватке материалов.

В группе производится настройка отображения отладочных сообщений.

При расчёте конструкций (заказов) можно получать определенную информацию о работе программы. Эта информация выводится через окно отладочных сообщений и может говорить, например, об ошибках, совершенных администратором при настройке. Содержание самих сообщений определяется администратором.

Рис. 1.86. Окно (представление )

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

В группе производится настройка протоколирования процесса расчёта.

  • .
Представление

В представлении определяется, какие именно элементы статики следует проверять при расчёте статических нагрузок (см. Руководство по настройке altAwin:Раздел «Статика»).

Рис. 1.87. Окно Параметры (представление Расчёт / Статика)

  • Опции расчёта
  •  — флаг, включающий отображение отдельного окна и вывод отладочных сообщений в процессе расчёта.
  • Весовая статика
  • Ветровая статика
Расчёты конструкций

В представлении «Расчёты конструкций» настраивается поведение приложения при работе с подразделом проектов (см.Шаблон:Расчёты конструкций).

  • Автогенерация наименований
    •  — шаблон для автогенерации названия расчёта конструкций;
    •  — шаблон для автогенерации названия элемента расчёта конструкций;
  •  — ссылка на элемент справочника «Валюты».
  •  — ссылка на элемент справочника «Продавцы».
    •  — в дереве расчётов конструкций показывает узлы состояний расчётов конструкций, на которые у текущего пользователя есть права.
См. задания конструкций
  • Автогенерация наименований
    •  — шаблон для автогенерации названия сменного задания конструкций;

Рис. 1.88. Окно (представление )

Автосоздание

В представлении производится настройка параметров автоматического создания сменных заданий.

Рис. 1.89. Окно (представление )

  •  — флаговый переключатель, управляющий добавлением в сменные задания дополнений к конструкциям при автосоздании сменных заданий (см. Сменные задания конструкций#Автоматическое создание и добавление сменного задания конструкций)
  •  — флаговый переключатель, управляющий добавлением в сменные задания дополнений к заказам конструкций.
По умолчанию

В представлении производится настройка параметров оптимизации конструкций по умолчанию (см. Сменные задания конструкций#Окно сменного задания конструкций);

Рис. 1.90. Окно (представление )

Если в представлении установлен флаговый переключатель , то при создании документа сменного задания поле будет обязательным для заполнения.

Экспорт стеклопакетов

В представлении производится настройка параметров для экспорта стеклопакетов из сменного задания, все настройки идентичны экспорту стеклопакетов из конструкции (см. рис. 1.81);

См. задания стеклопакетов

В подразделе производится настройка параметров приложения, имющих отношение к работе со сменными заданиями стеклопакетов (см. Сменные задания стеклопакетов).

Содержание и назначение полей представлений:

  • ,
  • ,
  •  — идентичны таковым, рассмотренным ранее для представлений подраздела (см. Параметры приложения#См. задания конструкций).
Шаблоны

В подразделе производится настройка параметров, имеющих отношения к работе с шаблонами конструкций.

Экспорт шаблонов

В представлении производится настройка шаблона автоименования файла при экспорте шаблонов конструкций.

Контрагенты
Задачи

В подразделе задаются настройки, относящиеся к механизму формирования персональных задач для контрагентов.

Рис. 1.93. Окно (представление )

  • Календарь
    •  — время начало рабочего дня для отображения в представлении
    •  — время начало рабочего дня для отображения в представлении (см. Календарь).
Склад

В подразделе производится настройка параметров приложения, связанных с отображением элементов в в таблицах подразделов , и (см. Раздел «Склад»).

Рис. 1.97. Окно (представление )

  • Цвета в представлении «Склад»
  • Цвета накладных
Склад продукции

В подразделе настраиваются правила заполнение некоторых полей окон приходной и расходной накладных для склада готовой продукции, а также производится настройка интерфейса для управления перемещением продукции между складами (см. Раздел «Склад продукции»).

Рис. 1.98. Окно (представление )

  • Автогенерация наименований
  • Перемещение продукции между складами

При заведении шаблона можно использовать теги, применяющиеся для формирования наименования заказа и изделия (см. табл. 2.4 — 2.5), а также дополнительно тег . Посредством этого тега в поле заносится наименование склада, для которого создается накладная.

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

Автоформирование приходов

В подразделе определяются параметры автоматического формирования приходных накладных на склад готовой продукции (см. Приходы продукции).

Рис. 1.99. Окно (представление )

  • Дополнения — флаговые переключатели, управляющие формированием приходов на склад готовой продукции для материалов и наборов.
  •  — поле, позволяющее для каждого типа элементов определить правила именования приходной накладной.
    •  — при переходе заказа в указанное состояние (см. Состояния заказа) будет автоматически выполняться формирование прихода продукции по этому заказу.
    •  — при переходе заказа в указанное состояние будет автоматически выполняться удаление прихода продукции по этому заказу.
План доставки

В подразделе определяются настройки планирования доставки готовой продукции (см. План доставки)

  •  — элемент справочника «Этапы заказа» (см. Руководство по настройке: «Этапы заказа») для использования при формировании плана доставки.
Код офиса
  •  — код офиса на основном месте используется для экспорта настроек в дилерские рабочие места. Код офиса должен соответствовать коду персонализатора, осуществляющего выдачу лицензии пользователю дилерской версии altAwin.
Источник

Перейти к содержанию

На чтение 8 мин. Просмотров 276 Опубликовано 12.04.2021

Каждый раз, когда вы ищете руководство для корневого каталога для устройства Android, вам всегда предлагается разблокировать скрытые параметры разработчика, а затем включить отладку по USB и/или OEM-разблокировку. А как насчет остальных вариантов? В меню настроек Android нет четкого объяснения их – это то, к чему я хочу обратиться сегодня. Это будет исчерпывающий обзор всех настроек в меню «Параметры разработчика», с точки зрения непрофессионала, и того, как они могут улучшить или сломать ваш телефон.

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

Содержание

  1. Основные параметры
  2. Параметры отладки
  3. Параметры сети
  4. Параметры мультимедиа

Основные параметры

  • Получить отчет об ошибке: нажатие этой кнопки захватит текущие файлы журнала на вашем устройстве и упакует их для отправки указанному вами получателю, например по адресу электронной почты.
  • Пароль резервной копии рабочего стола: это принудительно вводит пароль для любых резервных копий, которые вы создаете с помощью ADB. Без пароля эти резервные копии не могут быть восстановлены на вашем телефоне.
  • Не спать: это заставит ваш экран всегда бодрствовать во время зарядки, что отлично подходит для сокращение срока службы экрана и запись изображений на него.
  • OEM-разблокировка – Это позволит разблокировать загрузчик, но это не так это так же просто, как щелкнуть этим переключателем, если ваш оператор или производитель заблокировал загрузку вашего устройства. Но обычно это первый шаг в правильном направлении.
  • Включить журнал отслеживания Bluetooth HCI: Это предназначено для разработчиков и специалистов по безопасности, которым требуется для анализа пакетов Bluetooth HCI ( H ost C ontroller I nterface). Журнал будет найден в каталоге, например (/sdcard/btsnoop_hci.log) для извлечения и проверки.
  • Выберите конфигурацию USB: этот вариант, кажется, предлагает способ установки режима USB «по умолчанию», но он заменен стандартным параметром USB в меню настроек. Здесь есть один вариант, который может сбивать с толку, под названием «Источник звука». Некоторые люди задаются вопросом, превратит ли это ваше устройство Android в источник звука для вашего компьютера. На самом деле настройка «Конфигурация USB: источник звука» позволяет вашему телефону обмениваться данными через USB с периферийными аудиоустройствами USB, такими как USB-ЦАП. Это не для маршрутизации звука с Android на компьютер через USB.

Параметры отладки

  • Отладка USB: в основном это позволяет вашему устройству Android связываться с USB-портами вашего ПК через Android Debug Bridge.. Это дополнительная функция USB-связи – конечно, ваше устройство всегда будет распознаваться как запоминающее устройство или любой другой режим USB, который вы включили на своем устройстве, но без включенной отладки USB вы не можете отправлять команды ADB на Android со своего компьютера.
  • Отменить авторизацию отладки USB: Это отменит все пары ключей на вашем устройстве, которые соответствуют устройству Android компьютеру/компьютерам, используемым для отладки ADB. По сути, это похоже на удаление пароля Wi-Fi.
  • Отчеты об ошибках в меню питания: это позволит выбрать в меню питания параметр для сбора и отправки отчета об ошибке.
  • Разрешить фиктивные местоположения: этот параметр позволяет вам установить фиктивное местоположение для вашего устройства, что может обмануть большинство приложений, использующих сбор местоположения – однако это не надежно, например, некоторые приложения, такие как Google Play, могут получить ваше приблизительное местоположение в зависимости от вашего оператора связи, если вы используете мобильные данные без VPN.
  • Выберите приложение фиктивного местоположения: У вас может быть этот параметр вместо «Разрешить фиктивные местоположения», и в основном он будет предлагать вам выбрать стороннее приложение 3 rd , установленное на вашем телефоне, для отображения фиктивных местоположений для запросов местоположения из apps.
  • Выбрать приложение отладки: С точки зрения непрофессионала, это позволяет вам выбрать приложение для отладки и предназначено для разработчиков приложений инструментов, чтобы убедиться, что их приложение работает нормально на Android. i>
  • Подождать отладчика: этот параметр становится доступным после того, как вы выбрали приложение для отладки с помощью предыдущего параметра – это предотвратит запуск приложения, пока не будет подключен отладчик. .
  • Проверять приложения через USB: это позволит Google сканировать приложения, которые вы устанавливаете через ADB, на предмет вредоносного поведения. Это хорошо, если вы загружаете файлы .APK со своего компьютера на устройство Android.
  • Показывать штрихи: Не требует пояснений, но буквально просто показывает у вас визуальный индикатор, где экран нажат. Подходит для диагностики неисправного сенсорного экрана.
  • Местоположение указателя: этот параметр помещает информационную панель в верхней части экрана с указанием экранных координат последнего места касался экрана.
  • Показать обновления поверхности: заставляет мигать край окна приложения при обновлении его содержимого.
  • Показать границы макета: это пометит все края макета, чтобы показать вам, где регистрируются касания – например, если на вашем экране есть невидимый виджет, это выделит его.
  • Принудительное направление макета RTL: Принудительная ориентация экрана для поддержки языков справа налево.
  • Масштаб анимации окна: Устанавливает скорость воспроизведения анимации окна. Меньшее число быстрее. Некоторые модели с «дисплеем» устанавливают опцию, наряду с той, что ниже, на очень низком уровне в магазинах сотовых телефонов, чтобы телефоны выглядели очень быстро и быстро.
  • Масштаб анимации перехода: устанавливает скорость воспроизведения анимации перехода. Опять же, чем ниже, тем быстрее.
  • Имитировать вторичные дисплеи: этот параметр позволяет разработчикам имитировать экран разных размеров. Это немного ошибочно.
  • Принудительный рендеринг с помощью графического процессора: заставляет приложения использовать аппаратный 2D-рендеринг, если они были написаны так, чтобы не использовать его по умолчанию. Это может быть как хорошо, так и плохо, в зависимости от приложения.
  • Показывать обновления представлений графического процессора: с этим параметром любое представление, созданное с помощью графического процессора оборудование получает красный оверлей.
  • Показывать обновления аппаратного уровня: этот параметр сообщит вам, когда уровни обновляются в представлениях приложений с аппаратной поддержкой.
  • Отладка перерисовки графического процессора: перерисовка происходит каждый раз, когда приложение просит систему нарисовать что-то поверх чего-то другого. Этот параметр позволяет увидеть, когда и где это происходит, чтобы вы знали, является ли это проблемой.
  • Force 4x MSAA: Это вызовет 4-кратное сглаживание мультисэмплинга , который сгладит «неровности» на трехмерной графике, но снизит общую производительность.
  • Включен строгий режим: этот параметр мигает на экране, когда приложение использует основной поток для выполнения длительных и интенсивных операций.
  • Показать использование ЦП: это просто помещает крошечное окно в правом верхнем углу экрана с информацией о ЦП и о том, как он используется.
  • Профиль графического рендеринга: этот параметр может рисовать график на экране или записывать его в файл. График представляет собой визуальную визуализацию того, насколько тяжело работает графический процессор. Это еще один полезный вариант.
  • Включить трассировку OpenGL: этот параметр отслеживает ошибки OpenGL и помещает их в файл журнала, который вы выбрали при запуске. это вверх. Ничего такого, к чему большинству пользователей когда-либо понадобится прикоснуться.
  • Не сохранять действия: это буквально уничтожит любую активность, как только вы выйдете из главного окна, заставляя все, что связано с этим приложением, закрыть. Это не хорошо и сократит общее время работы от батареи. Это почти та же самая причина, по которой «очистители оперативной памяти» и приложения, принудительно закрывающие фоновые службы, в конечном итоге плохи. Вашему телефону придется усерднее работать, чтобы открыть эти приложения в следующий раз, когда вы их запустите.
  • Ограничение фоновых процессов: позволяет настраивать количество процессов, которые могут выполняться в фон сразу. Вам действительно не следует играть с этим, просто оставьте его по умолчанию.
  • Показать все ANR: этот параметр заставляет каждый процесс отображать «Приложение не отвечает» диалог, если он зависает – даже фоновые процессы, которые пользователь не запускал. Полезно, если одно приложение мешает другому.

Параметры сети

  • Агрессивное переключение Wi_Fi на сотовую связь: Если этот параметр включен, ваше устройство будет намного быстрее подключать мобильную передачу данных при обнаружении слабого сигнала Wi-Fi.
  • Всегда разрешать сканирование роуминга Wi_Fi: Включение этого параметра укажет вашему устройству всегда сканировать открытые сети Wi-Fi, даже когда ваше устройство «спит». Это полезно, если вы едете по улице, полной открытых подключений Wi-Fi, загружаете музыкальные файлы и хотите, чтобы ваше устройство переключалось между подключениями Wi-Fi.
  • Сотовые данные всегда активен: он делает именно то, что он говорит, он сохраняет мобильные данные всегда включенными, даже если вы включили Wi-Fi. Лучше всего сочетать его с опцией «Агрессивный переход wi_fi на сотовую связь».

Параметры мультимедиа

  • Отключить маршрутизацию аудио USB: включение этого параметра отключит автоматическую маршрутизацию на периферийные аудиоустройства USB, такие как USB DAC.

Источник

Во время разработки приложений необходимо учитывать интересы сразу нескольких групп участников: заказчики (бизнес), проектировщики, тестировщики, разработчики и дизайнеры. Однако документация обычно готовится только для заказчиков, а про разработчиков и тестировщиков почему-то постоянно забывают. В нашей первой статье мы расскажем о том, как можно самостоятельно подготовить необходимый комплект документации, утереть нос проектировщикам и получить документацию, которая будет соответствовать коду, а не абстрактным бизнес-фичам.

Это серия статей «Must-have документация для мобильного разработчика»: Часть 1 и Часть 2.

Передаю слово Вячеславу Черникову.

В первой части мы расскажем о том, почему важно уделять внимание техническому проектированию и опишем необходимый минимум документации, которая позволит создать «скелет» проекта на основе пользовательского интерфейса.

Данная статья является сокращенной версией руководства, доступного по ссылке в конце статьи.

Первичная документация

Ключевую идею, с которой мы начнем, можно коротко сформулировать следующим образом:

Мобильные бизнес-приложение — это в первую очередь пользовательский интерфейс для взаимодействия с внешним сервисом.

При разработке технической документации на проект это стоит обязательно учитывать, так как интерфейс нагляден и на его основе проще проводить разделение проекта на разделы. Да и сама модель предметной области очень хорошо описывается интерфейсом — в ней необходимо учитывать в основном те данные (и их производные), которые вводятся пользователем, отображаются на экране и управляют его поведением. Бизнес-сценарии также напрямую завязаны на поведение пользовательского интерфейса.

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

В следующих главах мы опишем минимально необходимый набор документов, которые позволят команде использовать простые чек-листы для контроля реализации.

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

Итак, у проекта обычно выделяют следующие производственные классы задач:

  • анализ;
  • проектирование и дизайн;
  • кодирование;
  • тестирование;
  • эксплуатация.

Можно выделить и больше, но они по факту будут являться производными от обозначенных.

На этапе аналитики производится поиск решения, описание общих требований к приложению. На выходе с этапа аналитики появляются спецификации, которые являются вводными для этапа проектирования.

Так как наше руководство предназначено в первую очередь для разработчиков, то считаем, что бриф или базовое ТЗ у вас есть.

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

На этапе проектирования самым важным является продумывание пользовательского интерфейса и создание схем экранов.

Если начинать сразу с дизайна (вместо схем экранов), то придется постоянно переделывать его (дизайн) для согласования с заказчиком. На этапе проектирования это сильно замедлит процесс. Дизайн фактически является производным от UX и наполняет изначальные схемы эмоциями, выправляет композицию, добавляет анимации и другие аспекты внешнего вида и визуального поведения. Схемы экранов, в свою очередь, создают структуру приложения и моделей данных — какие данные отображать, как они будут сгруппированы, как они будут влиять на поведение интерфейса.

На выходе с этапа проектирования будет получен комплект необходимых спецификаций и ресурсов, которые вместе с ТЗ уйдут разработчику. Этап кодирования разумно начинать с построения фундамента – базовой структуры проекта, в чем нам очень поможет понимание ключевых пользовательских сценариев.

Экраны, данные и логика

Напомним еще раз, что мобильные приложения это в первую очередь пользовательский интерфейс, поэтому и проектирование лучше начать со схем экранов и последовательности переходов между ними. Это необходимо для того, чтобы определить набор шагов, которые предстоит пройти пользователю для получения желаемого результата. Ведь бизнес-приложение создается для определенного набора ключевых сценариев (последовательности действий пользователя), с помощью которых человек может решить свои задачи.

Так как среднее время контакта человека со смартфоном составляет всего несколько минут, то количество шагов в бизнес-приложениях не должно быть большим — для пользователя в первую очередь важно получить результат (выполнить задачу или удовлетворить потребность) за время контакта с устройством. Для сложных приложений с большим количеством функциональных возможностей следует учитывать этот фактор. Хорошим выбором станет разделение приложения на относительно короткие сценарии не более 10 шагов каждый.

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

Группировка экранов и сквозное именование

Итак, у нас на руках есть схемы экранов от проектировщиков/дизайнеров и последовательность переходов между ними.

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

Первым делом необходимо выделить экраны, которые связаны между собой, обычно они должны идти друг за другом в пользовательских сценариях. Например, часто в приложениях можно выделить раздел Account с просмотром и редактированием всей информации, связанной с профилем пользователя.

Если вы опытный программист, то легко справитесь с разделением списка экранов на связанные разделы. В любом случае, потребуется немного практики.

Итак, у нас могут получиться следующие разделы:

  1. Account
  2. Help
  3. Checkout
  4. Catalog

Каждый раздел должен иметь название и номер. Названия разделов следует использовать для горизонтального разделения слоя работы с данными, бизнес-логики и пользовательского интерфейса. Это позволит в дальнейшем проще развивать проект.

Например, слой работы с данными (группы методов для различных серверных API) в этом случае разделится на разделы (репозитории, если вам так привычнее), каждый из которых будет обслуживать свой набор экранов:

DALDataServices (Repositories)

AccountDataService.cs (или AccountRepository.cs)

HelpDataService.cs

CheckoutDataService.cs

CatalogDataService.cs

В дальнейшем каждый из репозиториев может полностью скрывать всю работу с сервером, дисковым кешем и локальной СУБД. Это позволит на уровне бизнес-логики работать с репозиториями как с черными ящиками.

Дальше предстоит пронумеровать и назвать экраны (страницы, окна). На выходе у нас получится древовидная (хотя и плоская) структура интерфейса без учета последовательности переходов между экранами и их вложенности.

Имена экранов будут использоваться у нас в названиях классов для соответствующих страниц (Page) и ViewModel (или Controller для MVС):

1.1 Profile

ProfilePage

ProfileViewModel

1.2 EmailLogin

EmailLoginPage

EmailLoginViewModel

В первую очередь это важно для разработчиков, которые фактически получают готовую структуру проекта:

  • Слой доступа к данным разбивается на разделы приложения — создаем структуру Data Access Layer (DAL)
  • Добавляем нужные Pages и ViewModels — это создает структуру слоев работы с пользовательским интерфейсом (UI) и бизнес-логикой (BL).

Как видим, уже вырисовывается скелет проект. Слой DAL можно легко выделить в отдельную библиотеку. Если же у вас используется типовая архитектура или шаблон проекта (Base-классы, NavigationService, и т.д.), то считайте, что костяк приложения у вас уже имеется.

Пример структуры проекта представлен ниже.

UI (User Interface, пользовательский интерфейс)

    Pages

        Account

            ProfilePage.xaml

            …

BL (Business Logic, бизнес-логика)

    ViewModels

        Account

            ProfileViewModel.cs

            …

DAL (Data Access Layer, доступ к данным)

    DataObjects (Models)

        ProfileObject.cs (ProfileModel.cs)

        ProductObject.cs

        …

    DataServices (Repositories)

        AccountDataService.cs

        …

Для того, чтобы дальше реализовывать поведение экранов, нам потребуется дополнительная информация, поэтому продолжим знакомство с необходимыми артефактами.

Таблица экранов

После того, как у нас есть схемы экранов, мы также можем провести их анализ до фактического старта разработки. Следующим полезным артефактом для нас станет таблица экранов, оперировать которой будут не только разработчики, но и тестировщики. В сводной таблице легко собрать воедино всю текстовую информацию. Ключевыми столбцами таблицы для нас станут:

1. Номер экрана

2. Краткое название (Name)

3. Список возможных состояний (States)

4. Поля ввода для валидации (Validation)

5. Описание экрана и его поведения (Behavior)

Как видим, в представленном наборе полей собрана та информация, которая позволит корректно проверить работу каждого экрана в отдельности. Можно также каждому разделу присвоить свой цвет — это упростит работу с картой переходов и состояний.

Дополнительно, в эту таблицу могут быть добавлены следующие столбцы:

6. Список всплывающих уведомлений (alerts, sheets, dialogs)

7. Идентификаторы UI-контролов (например, LoginButton) для написания автоматизированных UI-тестов

8. Используемые модели (Models/Data Objects) данных

9. Используемые на каждом экране методы DAL

10. Используемые стили (Styles)

О каждом экране по столбцам достаточно просто вписывать короткие обозначения, которые в дальнейшем будут использоваться в программном коде и понятны в первую очередь разработчикам. Кроме столбца Behaviour (Описание экрана и его поведение), здесь ограничений лучше не делать.

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

  • отображать индикатор прогресса загрузки;
  • отображать загруженные данные;
  • отображать сообщение об отсутствии интернет-соединения;
  • отображать сообщение об ошибке (недоступен сервер, ошибки сервера);
  • отображать заглушку, если сервер вернул пустые данные (например, пустой список).

Хорошей практикой считается, если каждый экран, загружающий данные из сети (или из локальной СУБД) будет корректно отображать пользователю каждое из описанных состояний. Фактически, отдельное состояние описывается своим набором визуальных элементов (тексты, картинки, кнопки, другие элементы), и на уровне программного кода легко управлять переключением из одного состояния в другое. Также можно фиксировать негативные сценарии (ошибка загрузки, пустые данные) для дальнейшего анализа и устранения на стороне сервера или приложения.

Можно взять за правило и на всех экранах, загружающих данные, добавлять переключение состояний. Это упростит взаимодействие пользователя с приложением. Можно также использовать различные анимации или графику в негативных состояниях (ошибки, пустые данные), чтобы сгладить эффект.

Итак, у нас уже есть схемы экранов, список Page и ViewModel, а также детальная информация по каждому экрану. Каркас приложения можно построить, однако сейчас у нас экраны описаны независимо друг от друга и нет четкой и понятной последовательности переходов. Поэтому следующим полезным артефактом для нас станет карта переходов и состояний.

Карта переходов и состояний

Для того, чтобы лучше понять основные пользовательские сценарии, а также обозначить связи между экранами, можно использовать карту переходов и состояний. Плюсами карты являются ее компактность и наглядность. Даже для больших проектов карту переходов можно распечатать на принтере А4 и повесить над рабочим столом.

Итак, карта переходов начинается с точки старта – момента запуска приложения пользователем. Точек старта может быть несколько, например, один вариант запуска для авторизованного пользователя, второй – для неавторизованного, а третий – из Push-уведомления.

Дальше добавляются прямоугольники для каждого экрана и обозначаются стрелками последовательности переходов. Можно добавить идентификаторы (AutomationId) кнопок или событий, из-за которых произошел переход, и для наглядности еще указать данные, которые будут передаваться на новый экран.

Также у нас уже есть таблица экранов (предыдущая глава), где обозначены возможные состояния каждого из них и которые необходимо отобразить на карте переходов. Это позволит лучше понять возможные прерывания пользовательских сценариев, например, в случае ошибок или пустых данных. Если состояние прерывает (человек не может идти дальше) пользовательский сценарий, то обозначаем его минусом «-», если не прерывает, то плюсом «+». Стрелочки «назад» можно не добавлять.

Как видим, теперь у нас имеется практически вся необходимая для разработки информация в компактном виде. Эти три онлайн-документа (список экранов, таблица экранов, карта переходов) могут обновляться по мере развития проекта.

Для создания описанных выше артефактов нам будет достаточно 3 онлайн-инструментов:

  • текстовый редактор (Word Online)
  • табличный редактор (Excel Online)
  • графический редактор (Draw.io, Visio Online)

На подготовку каждого из артефактов уходит не больше одного дня, зато в дальнейшем это очень сильно упрощает процесс разработки, тестирования и развития продукта. За время медитативной подготовки документов и схем команда глубже понимает проект целиком и может уже финально оценить сложность и длительность его разработки (цифры для внутреннего использования).

Продолжение следует обязательно прочитать…

Полную версию руководства вы можете найти на Medium «Техническое проектирование мобильных приложений». Пообщаться напрямую с автором и сообществом Xamarin-разработчиков можно в нашем уютном чатике в Telegram.

Во второй части мы расскажем о том, как работать со стилями, фоновой функциональностью и пользовательскими сценариями. Оставайтесь на связи и задавайте свои вопросы в комментариях!

Об авторе

Вячеслав Черников — руководитель отдела разработки компании Binwell, Microsoft MVP и Xamarin Certified Developer. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone. Статьи Вячеслава вы также можете прочитать в блоге на Medium.

Другие статьи автора вы можете найти в нашей колонке #xamarincolumn.

Источник

Значения свойств приложения могут быть заданы в базе данных, в файлах свойств, через системные свойства Java или переменные окружения ОС. Если свойство с некоторым именем задано в нескольких источниках, его значение определяется в следующем приоритете:

  1. Системное свойство Java (высший приоритет)

  2. Переменная окружения ОС

  3. Файл свойств

  4. База данных (низший приоритет)

Например, значение, заданное в файле, переопределяет одноименное значение, заданное в БД.

Для переменных окружения ОС фреймворк пытается сначала найти точное соответствие по имени свойства, и если такой переменной нет, то ищется переменная с именем в верхнем регистре и с подчеркиваниями вместо точек. Например, переменная окружения MYAPP_SOMEPROPERTY может задать значение свойству myapp.someProperty. Для того, чтобы запретить возможность использования имен в верхнем регистре с подчеркиваниями, установите свойство приложения cuba.disableUppercaseEnvironmentProperties в true.

Некоторые свойства не поддерживают установку свойств в базе данных по причине того, что их значения требуются еще до того, как БД становится доступной приложению. Это параметры конфигурации и развертывания. Поэтому их можно устанавливать только в файлах свойств, через системные свойства Java или переменные окружения ОС. Параметры времени выполнения всегда могут быть установлены в базе данных (и, возможно, переопределены в файле или системными свойствами).

Как правило, некоторое свойство используется только в одном или нескольких блоках приложения. Например, cuba.persistenceConfig необходимо только для Middleware, cuba.web.appWindowMode − только для Web Client, а cuba.springContextConfig − для всех блоков. Это означает, что если нужно задать значение некоторому свойству, это необходимо сделать во всех блоках, в которых данное свойство используется. Свойства, хранящиеся в БД, доступны всем блокам, поэтому они устанавливаются в одном месте (в таблице базы данных), независимо от того, в каких блоках они используются. Более того, платформа предоставляет экран Administration > Application Properties для управления свойствами, хранящимися в БД. Свойства, хранящиеся в файлах, должны быть установлены одновременно в соответствующих файлах блоков приложения.

Когда вам необходимо установить значение свойству приложения, определенному платформой, найдите это свойство в документации. Если в документации сказано, что свойство хранится в БД, для установки значения используйте экран Administration > Application Properties. В противном случае выясните в документации, какие блоки приложения используют свойство, и установите значение в файлах app.properties этих блоков. Например, если в документации сказано, что свойство используется во всех блоках, а ваше приложение состоит из Middleware и Web Client, установите свойство в файле app.properties модуля core и в файле web-app.properties модуля web. Параметры развертывания можно также установить вне проекта в файле local.app.properties. Подробнее см. Хранение свойств в файлах.

Источник

1. Требования к аппаратуре и программному обеспечению

Для устройств на базе ОС Android:

  • Android — версия 2.3 и старше;
  • оперативная память — не менее 256 Мб для работы приложения;
  • на базе процессоров Intel x86 и ARM с архитектурой ARMv5TE и выше;
  • сенсорный экран.

2. Установка, обновление, удаление мобильного приложения

Установка мобильного приложения выполняется из магазина приложений Google Play (https://play.google.com/store).

Обновление мобильного приложения выполняется средствами магазина приложений.

Для удаления мобильного приложения необходимо на мобильном устройстве запустить приложение Google Play и в нем удалить мобильное приложение.

3. Запуск мобильного приложения

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

4. Работа со списком приложений

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

Для того чтобы изменить порядок приложений в списке, следует:

  • нажать кнопку Упорядочить — в правой части каждой строки отобразится кнопка перетаскивания.
  • нажать кнопку в строке приложения, которое нужно переместить и перетащить ее на требуемое место.

4.1. Создание приложения

Для того чтобы создать приложение для мобильной платформы, следует:

  1. Выбрать команду добавления приложения.
  2. Указать имя приложения и нажать кнопку Готово.
  3. После закрытия окна будет создано приложение.

4.2. Запуск приложения

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

4.3. Изменение свойств приложения

Свойства приложения изменяются в специальном окне. Для открытия окна свойств приложения следует выполнить длинное нажатие на нужном приложении. В открывшемся контекстном меню выбрать команду Изменить.

В открывшемся окне можно изменить наименование приложения, запустить его (кнопка Открыть) или удалить (кнопка Удалить).

После удаления приложения данные информационной базы восстановить невозможно.

4.4. Удаление приложения

Для удаления приложения следует выбрать команду Удалить и подтвердить свое действие: выполнить длинное нажатие на удаляемом приложении. В открывшемся контекстном меню выбрать команду Удалить.

После удаления приложения данные информационной базы восстановить невозможно.

4.5. Обновление приложения

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

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

Также имеет смысл отказаться от обновления, чтобы сделать резервную копию базы данных.

5. Интерфейс системы

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

6. Работа с формами

Прокручиваться может как форма, так и элемент формы. При прокрутке таких форм существует следующая особенность:

  • если прокрутка началась внутри элемента и ему есть куда прокручиваться в момент начала действия, то прокрутка будет осуществляться для элемента;
  • в противном случае прокручиваться будет вся форма.

Полосы прокрутки на мобильных устройствах не отображаются постоянно, поэтому можно не обратить внимания на то, что форма (отчет или таблица) показывает только фрагмент информации.

Практически в каждой форме есть команды, выполняющие определенные действия в форме. Часто используемые команды представлены в виде кнопок или гиперссылок на самой форме. Редко используемые команды доступны через специальное меню Все действия, доступ к которому осуществляется с помощью кнопки ≡.

Команды открытия вспомогательных форм реализованы с помощью специального меню, которое открывается с помощью нажатия на заголовок окна, если заголовок выделен подчеркиванием.

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

7. Ввод текста

Для ввода различной информации предназначена экранная клавиатура. Для ее активации, как правило, достаточно нажать на поле ввода, куда требуется ввести информацию. Кнопка Готово (Далее, Ввод и т. д.) приводит к переходу между полями ввода без закрытия клавиатуры.

8. Работа с файлами мультимедиа

В мобильном приложении может быть предусмотрена работа с мультимедийными возможностями устройства: создание аудиозаписи, использование встроенной камеры (для фото- и видеосъемки).

Запись аудио. Нажать кнопку диктофона в центре нижней части экрана. Чтобы остановить запись, повторно нажать кнопку диктофона. Чтобы отменить запись, нажать клавишу Назад.

Сохраненная аудиозапись будет обработана мобильным приложением.

Запись видео. Нажать кнопку записи видео в центре нижней части экрана. Чтобы остановить запись, повторно нажать кнопку записи. Чтобы отменить запись, нажать клавишу Назад.

Сохраненная видеозапись будет обработана мобильным приложением.

Съемка фотографии. Нажать кнопку фотокамеры. Для отмены съемки нажать клавишу Назад.

Сохраненный фотоснимок будет обработан мобильным приложением.

9. Местоположение на карте

В мобильном приложении может быть предусмотрена возможность работы с картографическим сервисом Google Maps (отображение адреса). В настройках телефона должна быть включена служба геопозиционирования.

Установка Google Maps в виде отдельного приложения не требуется.

10. Сообщения пользователю

Сообщения пользователю отображаются в специальной панели. Эта панель отображается на экране только в тот момент, когда в ней есть сообщения. Если панель закрывается, то список сообщений очищается. Нажатие на сообщение приводит к активации элемента формы, если сообщение связано с таковым. Для повторного открытия списка сообщений следует повторно вызвать действие, приводящее к открытию списка.

11. Резервное копирование

Резервное копирование данных выполняется в зависимости от используемого мобильного приложения.

Если используется мобильное приложение, не связанное с удаленной системой, то для резервного копирования можно воспользоваться штатными средствами используемой операционной системы мобильного устройства.

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

На устройствах под управлением iOS при создании приложения папка с данными приложения помечается как нерезервируемая. После того как изменяются данные приложения (в процессе работы с приложением), папка с данными приложения помечается как резервируемая и начинается ее резервное копирование с помощью системных средств.

Источник

Понравилась статья? Поделить с друзьями:
  • Либхер комфорт инструкция liebherr icuns 3324 001
  • Руководство мчс в своей работе
  • Амбробене сироп инструкция по применению взрослым от влажного кашля инструкция
  • Как получить пушкинскую карту школьнику на госуслугах пошаговая инструкция
  • Инженер по оос эколог должностная инструкция