Приложение получается родное (нативное) под Android и скорость запуска соответствующая.
Можете протестировать сами, установив демо-приложения с Google Play (по этой статье пока нет, но есть 2 других). Линки и инструкции по на стройке есть на нашем сайте.
1. Симметричный, например DES
2. В роли ключа «сигнатура подписи + солью», генерировать его динамически из нескольких кусочков
Если это найдут и потратят время на взлом, значит, ваша программа уже достаточно популярна. Можно больше не заморачиваться на защите и просто выпустить открытую версию. Иначе затраты на защиту (и поддержание ее в актуальном состоянии) в конечном итоге могут превысить стоимость разработки.
Как вам такой вариант защиты без NDK?
— В raw или assets кладем текстовый файл, содержащий исходный код (часть функциональности) зашифрованный ключом разработчика
— Когда требуется, приложение пытается расшифровать и выполнить его, используя информацию о текущем сертификате которым подписано приложение.
Минусы, на мой взгляд:
— дополнительная библиотека
— «целостность» программы не контролируется т.к. часть кода в текстовом файле
— злоумышленник может вставить выполнение своего кода
Взломать можно, но для этого потребуется сначала «вычислить» ключ разработчика, затем расшифровать текстовый файл и заново зашифровать уже свой ключом, которым будет подписываться взломанная версия программы.
Это конечно здорово, что 1С сейчас реагирует быстрей, чем раньше с «1С: Предприятие. Расширение для КПК». Не нравится то, что они навязывают свой “Пользовательский интерфейс”.
Я бы даже сказал, не навязывают, а бездумно копируют с ББ. User Experience от их примеров c Google Play никакой.
B еще пару вопросов, раз уж вы обладаете инсайдерской информацией:
— что там с отладчиком на мобильном устройстве, неужели придумают?
— что с лицензированием и стоимостью? Раньше проскакивала информация, что будет как раньше для WM – одна лицензия на 1 КПК.
И вроде бы как на распространение через магазины типа Google Play тоже будут какие-то ограничения.
Смотрите так же урок посложней — «Заказы покупателя», где показан пример создания документа программно. По интерактивному созданию т.е «из формы» урок еще не готов. См. в документации пакет ru.profi1c.engine.widget, классы Field<> и ObjectView предназначены для облегчения интерактивного редактирования объектов и его реквизитов.
Сравнение с существующими решениями 1С тянет на отдельную статью. Но, как уже отметил Asmody, с FBA вы создаете «родное» приложение для Android.
С 1С вы можете использовать только те возможности, что «вам разрешат», например, будете ждать пока (и если вообще) добавят возможность получения координат, возможность сделать фото т.д. С FBA вы не ограничены ни чем. Делайте виджеты, используйте возможности мультимедиа, да хоть управляйте КПК по средствам смс-сообщений… Плата за это – выше порог вхождения, т.е. знаний только по 1С будет маловато.
Посмотрите пример «Задачи для мобильного сотрудника». Там выполненные задачи сохраняются в локальной базе, а затем при обмене передаются «в обратную сторону»
Что подразумевается под фразой «стандартный подход», использование связки AsyncTasks & ProgressDialogs? Если да, то этот вариант не лучше, просто для для другой ситуации — когда вместо AsyncTasks надо использовать AsyncTaskLoader и информировать о прогрессе выполнения.
Если быстро и на один раз, то можно все (Progress + Loader) реализовать в одном классе наследнике DialogFragment.
В моем варианте Loader отделен от фрагмента, если потребуется добавить еще один Loader c другой логикой – не проблема (см. п.4). Да и диалог можно сделать другой (отображающий progress bar вместо тестового сообщения), в статье на это не акцентировано внимание, но в исходниках есть AbstractTaskLoader. publishProgress(int), останется только добавить отработку в AbstractTaskProgressDialogFragment. Handler полученного значения. В общем, я старался сделать универсальное решение.
Можете протестировать сами, установив демо-приложения с Google Play (по этой статье пока нет, но есть 2 других). Линки и инструкции по на стройке есть на нашем сайте.
2. В роли ключа «сигнатура подписи + солью», генерировать его динамически из нескольких кусочков
Если это найдут и потратят время на взлом, значит, ваша программа уже достаточно популярна. Можно больше не заморачиваться на защите и просто выпустить открытую версию. Иначе затраты на защиту (и поддержание ее в актуальном состоянии) в конечном итоге могут превысить стоимость разработки.
— В raw или assets кладем текстовый файл, содержащий исходный код (часть функциональности) зашифрованный ключом разработчика
— Когда требуется, приложение пытается расшифровать и выполнить его, используя информацию о текущем сертификате которым подписано приложение.
Пример выполнения кода из текста здесь.
Минусы, на мой взгляд:
— дополнительная библиотека
— «целостность» программы не контролируется т.к. часть кода в текстовом файле
— злоумышленник может вставить выполнение своего кода
Взломать можно, но для этого потребуется сначала «вычислить» ключ разработчика, затем расшифровать текстовый файл и заново зашифровать уже свой ключом, которым будет подписываться взломанная версия программы.
Я бы даже сказал, не навязывают, а бездумно копируют с ББ. User Experience от их примеров c Google Play никакой.
B еще пару вопросов, раз уж вы обладаете инсайдерской информацией:
— что там с отладчиком на мобильном устройстве, неужели придумают?
— что с лицензированием и стоимостью? Раньше проскакивала информация, что будет как раньше для WM – одна лицензия на 1 КПК.
И вроде бы как на распространение через магазины типа Google Play тоже будут какие-то ограничения.
С 1С вы можете использовать только те возможности, что «вам разрешат», например, будете ждать пока (и если вообще) добавят возможность получения координат, возможность сделать фото т.д. С FBA вы не ограничены ни чем. Делайте виджеты, используйте возможности мультимедиа, да хоть управляйте КПК по средствам смс-сообщений… Плата за это – выше порог вхождения, т.е. знаний только по 1С будет маловато.
В моем варианте Loader отделен от фрагмента, если потребуется добавить еще один Loader c другой логикой – не проблема (см. п.4). Да и диалог можно сделать другой (отображающий progress bar вместо тестового сообщения), в статье на это не акцентировано внимание, но в исходниках есть AbstractTaskLoader. publishProgress(int), останется только добавить отработку в AbstractTaskProgressDialogFragment. Handler полученного значения. В общем, я старался сделать универсальное решение.