Валентина, ты показала Ваше первое приложение в Delphi для Android .
Решает ли это конкретную проблему или это просто инициативная разработка, «проба пера»? Есть ли за этим реальные потребности бизнеса?
Первое мобильное приложение, написанное на Delphi для Android, стало для меня своего рода пробным камнем на пути к возможности разработки определенных частей информационной структуры предприятия на мобильных платформах.
Во многих предприятиях (которые являются нашими клиентами) сразу можно найти задачи, которые можно перенести на мобильную платформу.
Это, прежде всего, задачи, связанные с персоналом, не имеющим возможности доступа к данным информационной системы с обычного компьютера или ноутбука; локальной сети и Wi-Fi нет, только мобильная сеть.
Это работники на удаленных объектах, где нет возможности организовать стационарное рабочее место в силу определенной специфики, например, курьеры или выездные менеджеры.
Для таких задач хорошим решением станет Android-планшет с 3G-модулем.
От нас требуется обеспечить подключение к базе данных, удобный интерфейс и компактный трафик обмена данными.
Что касается решаемых задач, то задачи, которые мы сейчас решаем с помощью мобильной разработки под Android, могу описать кратко, но без конкретики (при уважении интересов наших клиентов).
Одна из задач: на удаленном объекте находится специалист, который должен передать небольшой объем оперативной информации по заказу — текущее состояние решаемой им задачи и некоторые выходные данные.
Данные должны быть переданы в информационную систему оперативно, поскольку от этого зависит дальнейшее прохождение заказа по цепочке.
Кроме того, для решения своих задач он должен получать дополнительную актуальную информацию, которую вводят в систему другие специалисты, возможно, также с мобильного устройства.
Использование мобильного устройства, а не ПК с Windows, определяется в основном весовыми характеристиками планшета.
«7 дюймов» легко помещаются в большой карман или небольшую сумочку и не ощущаются человеком как дополнительный вес, что позволяет носить эти устройства всегда и везде.
Да и работать они могут более 6 часов.
Как эти проблемы решались раньше: либо специалист носил с собой ноутбук с возможностью подключения к сети 3G, либо звонил или отправлял СМС диспетчеру.
Работа с ноутбуком не всегда возможна, а работа через диспетчера означает потерю оперативности и актуальности данных и, конечно же, человеческий фактор.
Перенос такой задачи на мобильную платформу в версии базы данных MS SQL Server (для наших задач только она) — Data Snap — приложение для Android лишено вышеперечисленных недостатков.
Еще одна типичная задача, пользующаяся большим спросом, - это сбор оперативных данных с удаленных объектов, где нет и не будет возможности развернуть стационарные рабочие места в силу некоторых особенностей - например, неохраняемое, неотапливаемое помещение без электричества (это тоже бывает).
Для такой задачи недорогой планшет на Android — очень подходящее решение; даже время работы не очень критично, так как требуется только сеансовое подключение к базе данных.
В наших производственных задачах решения для iOS, увы, остаются в стороне из-за политики Apple в отношении обновления приложений, не говоря уже о стоимости устройств, и никаких изменений в лучшую сторону в ближайшее время не предвидится.
Для массового использования, например на производстве, существенны стоимость владения и скорость обновления специализированного программного обеспечения, например, при развертывании 100 и более мобильных рабочих станций.
Также стоит задача оперативного ввода данных из точек, распределенных по предприятию, где у сотрудника имеется рабочее место с настольным компьютером, подключенным к сети, но в связи, опять же, со спецификой работы, он должен вводить некоторые данные за один раз.
расстояние от рабочего места, например, проверка содержимого заказа.
Сборщик заказов должен видеть позиции заказа, но вводит только «ОК» или «Проблема».
Для таких задач использование сети Wi-Fi и планшета Android с модулем Wi-Fi делает стоимость решения еще ниже.
Дизайн мобильного приложения обычно основывается на определенном «сценарии» использования.
Можете ли вы поделиться? При разработке интерфейса и философии работы мобильного приложения учитываются как особенности самого мобильного устройства – сенсорный ввод, ожидаемое разрешение экрана, так и «особенности» пользователя.
Другими словами, один и тот же функционал, реализованный для менеджера на поле и для оператора на удаленной площадке, может отличаться из-за «особенностей восприятия» пользователем мобильного устройства.
Прежде всего, это комфортное использование без ущерба для функциональности приложения.
Пользователи наших клиент-серверных приложений привыкли работать с функционально насыщенным экраном, по сути, пультом дистанционного управления, на котором вся необходимая информация всегда под рукой, или на виду, или доступна в один клик, или доставляется всплывающим окном.
вверх уведомления.
Поэтому для интерфейса мобильного приложения очень важно, чтобы при работе пользователь не чувствовал себя скованным в своих действиях и доступе к необходимой информации.
Апофеоз пользовательского дискомфорта очень хорошо выражен фразой «Вы заставляете меня двигать мышкой!» Поэтому в идеале нам бы хотелось, чтобы пользователь мобильного приложения воспринимал его почти как игру или хотя бы получал удовольствие от работы с ним.
И вдруг в ходе разработки оказывается, что использование «сеток» для отображения информации на мобильных устройствах не всегда оправдано — их неудобно прокручивать, а в большинстве случаев использование ListBox и ListView предоставляет пользователям мобильных устройств гораздо более интуитивные возможности.
Самое неприятное, что в мобильной версии приложения пользователь лишен десктопной «мультиоконности», и здесь ему приходится решать, какой информацией вообще придется пожертвовать, чтобы «мобилизовать» решение, а какой информация будет скрыта под закладками или вынесена в отдельные формы или всплывающие меню.
Поэтому интерфейсы задач «десктопного» и его «мобильного брата» хоть и имеют схожий функционал, но совершенно разные.
Поскольку мобильное приложение разрабатывается под конкретного заказчика и задачу, проблем с совместимостью с устройствами не возникает, поскольку мы точно знаем, какие устройства и с какими характеристиками будут использоваться заказчиком.
Можете ли вы попросить несколько скриншотов - желательно по мере работы над сценарием? Технических проблем нет, но есть и другие соображения.
Наши клиенты рассматривают наличие мобильных решений как дополнительное конкурентное преимущество, поэтому мы решили отказаться от размещения фотографий.
Кстати, это большая проблема не только мобильных приложений, но и клиент-серверных систем.
Я могу показать вам только самый лучший пилотный проект, да и то мне пришлось его скрыть.
Интерфейс полноценного текущего проекта пришлось бы полностью замазать, извините, «по уши», осталась бы только «полоска зарядки».
Без ущерба для клиентов могу показать только самый первый прототип, да и то с размытыми данными.
В среде IDE также будет представлено представление проекта для тонкого мобильного клиента и сервера DataSnap. 
Разработка интерфейса приложения оказалась достаточно трудоемкой задачей с точки зрения эргономики, при этом сама функциональность приложения не вызвала никаких проблем; мы работали в знакомой среде программирования — Delphi XE5.
Кстати, как и большинство разработчиков, я что-то «леплю» себе.
Я могу показать это: 
Что такое компонентная база приложения? Что используется и как?
При разработке наших приложений мы всегда стараемся максимально минимизировать набор сторонних компонентов, чтобы иметь как можно меньше зависимости от других разработчиков при переводе проектов на новые версии продуктов Embarcadero, тем более, что они выпускаются с такими частота.
В случае разработки наших мобильных приложений даже стандартного набора компонентов, входящего в версию Delphi XE5 Enterprise, по-прежнему достаточно, поскольку он содержит возможности мобильной разработки, Data Snap и FireDAC.
Кроме того, использование «стилей» для Android вполне способно «оживить» интерфейс приложения.
Решение, предлагаемое TMS, выглядит визуально и функционально привлекательно, но я пока использовал эти компоненты только при разработке приложений для Mac OS. Было бы здорово, если бы Embarcadero включил их в стандартную комплектацию, хотя бы в версию Enterprise. Ведь так произошло с Fast Report и Fire DAC. Как и откуда берутся данные?
Работа с данными организована следующим образом — есть сервер базы данных (MS SQL Server), есть сервер Data Snap, через который клиент на Android работает с данными.
Как действия пользователя записываются в «базу данных» (если к ней есть подключение)? Естественно, связь с базой данных есть; все, что вводит пользователь, сразу отражается в базе данных.
Как менеджеры обходились без этого приложения? Естественно, что раньше и менеджеры, и работники на удаленных объектах обходились без мобильных приложений.
Раньше даже простые люди обходились без мобильной почты и телефона.
Они пользовались ноутбуками, звонили, писали письма, отправляли курьеров с посылками, готовили отчеты с такой задержкой, что данные уже не были актуальны.
Как вы думаете, насколько ускорились бизнес-процессы? Вообще говоря, при автоматизации производства использование мобильных решений (здесь я имею в виду не только мобильные приложения, но и веб-решения) настолько существенно повышает эффективность производства, что в конечном итоге это выражается в весьма существенных цифрах.
Потому что есть процессы, которые технически вообще не реализованы в немобильной версии, либо реализованы очень дорого.
Основное преимущество, которое дает мобильное решение, — оперативное взаимодействие с обратной связью, именно это лежит в основе клиент-серверных решений — все процессы происходят в режиме реального времени.
Видите ли вы дальнейшее развитие функционала приложения? Да по крайней мере для мобильного менеджера уже есть идеи по развитию, и эти идеи уже исходят не только от нас, но и от самих пользователей.
Вы можете развиваться бесконечно; при наличии времени и средств можно довести функционал до «настольной» системы, особых технических проблем нет — Embarcadero Delphi XE5 Enterprise это позволяет. Если система изначально проектировалась как трехуровневая, то скорость трансляции определяется технической скоростью написания кода.
Главное — не торопиться и решать проблемы шаг за шагом.
Основная проблема — размер экрана мобильного устройства и эргономика (размер элемента управления должен быть существенно больше для пальца, чем для мыши).
Насколько вы считаете такое решение типичным в рамках «корпоративной мобильности»?
Я считаю, что наши мобильные решения типичны для тех отраслей, для которых мы их разрабатывали, поскольку основные бизнес-процессы для разных клиентов в одной отрасли зачастую различаются лишь предпочтениями менеджеров и исторически сложившимися правилами (даже с учетом географического положения).
Например, пользователями наших мобильных решений являются менеджер по продажам, работник склада, водитель-экспедитор, комплектовщик заказов, логист удаленного объекта, менеджер по закупкам/продажам, мастер по сырью/продукции, менеджер по согласованию документов, оборудования.
слесарь по ремонту (да, наши системы следят за оборудованием), технолог производства.
То есть решаются стандартные производственные задачи.
Воспользуйтесь этой возможностью, чтобы пожелать нам «без сахара» для Embarcadero. Думаю, что не буду оригинален в этом вопросе, но в отличие от других «камнеметателей» постараюсь меньше их забрасывать, понимая сложные и новые задачи, которые решают продукты линейки средств разработки.
Кстати, параллельно я рассматриваю разработку мобильных приложений с использованием других (не буду здесь называть каких) инструментов разработки, поэтому могу сравнить два мира - две системы, и внести некоторые предложения.
Я знаю, что для корпоративных мобильных приложений его размер не критичен, тем более что установка новой версии на планшет для пользователя не составит труда.
Однако мне все же хотелось бы видеть меньший объем заявок.
Я так понимаю, это нормальное желание приложения занять всю оперативную память во время работы.
У Live Binding особенно хороший аппетит – хотелось бы и здесь увидеть некоторый прогресс.
Мы заметили неприятную особенность «вялости» интерфейса при использовании Live Binding, как при работе с терминальным сервером по плохому каналу.
Я хочу ускорения.
Когда запускаю приложение.
кофе пить не успеваю, но успею)) 5-7 секунд это минимум.
Все вышеперечисленное существенно не мешает процессу разработки, однако решение этих проблем существенно повысит привлекательность Embarcadero как средства разработки конкурентоспособных мобильных приложений не только в корпоративном секторе.
Спасибо, Валентина! Теги: #delphi #Android #embarcadero #delphi
-
О Тайм-Менеджменте, Саморазвитии И Деньгах
19 Dec, 24 -
Кризис - Доллар Будет Стоить 60-100 Рублей
19 Dec, 24 -
Реклама Adwords Становится Слишком Дорогой
19 Dec, 24
