повозившись с мобильной платформой 1с, захотелось чего то нового, хардкорного. ну и подбивают на автоматизацию братьев заграничных. в общем, вопросы:
1. на чем сейчас пишут под андроид, что в тренде? котлин загибается уже?
2. какие мобильные субд можно использовать, ну кроме мскл?
3. в какие магазины приложений можно пробиться? что реально доступно?

1. Пишут на том что знают
2. SQLite самая популярная, формат базы одинаков с десктопом, можно легко переносить
3. В любые, проблема только вывода средств

(1) 3. но бесплатное размещать же можно без проблем? оченно хорошо..

(2) Даже платно размещать можно.
Но хрен средства выведешь.

(0) посмотри в сторону Dart и Flutter. Можно сразу не только андройд, но и iOS отвоить одним фраймворком. А при желании им и веб и десктоп можно закрыть

(3) было бы что выводить. все решаемо

(0) Кажется под андроид сейчас Kotlin является мейнстримом

(6) Мейнстрим до сих пор Java и C++
Kotlin это по сути как Scala сахарная обертка сверху для сокращения кода
Фактически код переводится в Java и уже затем компилится

(7)+ Один хрен большая часть либ и фреймворков на Java
Надо его знать чтобы ковыряться и допиливать

(8) понял, по котлину за три года ничего не поменялось)
спасибо за инфу!

(4) Lazarus/Delphi в этом случае ничем не хуже а даже лучше
И на GoMobile можно но там плохо с UI, хотя если надо низкоуровневая графика (игры) то прекрасно через OpenGL
Но самым популярным до сих пор остается HTML/CSS/JS завернутое в нечто

(4) нужен только андроид, изучаю для целей развития начатой пару лет назад темы.

(10)+ Ну и Xamarin если знаем/нравится C#

(11) Тему кратко опиши
Что приложение должно делать
Чтобы выбрать на чем лучше

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

(14) Ааа это неинтересно
Тема уже заезженная
И МП 1С вполне умеет в мультиязычность, там проблема только что в самой 1С хрен язык выберешь, привязан к языку системы

Имхо самое удобное это попробовать Delphi 12
Ничего лучше не нашел, все остальное сплошные костыли
Начать можно с Delphi 11 Community Edition
https://www.embarcadero.com/ru/products/delphi/starter

(15) с 1с проблемы, начиная от мультиязычности, заканчивая защитой и монетизацией.
в общем, ОЧЕНЬ удобно отрабатывать бизнес-модель, но развивать нет.

(16) ну с явой нормально, думал, может по котлин есть новости.

(14) может работу с драйвером сканера нужно будет дописать, а так основной функционал можно практически без кода сделать например на FlutterFlow.

и почему мобильная платформа 1с не пошла? по ссылке же вроде готовый продукт уже был

(16) удивлен что делви еще жива и развивается. Я еще с 4 версии начинал

Только смотрю они себя теперь позиционируют и под мобилки и под мас, но линукса так и не добавили. Линукс все таки добавили в 12 версии

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

(21) смотри FlutterFlow. Можно быстро собрать MVP. Потом выгрузить исходный код и дорабатывать дальше. А главное перспективы очень неплохие для развития себя как программиста дальше на Darte

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

(22) ок, спасибо, посмотрю.

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

(21) МП 1C вполне хорошо когда надо с данными работать
Для сложного пользовательского интерфейса есть ПолеHTML
Я вот такое делал
https://cloud.mail.ru/public/cSmx/e89HH6vCm

(26)+ И да ТабДок в МП 1С это самая лучшая штука для показа таблиц
На других ЯП/системах под мобилы до такого как пешком до Луны

(27) ето да..

(27) Да ты чего, вот насмешил то. Google имеет свое видение интерфейсов https://m3.material.io/  и ей десктопная реализация 1С внутри ее Андройда вообще по по барабану. Ну в общем не гони.

(29) ты немного не понял
grid'ов есть много
но они убогие по сравнению с ТабличныйДокумент

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

