Истек год с момента выхода технологии внешних компонент для мобильных приложений (далее ТВК). Это довольно большой срок в IT отрасли, который дает право подвести некоторые итоги, подчеркнуть достоинства и указать на недостатки. Однако, если посмотреть на количество открытых приложений, написанных с использованием этой технологии, например, в библиотеке Инфостарта, то нам для их подсчета хватит пальцев одной руки. Причины тому очевидны: сложность, неудобство разработки, а знания, которые необходимы, находятся далеко от того, чем занимается обычный 1С разработчик. Но есть и второй подводный камень – искусственные ограничения, установленные 1С. С одной стороны, выпустив мобильную платформу, 1С поставила грандиозную задачу унификации мобильной разработки для всех ОС. Программист мобильных приложений должен знать 1С и ничего больше. Даже в другом универсальном решении - Xamarin при обращении к однотипным устройствам аппарата, например, сенсорам, приходится программировать, учитывая особенности конкретной операционной системы. В мобильной платформе не так – позиционирование в пространстве, работа с мультимедиа и другие операции выполняются одинаково. Но эта стандартизация ограничена мобильной платформой 1С. Расширить наши возможность может ТВК, но препятствия, которые следует преодолеть, значительно превзойдут сложность разработки на «родных» языках мобильных ОС (Java/C#/Objective-C).
Рассмотрим ограничения, с которыми сталкивается разработчик внешних компонент под андроид. Как было сказано, иногда они искусственные. Например, 1С закрыла доступ из компоненты к визуальной части интерфейса приложения. Программист не может вывести свою собственную форму (Activity) на экран. Кто изучал пример внешней компоненты для андроид от 1С догадается, что для этого управляемый код компоненты выполняется в отдельном потоке (базовый java класс наследуется от Runnable). Но побочным эффектом такой архитектуры является то, что мы не можем запускать объекты, требующие основного потока приложения для своего функционирования. Один из способов обхода этого ограничения представлен в компоненте «Распознавание речи». В андроиде доступ к сервисам распознавания предоставляет класс SpeechRecognizer. Метод-фабрика его создания – createSpeechRecognizer должен вызываться на базе контекста основного потока приложения. Поэтому приложение состоит из двух частей: собственно внешней компоненты, оформленной по стандарту 1С как устройство ввода и отдельного приложения, которое запускается компонентой и отправляет оповещения (broadcast). Оповещение принимает внешняя компонента и генерирует внешнее событие в 1С. Получение оповещений и отправка намерений (intent) – функциональность с которой ТВК прекрасно справляется. Пример кода стандартный:
BroadcastReceiver mReceiver = new BroadcastReceiver()
{
@Override
public void onReceive(Context context,Intent intent)
{
// Обработка сообщения
}
};
Но перед регистрацией получателя обязательно программируем фильтрацию:
final Intent intent = mActivity.getPackageManager().getLaunchIntentForPackage(PackageName);
intent.putExtra(“SomeParameter”,mParameter);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
mActivity.startActivity(intent);
Рассмотрим другой пример, когда из-за несовершенства архитектуры ТВК приходится писать дополнительное ПО – компонента для считывания ввода с физической клавиатуры. Ею снабжены многие промышленные сканера. Если бы мы создавали отдельное приложение для андроид, задача не представляла бы особой трудности. Активность унаследована от KeyEvent.Callback, поэтому необходимо всего лишь переопределить обработчик onKeyDown. Но у нас нет доступа к основному контексту мобильного приложения 1С. Вторым подходом к решению задачи будет напрямую читать из /dev/input/event2 (файл клавиатурного ввода в linux). Если это было бы возможно, мы получили бы хорошее решение только на C++ без дополнительных связок с управляемым кодом. Но, к сожалению, в андроиде прямой доступ к устройствам ввода запрещен. Выход – устанавливать такую компоненту только на устройства с разблокированным пользователем root или писать отдельный драйвер тоже с root правами.
Второе приложение к статье – «Барометр» представляет собой пример обращения к сенсору. Следует отметить, что из-за отсутствия в классе компоненты событий onResume и onPause, ответственность на включение и отключение устройства ложится на программиста 1С. Если мобильное приложение перейдет в спящий режим, а сенсор не будет отключен, оно может сильнее разряжать батарею. Это же замечание верно для оповещений (Broadcast). Многие сенсоры, реализующими интерфейс SensorEventListener, а также сканер отпечатка пальца можно запрограммировать через ТВК. Приведу почти полностью класс компоненты для измерения давления:
public class Pressure implements Runnable, SensorEventListener {
private Activity m_Activity;
private SensorManager m_Manager;
private Sensor m_Sensor;
public void run()
{
// подключение so-файла с нативной частью кода
}
public void show()
{
m_Activity.runOnUiThread(this);
m_Manager = (SensorManager)m_Activity.getSystemService(Context.SENSOR_SERVICE);
if (m_Manager!=null)
m_Sensor = m_Manager.getDefaultSensor(Sensor.TYPE_PRESSURE);
}
@Override
public final void onAccuracyChanged(Sensor sensor, int accuracy)
{
}
@Override
public final void onSensorChanged(SensorEvent event)
{
if (event.values.length > 0)
{
// отправка сигнала в нативную часть компоненты (а затем в 1С)
}
}
public Pressure(Activity activity)
{
m_Activity = activity;
}
public boolean startListen()
{
if (m_Sensor!=null)
{
m_Manager.registerListener(this,m_Sensor,SensorManager.SENSOR_DELAY_NORMAL);
return true;
}
else
return false;
}
public void stopListen()
{
if (m_Sensor!=null)
m_Manager.unregisterListener(this);
}
}
Имея «нулевой» опыт разработки под iOS, в этой статье я ничего не могу сказать о компонентах для этой системы, возможно кто-то из членов сообщества поделится своим опытом в этой сфере. А вот о создании компонент для windows phone поговорил бы с удовольствием, но к сожалению, 1С здесь потерпело полное поражение.
Мобильная платформа для winphone, вышедшая на рубеже 2015/2016 года, была уже тогда устаревшей, так как почти одновременно вышла мобильная windows 10. Эти две системы, имея общее название, по сути являются принципиально различными. Все новые датчики и устройства телефонов на windows 10 программируются с помощью universal windows platform (UWP). Подсистема windows runtime (WinRT), являющаяся базой в windows 8, в windows 10 оставлена для совместимости и не имеет API для новых функций. (Знающие архитектуру winphone могут поставить это утверждение под сомнение, спросив, каким же образом сама 1С написала сканирование штрихкодов, которое работает на windows 10 и не работало на windows 8? Ответ находится при изучении состава платформы для winphone – была использована сторонняя библиотека ZXing). В windows phone невозможно по аналогии с андроид написать отдельное приложение или службу, с которого 1С будет получать данные: в этой ОС нет межпроцессного взаимодействия. Таким образом, мы можем, глядя из песочницы 1С, только облизываться на устройства телефона под управлением windows phone 10: барометр, сканер отпечатка пальца, сканер сетчатки глаза, не имея к ним доступа.
Допустим, мы хотим написать компоненту только для windows phone 8. Но и в этом случае столкнемся с практически непреодолимыми препятствиями. В документации по развертыванию мобильных приложений 1С на веб-сервере сказано, что внешние компоненты для winphone не устанавливаются на мобильной платформе 1С для тестирования. То есть, отсутствуют пути для их отладки. В андроиде можно переключить телефон в режим разработчика и устанавливать любое число раз на него скомпонованное приложение. Такой режим есть и у аппаратов на windows phone 10, но он не позволяет устанавливать тестовые приложения на WinRT. Таким образом, внешние компоненты для winphone 8 следует писать сразу без ошибок. Бурные овации таким разработчикам!
Универсальность внешних компонент вряд ли достижима, хотя 1С и старается создать какой-то стандарт. Даже физически разные мобильные устройства сильно отличаются, не говоря уж о программном обеспечении. Представим себе организацию, которая использует мобильное приложение для приемки товара, которое устанавливается на ТСД под управлением андроид, имеющие лазерный сканер, на планшеты под windows 8 с присоединенными сканерами через usb и настроенными на клавиатурный вывод. Для ТСД на андроиде написана внешняя компонента, на windows она не нужна. Но сборщик мобильных приложений откажется формировать установочные файлы и скажет, что отсутствует компонента для windows. Разработчики вынуждены либо формировать отдельные cf для разных ОС либо создать компоненту-пустышку для windows, чтобы удовлетворить требованиям 1С.
О примерах к статье
В архивах находятся файлы конфигураций и справочные текстовые файлы о развертывании и документация по компонентам. Для запуска на устройствах их необходимо собрать сборщиком мобильных приложений. Компоненты тестировались на релизе мобильной платформы 8.3.11.57.
