Comments 35
По мне так Native лучше всего.
Да и если хочешь писать на Android и iOS — лучше потратить время и изучить нативный инструмент. Хоть и не мог долго принять синтаксис Objective-C, со временем стал получать удовольствия от работы с ним.
Да и если хочешь писать на Android и iOS — лучше потратить время и изучить нативный инструмент. Хоть и не мог долго принять синтаксис Objective-C, со временем стал получать удовольствия от работы с ним.
Тогда не будет единой кодовой базы. А это один из главных аргументов в пользу защиты кросс-платформенных инструментов.
И даже если не принимать во внимание то, что у вас потенциально может быть три проекта (под iOS, Android и Windows), они еще и написаны будут на разных языках (Objective-C, Java, C#)
И даже если не принимать во внимание то, что у вас потенциально может быть три проекта (под iOS, Android и Windows), они еще и написаны будут на разных языках (Objective-C, Java, C#)
Единая кодовая база несомненно — круто. Я бы сам от такого не отказался, с учетом того что приходится писать проект на несколько платформ.
Нативные инструменты всегда идут в ногу с обновлением ОС. Поэтому и проще поддерживать под конкретную версию ОС.
Ну и у меня есть несколько вопросов, которые все время заставляют остановится на переход в кросс-платформенности.
1) Как реализуется поддержка нативного АПИ?(Например реализация MediaController на локскрине. Так как в андроиле >=4.0 и <=5.0 разное апи для реализации).
2) Есть ли например поддержка для андроида — «Requesting Permissions at Run Time»? Я понимаю что андроид 6 не так быстро распространяется, но все таки добавили поддержку данной фичи?
Просто я скептически отношусь, после того как 1 разраб пишущий на Unity Кросс-Платформенные приложения на заказ, скинул исходник простого приложения на IOS — исходники которого на Objective-C весили 500 мегов.
Хотя изначально написанное на нативе — исходники весили бы не более 30-40 мегов.
Нативные инструменты всегда идут в ногу с обновлением ОС. Поэтому и проще поддерживать под конкретную версию ОС.
Ну и у меня есть несколько вопросов, которые все время заставляют остановится на переход в кросс-платформенности.
1) Как реализуется поддержка нативного АПИ?(Например реализация MediaController на локскрине. Так как в андроиле >=4.0 и <=5.0 разное апи для реализации).
2) Есть ли например поддержка для андроида — «Requesting Permissions at Run Time»? Я понимаю что андроид 6 не так быстро распространяется, но все таки добавили поддержку данной фичи?
Просто я скептически отношусь, после того как 1 разраб пишущий на Unity Кросс-Платформенные приложения на заказ, скинул исходник простого приложения на IOS — исходники которого на Objective-C весили 500 мегов.
Хотя изначально написанное на нативе — исходники весили бы не более 30-40 мегов.
Я не пишу нативный код, так что постараюсь ответить вам в меру своей компетенции
1) Через Kroll. Kroll — это написанное на C++ микроядро для запуска модулей. Заявляют, что с его помощью можно "… передать JavaScript объект в функцию на Python". Отвечая на вторую часть вопроса — при создании окна ему можно передать флаги, которые определяет WindowManager.LayoutParams (в частности, FLAG_SHOW_WHEN_LOCKED). Так что в конечном счете все зависит от самого разработчика.
2) Есть, еще с версии 5.1.0
Исходники простого проекта под андроид вот прямо сейчас у меня весят 53 МБ. Правда, там почти нет графики
1) Через Kroll. Kroll — это написанное на C++ микроядро для запуска модулей. Заявляют, что с его помощью можно "… передать JavaScript объект в функцию на Python". Отвечая на вторую часть вопроса — при создании окна ему можно передать флаги, которые определяет WindowManager.LayoutParams (в частности, FLAG_SHOW_WHEN_LOCKED). Так что в конечном счете все зависит от самого разработчика.
2) Есть, еще с версии 5.1.0
Исходники простого проекта под андроид вот прямо сейчас у меня весят 53 МБ. Правда, там почти нет графики
1) А от таких вот трансформаций не страдает производительность или скорость сборки? Ну и по мне будет написано очень много кода, чтобы написать локскриновский медиаплеер для Android,iOS и Windows Phone одновременно. Думаю будет куча проверок.
2) Классно, что они стараются оперативно выпускать обновления.
Для фриланса быстро написать 1 приложение на все платформы — это несомненный плюс. Для компаний все таки лучший вариант — это Native.
А так спасибо за ответы.
2) Классно, что они стараются оперативно выпускать обновления.
Для фриланса быстро написать 1 приложение на все платформы — это несомненный плюс. Для компаний все таки лучший вариант — это Native.
А так спасибо за ответы.
500 мегов, потому что Unity в проект выплевывает их core либу (/Libraries/lib-iphone.a если мне память не изменяет), которая в себе содержит все архитектуры, на самом деле линкеру/компилятору в конечном итоге необходима лишь малая часть этой либы чтобы собрать ваш проект. Но согласен, юнити всегда весит существенно больше нативного проекта.
Ну я подозревал, что он докидывает кучу своего при преобразование в Objective-C.
Меня просто попросили собрать проект и закинуть в стор. Правда я очень долго проклинал этот проект, так как собирался он уйму времени, и меня от этого дико бомбило.
Мне всегда нравится писать под iOS из-за скорости сборки проекта, в отличии от Gradle у Андроид студии.
Меня просто попросили собрать проект и закинуть в стор. Правда я очень долго проклинал этот проект, так как собирался он уйму времени, и меня от этого дико бомбило.
Мне всегда нравится писать под iOS из-за скорости сборки проекта, в отличии от Gradle у Андроид студии.
Что мешает отделить бизнес-логику от представления?
Хочу заметить, что общую кодовую базу можно держать и на C# и не F#.
> А что делает приложение нативным?
Приложение компилируется в стандартный для платформы байт-код, и использует API системы напрямую.
Приложение компилируется в стандартный для платформы байт-код, и использует API системы напрямую.
Именно. В случае линукса — это будут, например, so файлы. А всякие питоны — это уже скрипты. Производительность, очевидно, лучше, когда ты используешь нативные средства. А всякие look&feel — это уже не существенный признак. Так-то я видел оболочки под winXP, которые убирали кнопку пуск, и наоборот оболочки, которые под линуксом имитировали интерфейс винды.
На самом деле всё просто до неприличия…
1 Нативное приложение всегда лучше чем кроссплатформенное
2 Объяснять таким образом как указано выше можно только клиенту, специалист всегда знает в чем на самом деле разница и что указанные вами критерии к нативности отношения не имеют.
3 Любом более менее серьезное не нативное приложение при достижении возраста N будет переписано на нативный код под 1 платформу, лучше когда этот возраст 0.
Таким образом явно видно что выше указана просто очередная победа маркетологов над здравым смыслом.
Вот какие тезисы я вынес за время работы в этой сфере.
2 Объяснять таким образом как указано выше можно только клиенту, специалист всегда знает в чем на самом деле разница и что указанные вами критерии к нативности отношения не имеют.
3 Любом более менее серьезное не нативное приложение при достижении возраста N будет переписано на нативный код под 1 платформу, лучше когда этот возраст 0.
Таким образом явно видно что выше указана просто очередная победа маркетологов над здравым смыслом.
Вот какие тезисы я вынес за время работы в этой сфере.
Нативное приложение всегда лучше чем кроссплатформенное
Всё-таки не следует противопоставлять native и cross-platform приложения. Потому что последнее может быть скомпилировано в native код для нескольких требуемых платформ.
Пример: C/C++ приложения (как консольные, так и с GUI), компилируемые из одних и тех же исходников в бинарники для Linux, Windows и Mac OS X.
А что мешает вести мульти платформенную разработку с единой кодовой базой используя MVC архитектуру.
UI/UX компоненты будут нативными. А кодовую базу держать в простом model классе можно даже на java.
github.com/google/j2objc
UI/UX компоненты будут нативными. А кодовую базу держать в простом model классе можно даже на java.
github.com/google/j2objc
Если необходимо быстро сделать приложение или приложение простое — кроссплатформенные движки помогут. Как только возникнут ограничения движка, начнутся раздумья над разработкой именно на языке платформы и используя API системы.
Так было решено у нас в компании, приложение было выпущено на базе react-native. Но в последнее время начали поступать предложения и пожелания о том, что охота виджеты как для Andriod, так и для iOS, и охота приложение для Apple Watch, а средствами кроссплатформ это не реализовать. Так что пока сидим и думаем что же делать с такими пожеланиями.
Так было решено у нас в компании, приложение было выпущено на базе react-native. Но в последнее время начали поступать предложения и пожелания о том, что охота виджеты как для Andriod, так и для iOS, и охота приложение для Apple Watch, а средствами кроссплатформ это не реализовать. Так что пока сидим и думаем что же делать с такими пожеланиями.
Так делайте нативно, с советом выше.
Попробуйте Titanium! У них есть WatchSession; виджетов, конечно, пока на нем делать нельзя, но есть куда работать, например, использовать RemoteViews
У каждого инструмента свои задачи и плюсы/минусы, как тут выше упоминали в комментариях. Просто не стоит забывать, что кроссплатформенные приложение будут дороже обходиться в поддержке и развитие. А это важный фактор для компаний.
Глянул опрос, на который ссылается автор. Это гениально — опрос из 45 человек в твиттере, посвященному новостям о Titanium'е. Я думаю, если провести опрос среди людей, которые пишут на «стандартном» для платформы языке со стандартными API, то результат будет очень другим.
На одной из конференций, докладчик сказал, что на Phonegap можно быстро запилить приложение и выложить его. А пилить нативное можно потом не торопясь, сколько будет нужно. Хоть лет 5 ;)
Чем Титаниум лучше Хамарина?
Вот здесь можно скачать и оценить: http://propertycross.com/frameworks/titanium/titanium.html
Плюс можно глянуть другие технологии, в том числе и xamarin: http://propertycross.com/
Плюс можно глянуть другие технологии, в том числе и xamarin: http://propertycross.com/
А в пулл-риквестах лежит код для React Native :)
Cordova приложения это тоже «не сайты обернутые в приложения». Хотя могут и такими быть. Кордова прекрасна — HTML5/CSS/JS. Все основные платформы. Любой framework — хоть Ionic/Ionic2, хотя Angular, хоть ReacJS, хоть VanillaJS…
Всё хорошо, пока не встречаешь дефрагментацию WebView. И начинаются фиксы и компромиссы. Титаниум не имеет такой проблемы?
Всё хорошо, пока не встречаешь дефрагментацию WebView. И начинаются фиксы и компромиссы. Титаниум не имеет такой проблемы?
Пишу на Титаниуме третий год, конечно случались проколы, но в целом очень доволен технологией.
Весь стек проекта на CoffeeScript + Jade. Помимо Appcelerator на мобилке, пользуюсь AngularJS на сайте и NodeJS на бекенде.
Тот случай, когда один разработчик может потянуть весь проект целиком.
— JavaScript бриджи действительно работают медленнее native, иногда приходится хитрить или отказываться от чего-нибудь (в моем случае чаще всего жертвую действиями/анимациями завязанными на listener-ы, аля перетащить View пальцем)
+ Верстать экраны на их Alloy фреймворке мне лично гораздо удобнее и быстрее чем html.
+ Предоставляют из коробки, как часть платформы, облачный сервис. Мне было очень удобно, т.к. сначала не писал своего бекенда, а фокусировался на приложении.
+ Ничто не мешает вам засунуть ваше html приложение в веб-вью на Титаниуме, получите тот же Phonegap, только уровень доступа будет повыше. У меня был такой «webview» компонент — лента событий, написанный на Angular. Пользоваться можно, но все таки не native. Потом избавился от него, переписал на TableView.
+ Так же Титаниум расширяется модулями. Мне кажется, это нормальное стратегическое решение — написать приложение в Appcelerator Titanium, а потом растаскивать по native модулям медленные части, сохраняя главную логику в JavaScript.
+ Так же рекомендую поглядеть на Hyperloop (бета).
Я еще не пользовался, но надеюсь эта разработка поможет с ботлнеками, т.к. дает прямой доступ к нейтив API из JavaScript
Пишете на JavaScript что-то типа такого:
var UIView = require('UIKit/UIView'),
UIColor = require('UIKit/UIColor');
var view = new UIView();
view.backgroundColor = UIColor.redColor();
view.addSubview(label);
Примеры: github
факидоки: iOS, Android
Весь стек проекта на CoffeeScript + Jade. Помимо Appcelerator на мобилке, пользуюсь AngularJS на сайте и NodeJS на бекенде.
Тот случай, когда один разработчик может потянуть весь проект целиком.
— JavaScript бриджи действительно работают медленнее native, иногда приходится хитрить или отказываться от чего-нибудь (в моем случае чаще всего жертвую действиями/анимациями завязанными на listener-ы, аля перетащить View пальцем)
+ Верстать экраны на их Alloy фреймворке мне лично гораздо удобнее и быстрее чем html.
+ Предоставляют из коробки, как часть платформы, облачный сервис. Мне было очень удобно, т.к. сначала не писал своего бекенда, а фокусировался на приложении.
+ Ничто не мешает вам засунуть ваше html приложение в веб-вью на Титаниуме, получите тот же Phonegap, только уровень доступа будет повыше. У меня был такой «webview» компонент — лента событий, написанный на Angular. Пользоваться можно, но все таки не native. Потом избавился от него, переписал на TableView.
+ Так же Титаниум расширяется модулями. Мне кажется, это нормальное стратегическое решение — написать приложение в Appcelerator Titanium, а потом растаскивать по native модулям медленные части, сохраняя главную логику в JavaScript.
+ Так же рекомендую поглядеть на Hyperloop (бета).
Я еще не пользовался, но надеюсь эта разработка поможет с ботлнеками, т.к. дает прямой доступ к нейтив API из JavaScript
Пишете на JavaScript что-то типа такого:
var UIView = require('UIKit/UIView'),
UIColor = require('UIKit/UIColor');
var view = new UIView();
view.backgroundColor = UIColor.redColor();
view.addSubview(label);
Примеры: github
факидоки: iOS, Android
Правильно писать «Titanium != HTML», а не «Titanium !== HTML».
Sign up to leave a comment.
Что такое «Нативное приложение»?