(30) Ты просто привык к ТабличномуДокументу и от него и пляшешь (Excell в твоей голове). А на разноразмерных экранах надо очень гибко рисовать по разному.

(32) я много к чему привык
суть что в 1С есть готовый "компонент"
а там придется покопаться, возможно покупать платный и один хрен дописывать его самому
и то не все выйдет хорошо, как легко умеет табдок

Ну и как ты этот готовый компонент будешь использовать для
1280x720  - Xiaomi Redmi Go (Nexus1) и  3200 × 1440  Xiaomi 14 Pro? Ты пробовал переключать редактор форму при разных телефонах?

(34) Прекрасно использовать ))
Уже использовал, когда любился с гридом две недели на Java (в свое время задолго до выхода МП 1С)
И когда сваял потом после выхода МП 1С на ТабДок тоже самое за один день

Суть в том что надо тебе повернуть текст или сделать его разным шрифтом/размером в разных ячейках и/или закрепить ячейки слева/сверху - никаких проблем
Надо чтобы не только по вертикали но и по горизонтали прокрутка была - никаких проблем
Картинки/ШК вставить - никаких проблем

А в доступных гридах на "больших языках" под мобилы это ахтунг
С переписыванием исходников на низком уровне
Но обычно все заканчивается уже на отсутствии поддержки кириллицы ))

(35) Ах простите нас старые layout из древнего андройда https://startandroid.ru/ru/uroki/vse-uroki-spiskom/15-urok-6-vidy-layouts-kljuchevye-otlichija-i-svojstva.html
Недостойный старый constraint layout позволяющий всё конечно не нужен. Новомодные compose функции просто дурь какая-то если есть табдокумент ;)

(36) 1. Речь шла про времена появления МП 1С
2. Советую самому попробовать на практике

(36)+ и да лайоут штука конечно хорошая
но до табдока ей далеко как и до УФ

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

короче все тоже самое что и на больших компах
на 1С учетное приложение делается намного быстрее и проще

(38) Угу, а потом просят залить серым фоном недоступные элементы для редактирования. И все, приехали.

(0)
1. PWA - на JS
2. IndexedDB
3. Можно публиковать приложение на любой веб-сервер, даже на свой собственный

(39) Посылаются нафик
Согласен что на 1С куча ограничений когда спускаешься ниже
И много неприятных багов/глюков (речь про мобильные приложения)
Но по скорости разработки с отличной функциональностью лучше нет

(41) Много что есть лучше. На бутстрапе очень легко и быстро клепать интерфейсы, все открыто и понятно, и гибкости больше чем в 1С.

(7) "Фактически код переводится в Java и уже затем компилится"
Т.е. ты говоришь, что котлин сам по себе не компилируется?

(8) я бы не называл эти языки обертками
wiki:Список_языков_JVM

Спрашивать про стратегию на непрофильном форуме это топ.

(41) Точнее 1С МП сама является огромным костылем в разработке мобильных приложений.
Но да соглашусь с Вами и перечислим преимущества МП
1. Скорость разработки
2. Не нужно обучать и держать отдельного специалиста по Android
3. Установка на телефоны платформы, дает возможность работать с разными МП и быстро все обновлять конфигурацию и исправлять ошибки.
4. Пока 1С не ужесточит лицензионную политику, находимся в вечном тестировании и все бесплатно ;)

(46)это так и останется в тестировании, коммерческую разработку вести не реально - одна сплошная "дыра":
1. проблемы с построением классического мобильного интерфейса - аццкий изврат.
2. проблемы со стабильностью и изменением поведения при переходе на следующие платформы 1с.
3. исходный код 1с в открытом виде.
4. производительность.
5. сомнительная политика лицензирования, с 100% вероятностью изменения когда "попрет".
НО!
разработка бизнес-приложений ведется ОЧЕНЬ быстро и дешево! поэтому тема жива.

