Валентина, Вы показывали Ваше первое приложение в Delphi for Android. Оно решает какую-то конкретную задачу или это просто – инициативная разработка, «проба пера»? Стоят ли за этим реальные бизнес-потребности?
Первое мобильное приложение, написанное в Delphi for Android, был для меня это неким пробным камушеком в сторону возможности развивать определенные части информационной структуры предприятия на мобильных платформах.
На многих предприятиях (являющихся нашими клиентами) сходу можно найти задачи, которые можно вынести на мобильную платформу. Это, в первую очередь задачи, связанные с персоналом, у которого нет возможности получить доступ к данным информационной системы с обычного компьютера или ноутбука, нет локальной сети и WiFi, только мобильная сеть. Это работники удаленных площадок, на которых нет возможности организовать стационарное рабочее место в силу определенной специфики, например, курьеры или менеджеры на выезде.
Для таких задач планшет на Android с 3G-модулем – хорошее решение. От нас требуется обеспечить связь с базой данных, удобный интерфейс, компактный трафик обмена данными.
По поводу решаемых задач — могу описать задачи, которые мы решаем сейчас, используя мобильную разработку для Android кратко, но без специфики (соблюдая интересы наших клиентов).
Одна из задач: есть специалист, находящийся на удаленной площадке, который должен передать небольшой объем оперативной информации по заказу – текущее состояние проблемы, которую он решает, и некие выходные данные. Данные должны быть переданы в информационную систему оперативно, так как от этого зависит дальнейшее прохождение заказа по цепочке. Кроме того, для решения своих задач, он должен получить дополнительную актуальную информацию, которая вносится в систему другими специалистами, возможно, тоже с мобильного устройства. Использование мобильного устройства, а не ПК под Windows, определяется в основном весовыми характеристиками планшета. «7 дюймов» легко помещаются в большой карман или маленькую сумочку и не ощущаются человеком как дополнительный вес, что позволяет носить эти устройства всегда и везде. Да и работать они могут более 6 часов.
Как решались это проблемы раньше: либо специалист носил с собой ноутбук с возможностью подключаться к сети 3G, либо звонил или посылал SMS диспетчеру. Работа с ноутбуком не всегда возможна, а работа через диспетчера – это потеря оперативности и актуальности данных и, естественно, человеческий фактор.
Вынос такой задачи на мобильную платформу в варианте – БД 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.
Как действия пользователя фиксируются в «базе данных» (если есть связь с ней)?
Естественно, связь с базой данных есть, все, что вносит пользователь, сразу отражается в базе данных.
Как без этого приложения менеджеры обходились?
Естественно, и менеджеры, и работники на удаленных площадках раньше обходились без мобильных приложений. Раньше ведь и обычные люди обходились без мобильной почты и телефона. Использовали ноутбуки, звонили, писали письма, посылали курьеров с пакетами, готовили отчеты с таким сроком запаздывания, что данные уже были неактуальны.
Насколько по-Вашему ускорились бизнес-процессы?
Вообще говоря, при автоматизации производства использование мобильных решений (тут я имею в виду не только мобильные приложения, но и web-решения) повышают эффективность производства настолько существенно, что это выражается в итоге довольно солидными цифрами. Потому что есть процессы, которые в немобильном варианте технически вообще не реализуются, либо реализуются очень затратно.
Основное преимущество, которое дает мобильное решение – это оперативное взаимодействие с обратной связью, это именно то, что является основой клиент-серверных решений – все процессы происходят в реальном времени.
Видите ли Вы дальнейшее развитие функционала приложения?
Да, по крайней мере, для мобильного менеджера уже есть идеи для развития, причем эти идеи уже идут не только от нас, но и от самих пользователей. Развивать можно бесконечно, при наличии времени и финансирования можно довести функциональность до «десктопной» системы, особых технических проблем нет – Embarcadero Delphi XE5 Enterprise это позволяет. Если же система была изначально спроектирована как трёхзвенная, то скорость перевода определяется технической скоростью написания кода. Главное – не торопиться и решать задачи поэтапно.
Основная проблема – это размер экрана мобильного устройства и эргономика (размер управляющего элемента должен быть существенно больше для пальца, чем для мыши).
Насколько Вы считаете данное решение типовым в рамках «корпоративной мобильности»?
Считаю, что наши мобильные решения — типовые для тех отраслей, для которых мы их разработали, поскольку основные бизнес-процессы для разных клиентов в одной отрасли часто отличаются лишь предпочтениями руководителей и исторически сложившимися правилами (даже с учетом географического расположения).
К примеру, пользователи наших мобильных решений – менеджер по продажам, работник склада, водитель-экспедитор, комплектовщик заказов, логист удаленной площадки, руководитель закупки/продаж, мастер по сырью/продукции, руководитель, утверждающий документы, ремонтник оборудования (да, наши системы мониторят оборудование), технолог производства. То есть, решаются типовые производственные задачи.
Пользуясь случаем, предоставьте нам «sugar-free» пожелания к компании Embarcadero
Я думаю, что в этом вопросе не буду оригинальна, но в отличие от других «камнекидателей» постараюсь кидать их поменьше, понимая те сложные и новые задачи, которые решают продукты линейки средств разработки. К слову сказать, параллельно я рассматриваю разработку мобильных приложений на других (не буду здесь называть, каких)средствах разработки, поэтому могу сравнить два мира – две системы, и высказать некоторые предложения
- Знаю, что для корпоративных мобильных приложений его размер не критичен, тем более что установка новой версии на планшет пользователем не составляет труда. Однако все равно хотелось бы увидеть меньший объем приложений.
- Понимаю, что это нормальное стремление приложения – занять при работе всю оперативную память. Особенно хороши аппетиты у Live Binding – хотелось бы и тут каких-то подвижек.
- Замечена неприятная особенность «заторможенности» интерфейса при использовании Live Binding, как при работе с терминал-сервером по плохому каналу. Хочется ускорения.
- При старте приложения… кофе попить не успеваю, но заварить могу успеть )) 5-7 секунд – это минимум.
Всё описанное выше не сильно мешает процессу разработки, но решение этих проблем существенно повысило бы привлекательность Embarcadero как средства разработки конкурентоспособных мобильных приложений не только в корпоративном секторе.
Спасибо, Валентина!
Автор: FireMonkey
