@frostyfull

Доброго времени суток дамы и господа)
У меня такой вопрос, в компании, в которой я работаю, стоит задача написать мобильное приложение, но пока еще не решено точно как должно приложение работать.
Либо оно постоянно коннектится к базе 1с, что на мой взгляд не продуктивно, и тогда придется писать на 1с
Либо будет локальная база данных, которая периодически будет обновляться, что более перспективно, и тогда можно будет юзать более продвинутый язык для написания, с которого в последствии можно будет легко скомпилировать для ios

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

0

Pablito

Постановка задачи, достойная любой девочки из HR.
Мы что-то задумали, не факт что это будет, я что-то хочу, как это сделать и на чем?

2

@frostyfull

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

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

0

@Tester64

Ладно, новичок, слушай:
Основной язык андроида - это ява! И только ява!
Иногда пишут вставки на си и си++ и оборачивают в яву. Это для скорости и взломоустойчивости.

Есть готовые "трансляторы" под разные языки. Они либо урезанные либо узкоспециализированные. В основном это игровые движки (например на с#). Но так-же поступил и новый Делфи. Он написал свой транслятор под большинство платформ и компилирует паскаль-текст в код под свой транслятор. Сам не пробовал, но на него (делфи) многие жалуются (и возвращаются на яву).

Ява по идее мультиплатформенная. И может быть запущена и под винду и под линукс и под мак. Но... ява под андроид использует гугл-андроид-апи! Это окошки, кнопочки и работа с ними. Под другие ОС подобного нет!
Насчет SDK! Он один! И действительно подходит под большинство андроидов (разные версии и качества). Есть нюансы, но если написал программу под старичка 2.3, то скорее всего (99%) он запустится и на 4.4.

1С сделала свой транслятор! 8.3 кажется. Но его тоже в руках не держал... и возможностей не знаю.
Еще слышал про "конструктор" от агент-плюс. Но тоже ничего хорошего не скажу. И он как и 1С платный и не дешевый...

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

И еще совет: прежде чем задавать здесь вопросы, узнай у начальства задание в деталях! А не "непохо было бы бы... нашу 1С и на андроиде запустить в автономном режиме и на маке и к военному спутнику подключить... а теперь узнай как все это должно работать и сколько будет стоить..."

2

@forcelain

Для клиенсткой части можете посмотреть на кросс-платформенные SDK. Из наиболее популярных могу отметить PhoneGap, Appcelerator Titanium, Xmarin. Они сгодяться на более-менее простое приложение. Кстати, имейте в виду, что для сборки под ios Вам не обойтись без машины на Mac OS
Со стороны сервера наверняка эффективнее всего написать сервис, который предоставляет данные из 1с по HTTP(S), он же может и вносить изменения в базу. Таким образом у Вас будет унифицированный доступ и Вы не будете зависить от архитектуры клиента.

0

@Tester64

До андроида мечтал заняться ioc. Насколько слышал, можно работать или в эмуляторе, или даже на линуксе...

Это как? Получится же онлайн клиент! От чего хотели избавиться... Иначе вполне можно перебросить терминал на сервер с 1С даже по слабому каналу!

0

@forcelain

Для сборки приложения под ios нужен xcode, который ставится только на Mac OS. Для вышеприведенных кроссплатформенных SDK для сборки под ios тоже нужен xcode. Ну и до кучи, как таковых эмуляторов iPhone/iPad нет, есть симуляторы, которые тоже работают только на Mac OS

0

Pablito

...которая прекрасно работает на виртуальных машинах, на торрентах полно готовых сборок

1

@forcelain

если Вы так говорите, Вы скорее всего даже не пытались её поставить на виртуалку

0

Pablito

Не вводите людей в заблуждение! Все прекрасно работает на виртуальной машине.

1

@frostyfull

да я тоже что-то читал про виртуалки, вроде не должно проблем возникать

0

@NiRamz

Под андроид что то серьезное только на Java. Да, вы можете сэкономить и написать на том же phonegap (врятли правда что то крупное), но потом с поддержкой и фиксами замотаетесь и в итоге придется переписать под каждую платформу отдельно. По поводу сборки проекта ТОЛЬКО из под мака и xcode - заблуждение (у нас написан и работает сервер автоматической сборки, который по каждому коммиту собирает android или же iOs приложение и рассылает в нужные отделы). Запустить из под эмулятора можно. Стандартные эмуляторы девайсов в iOs работают намного лучше андроидных стандартных (если конечно не запускать их на линуксе, тогда примерно одинаково). По поводу кросплатформенности Java - немного не соглашусь, apk исполняются не в JVM, а DVM так что без гемороя запустить обычное джавовское приложение не получится.
Теперь по поводу постановки задачи - постановка, мягко говоря ни к черту. Лучше всего делать между клиентом и базой какую то прослойку (не обязательно веб сервер, можно и в локальной сети), клиент не должен выполнять сложного функционала, следует по максимуму облегчить его работу, тогда в будущем будет проще его дописывать, хотя бы в том случае если поменяется структура данных от сервера.

2

@Tester64

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

Если не секрет, ЗАЧЕМ? Не могу придумать применение? Фантазия забуксовала... Сборка мега-крупных проектов с сотней изменений от нескольких разработчиков? Или наоборот мега мелких - где меняется только дизайн и встроеные базы? Или это для простейших "конструкторов" приложений ("хочу блок A+B+E+H и дизайн №8"?

Последние пару лет отслеживаю эту тенденцию! ПОЧЕМУ? Стереотип или некая не понятная мне логика? Да уже есть 4х ядерные устройства помощнее Пентиум 500(занизил за счет слабости APM-процессоров). А я успешно запускал 1С70 на пентиум 100. Почему клиент обязан работать в онлайне? Лично знаю десяток мест, где даже GSM не ловит... Базы - надежные, памяти хватает, дизайн можно допилить, проца для обрабоок/отчетов должно хватать, батареи тоже все долговечнее...

А мега-шустрое на с/с++. Жаль что его так анти-рекламируют сами гуглы... Я его уже почти оценил! (жаль плохо еще знаю с++ для чего-то сложного)

0

@frostyfull

у меня еще вопрос, если к примеру между сервером и клиентом делать так называемую прослойку, если ее на разных языках писать, не должно конфликтов возникнуть?
Прослойка к примеру на 1с, а приложение на яве?

0

@NiRamz

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

1

@Tester64

Если можно здесь поподробнее!

Задумал некоторые сложные математические классы перевести на с++ с частым вызовом и обратной связью (например 5типальцевый мультитатч и свой формат базы данных типа dbf).
Еще задумал написать полностью свой интерфейс для сильно-графической программы - полная подмена компонент активити своими более... "сложными" аналогами (то что на яве изменить не получилось - пришлось свое писать).

Расчитывал на прирост скорости раза в 2 минимум... Скорость отрисовки, скорость обработки клика (как в игрушках, а не ме-е-едленный клик по стандартной ява-кнопке). Не говоря уж о компактности кода, простоте подключения (в ан-студии ява библиотеки "подключать" приходится) и защищенности от дебага.

Добавлено через 2 часа 5 минут
Винда на подобное никогда не смотрела... поэтому ее программы очень долговечны... До сих пор у меня работает то что написал на тормознутом Вин95. И стимулируют ускорять проги покупкой нового харда. Уже идут акци - минапи19. А это вроде уже 4.х. А это уже не 2.3 и явно мощные! А кому нужны 2 ядра, если их можно использовать лишь для игр? Насколько я знаю ни одна звонилка пока не использовала 2е ядро... Понимаю тяжелые операции по гиганским базам (отчеты, аналитика), но ведь их-же можно сделать и на планшете! пусть дольше. Пусть думает 5 минут в фоне, вместо 5 секунд онлайн... И 4 секунды при подключении - "ускорение через облако". Но я заметил что этого пытаются избежать... и софт морально стареет уже через год-два на новых плашетах, вместо идти впереди харда! И сервера закрываются обесценивая софт. И оффлайн базы никто на устройствах предпочитает не хранить. Хотя я знаю людей, у которых в семье нет компа - только андроид планшеты.

0

@NiRamz

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

По поводу второго момента - не смотрите на флагманы от того же самсунга, не у всех они есть. Про поддежку 2.3 я не говорю, но и при поддержке 3+ андроида выплывают разного рода динозавры.

0

@Tester64

Все равно не понимаю!
Согласен - на нем писать сложнее, больше контролировать (нет сборщика мусора - но это даже лучше/логичнее), тяжелее компоненты (можно упростить своими, как сделало Qt), нет удобного редактора/отладчика (наживное), двойная компиляция (натив + ява-apk).
Но... по идее... скомпилированное компактнее, инсталяция быстрее, скорость выше, совместимость относительно полная. Про взломоустойчивость - вообще молчу...

Насколько я знаю все игровые движки для ускорения ЦЕЛИКОМ делают на нативе! Я ошибаюсь? Если нет, то чем программы хуже? Если начать с написания интерфейса...

Про минусы обычно слышу только нечто невнятное... "не советую", "не стоит", "лучше не делать". От Вас первого услышал намеки на реальные замеры!
"поиграйтесь с профайлингов в ddms, посмотрите на время выполнения и сразу станет все понятно"
Для меня это еще тяжело... Я не линуксоид и на андроиде чуть больше года с нуля (как и на яве). Можете обьяснить результаты?

Пока все еще мечтаю написать на нативе свой программный движок для узкоспециализированных учетных программ. Но все не могу начать, пока не буду уверен что это будет ГАРАНТИРОВАННО не хуже чем на яве... Пока 50 на 50 - мега-круто то что вычитал и опробовал, и невнятные минусы от советников со стажем.

0

@NiRamz

в нативе инициализация идет подольше объектов, дальше может работать скорее.
возьмем к примеру MediaPlayer (он нативный, если не в курсе), есть девайсы, которые виснут и выкидывают ANR просто на строке new MediaPlayer (HTC Flayer повисал в 70% случаях).

откройте DDMS, там есть кнопочка "Start method profiling", жмакаем на нее и начинаем выполнять какие то действия на девайсе, потом опять нажимаем и нам вываливается отчет с полным стеком вызовов по времени работы. Собственно начинаем его анализировать, очень удобная штука особенно при написании сложных списков, да и вообще при работе со вьюхами и анимацией. Можно точно отследить и оптимизировать время работы.

Добавлено через 52 секунды
а если HTC попадал в оставшиеся 30%, то повисал при вызове mp.release();

0

@Tester64

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

Да и медиаплеер во всех средах не всегда надежен! Кривой медиа формат и получаем кучу исключений. У меня даже винамп на некоторых медиа-файлах вылетал. А некоторые gif-ы напрочь убивают ACDS.

Слышал что SQLite написан на нативе!!! И вся ОС построенна на его надежности... Unity3d тоже слышал что на нативе и его игры у меня не зависали...

Добавлено через 2 часа 24 минуты
Совсем забыли об авторе ветки...
Конфликт ОБЯЗАТЕЛЬНО будет! Большинство языков не совместимы! На то и нужны стандарты и собственные API. Вам нужно на разных языках лишь выбрать метод хранения промежуточных данных! Текстовый, база, xml, свой сокет-протокол, универсальны сокет протокол (например MySQL).
Выгружаете данные из 1С, выкладываете их в сеть, скачиваете из сети на андроид, разбираете полученное, выводите юзеру. Получаете от юзера данные, шифруете в некое хранилище, отправляете хранилище в сеть, закачиваете в 1С, разбираете полученное в 1С. Все что между программой юзера и 1С и называют прослойкой! И иногда она намного сложнее программы на андроиде...

0