(47) Не в защиту 1С, а в защиту реальной мобильной разработки:
1. Нет классического мобильного интерфейса, есть разные подходы (Activity, fragment и куча вариантов xml разметка или compose это вообще отдельно)
2. Если Вам тяжело отслеживать ошибки мобильной платформы, то я Вас разочарую в чистой разработке с открытым исходным кодом любое изменение номера библиотеки, обновление AGP может приводить к фатальным ошибкам ;) И количество несовместимости на порядок больше. И это Ваши проблемы, Отсюда уровень квалификации выше и отмазаться на то что это не сделали в 1С не получиться.
3. У Андройд своя система работы с depricated и старым кодом грубо говоря собираем на последнем SDK и указываем минимальную старую поддерживающую версию. У 1С монолит с поддержкой версии 4.4 - то есть полный depricated. Код 1С это полное легаси в котором разбирается только 1С ;)
4. С производительностью отдельная тема самого движка 1С. Если хотите надо обсудить отдельно.
5. Сомнительная? Капитализм - содрать сколько можно,а если монополия то это просто замечательно! (Корп лицензии нам в пример)

А в чем "сомнительность" политики лицензирования?
Если ты зарабатал на приложение больше 60 тысяч то платишь 10% от оборота. В остальном случае бесплатно. (стим вон вообще 30% берет с оборота)

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

0) Если разработка вне 1С экосистемы - то Android Studio. Хорошая, годная вещь с совершенно уебским дизайнером UI. Но учитывай особенности java.
Если знаешь Delphi - то Дельфи 12. На порядок более простой редактор UI (дада, та самая разметка через TPanel) и код, близкий к классическим ЯП. Более быстрая отладка и запуск. Можно код крайне быстро отладить на десктоп версии и перенести в мобильную так, что никакой x86 Intel performance эмулятор из Android Studio и рядом не стоял.

(51) понял, спасибо!

(51) а что за язык в делфи 12 используется для работы с мобилками? Раньше там был практически паскаль

React Native + flutter.

(53) pascal

(55) Ненавижу Pascal...

(55) прикольно. надо вспомнить молодость

(56) Бывает

(55) в бесплатной 11 версии заявлена так же возможность писать приложения под MAC, а среды под MAC я не вижу, качается под винду только. Это как так у них получается?

(59) писать под мак != писать на маке
под андроид тоже не на андроид обычно пишут.. а на винде или линуксе

(61) достал уже со своей рекламой

(60) как сказать. Много чего чтоб скомпилить нужен мас. Вот и интересно как пакет собрать под виндой

(51) Я конечно против твоего авторитета в 1С ничего не имею, но вводить людей в заблуждение не стоит.
Но ConstraintLayout это наверное более доработанное и впитавшее в себя все лучшее из философии layout. Более гибкое чем даже ОФ 1С(привет неправильной связке - ломающей всю форму), тоже что всякие разметки в .net и копии их в Delphi ;)
И отлаживать мобилку на десктопе, помогает только когда надо исправить большую ошибку.
(54) Молодым Dartам - доступно и всерьез! Хотя я против единого движка под управлением корпорации.

(60) Если серьезно (писать под мак = писать на маке)
Под IOS тоже пишут не под IOS, а под macOS пишут!!!
Вы что вообще мат часть не изучаете?

(65) зачем изучать если уже знаю
да яблоко пытается всеми силами продавать свои поделки, в т.ч. xcode типа только под macos есть
но лично я юзал хакинтош и виртуалку
что далеко не мак ))

(64) ConstraintLayout только для студенческих поделок подходит и то с натяжкой
На реальных сложных проектах превращается в какой то пипец

А уж эти тучи параметров которые дико неудобно править
Со специфическим синтаксисом и часто глючащая среда

(68) Сначала объяснись зачем (с какой целью) ты влез со своей поделкой сюда?

Какое отношение оно имеет к теме ветки?
Или к обсуждению?

Ты что то хотел пояснить за технологию разработки под мобилы???

Нет, просто нахрена то вставил ссылку на свою рекламную ветку.
Зачем?

(66) ну для процесса программирования хакинтошь=мак. Разрешение экрана пока эпл не проверяет при запуске икскода

(65) да и под ios ты конечно можешь писать на других ОС, только вот собрать и опубликовать должен с мака

(71) Собираю под виндой, публикую тоже, хотя публиковать можно откуда угодно, хоть с телефона.

(27) емнип, с табдоком есть проблема при изменении масштаба?

(0) котлин уже загибается? он же вроде как недавно появился...
1С - наше все, живее всех живых!

(16) <аж поперхнулся>
Это ты после темы на хабре про новичков в делфи решил что норм с делфи такое начинать?

1. пишут на java и kotlin. нужно знать и то, и то, т.к. под капотом у kotlin java
2. чаще всего, наверное, все-таки Room (SQLite), реже встречаю Realm (nosql)
3. гугл, рустор, хуавей

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

(67) ну бред же. как раз ConstraintLayout очень часто выручает там, где кто-то своими грязными руками прошелся и понасоздавал дофига уровней вложенности. С ним часто можно зарефачить всё на один уровень.

(76) "...композ (еще одна веха развития в современном программировании после манифеста реактивности)..."
Да какая это веха. Очередной виток спирали. Когда-то все начиналось с этих функций для гуи.
Разного рода варианты хранения гуи во внешних xml, json, css и т.д. не на пустом месте появился.
Ради интереса сделал пару вещей на flutter. И если это что-то больше чем примерчик с парой виджетов с ютуба то на самом деле получается лютая спагетина из классов, функций, построителей и прочей лапши. В которой через неделю уже теряешься.

(76) спасибо.

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

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

(80) Те люди которые Вам легко объяснят разницу MVC vs MVP vs MVVM в разных модификациях 1С не занимаются ;)
И да реактивный интерфейс предполагает правильное выстраивания схемы отображения в update автоматом, если у тебя произошли изменения в модели... В общем сидим на теплом ламповом 1С...

(80) MVC это довольно старый подход хотя некоторые особенности похожи на композ. а именно Unidirectional data flow, который характерен для композа. однако есть и различия, которые проявляются, если сравнить MVC  и MVVM, который наиболее часто применяется в композе. MVVM в отличие от MVC налагает жесткое ограничение, что ни один из компонентов (Model, Controller) не должен владеть ссылкой на View. Напротив, View слушает поток данных от ViewModel. т.е. для MVC было нормально, что изменения в Model приводили к частичному обновлению состояния View- мутированию. Но не для композа. Собственно если Вы работали с какой-либо версией Rx, то знаете рекомендации по поводу иммутабельности состояний при передаче между операторами в цепочке. композ следует этой же логике.
(81) ну собственно композ и другие декларативные языки- это логичное развитие программирования. для 1С совсем никак не применимо, т.к. она не дошла до предыдущего шага (нужны примитивы для работы с многопоточностью).

(82) Говорят новое это хорошо забытое старое :)
Главный лозунг компоса - никаких больше xml! Все пишете в своем любимом редакторе.
Но к xml и пришли потому что для редактора стало совсем неподъемным эта лапша.
Все примеры о "иммутабельности" отличные только для демонстрашки условных виджетов заказа еды. Не больше.
Вот как пример: какая у вас будет иммутабельная модель для построения экрана расходной накладной?
Поменяли количество в одной из сотни строк, что должно обновиться, весь экран перерисоваться, так как поменялась модель всего документа. Или вы документ расчлените на сотни "моделек" которая будет каждая отвечать за свой кусочек экрана?

Интересные вы тут темы поднимаете...

(16) без VPN не зарегистрировать лицензию, это так, на всякий случай

(85) Опять дискриминация на ровном месте

(84) а если пролучится "пролезть" - еще и выгодные)

(87) Не понимаю, куда пролезть?

(88) в хорошую тему! зайти! вот ты такой зашел, красивый, а тебе еще и денег дали!

(83) "Главный лозунг компоса - никаких больше xml! Все пишете в своем любимом редакторе.
Но к xml и пришли потому что для редактора стало совсем неподъемным эта лапша." - не уверен, что это главный. Ушли от xml по причине развития dsl, который в т.ч. помогает избавиться от лапши. сам гугл заявляет, что код с помощью композа получается более лаконичный, чем на вью.

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

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