Comments 35
По мне так Native лучше всего.
Да и если хочешь писать на Android и iOS — лучше потратить время и изучить нативный инструмент. Хоть и не мог долго принять синтаксис Objective-C, со временем стал получать удовольствия от работы с ним.
Да и если хочешь писать на Android и iOS — лучше потратить время и изучить нативный инструмент. Хоть и не мог долго принять синтаксис Objective-C, со временем стал получать удовольствия от работы с ним.
+3
Тогда не будет единой кодовой базы. А это один из главных аргументов в пользу защиты кросс-платформенных инструментов.
И даже если не принимать во внимание то, что у вас потенциально может быть три проекта (под iOS, Android и Windows), они еще и написаны будут на разных языках (Objective-C, Java, C#)
И даже если не принимать во внимание то, что у вас потенциально может быть три проекта (под iOS, Android и Windows), они еще и написаны будут на разных языках (Objective-C, Java, C#)
+1
Единая кодовая база несомненно — круто. Я бы сам от такого не отказался, с учетом того что приходится писать проект на несколько платформ.
Нативные инструменты всегда идут в ногу с обновлением ОС. Поэтому и проще поддерживать под конкретную версию ОС.
Ну и у меня есть несколько вопросов, которые все время заставляют остановится на переход в кросс-платформенности.
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 мегов.
+2
Я не пишу нативный код, так что постараюсь ответить вам в меру своей компетенции
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 МБ. Правда, там почти нет графики
0
1) А от таких вот трансформаций не страдает производительность или скорость сборки? Ну и по мне будет написано очень много кода, чтобы написать локскриновский медиаплеер для Android,iOS и Windows Phone одновременно. Думаю будет куча проверок.
2) Классно, что они стараются оперативно выпускать обновления.
Для фриланса быстро написать 1 приложение на все платформы — это несомненный плюс. Для компаний все таки лучший вариант — это Native.
А так спасибо за ответы.
2) Классно, что они стараются оперативно выпускать обновления.
Для фриланса быстро написать 1 приложение на все платформы — это несомненный плюс. Для компаний все таки лучший вариант — это Native.
А так спасибо за ответы.
+3
500 мегов, потому что Unity в проект выплевывает их core либу (/Libraries/lib-iphone.a если мне память не изменяет), которая в себе содержит все архитектуры, на самом деле линкеру/компилятору в конечном итоге необходима лишь малая часть этой либы чтобы собрать ваш проект. Но согласен, юнити всегда весит существенно больше нативного проекта.
0
Ну я подозревал, что он докидывает кучу своего при преобразование в Objective-C.
Меня просто попросили собрать проект и закинуть в стор. Правда я очень долго проклинал этот проект, так как собирался он уйму времени, и меня от этого дико бомбило.
Мне всегда нравится писать под iOS из-за скорости сборки проекта, в отличии от Gradle у Андроид студии.
Меня просто попросили собрать проект и закинуть в стор. Правда я очень долго проклинал этот проект, так как собирался он уйму времени, и меня от этого дико бомбило.
Мне всегда нравится писать под iOS из-за скорости сборки проекта, в отличии от Gradle у Андроид студии.
0
Что мешает отделить бизнес-логику от представления?
+1
Хочу заметить, что общую кодовую базу можно держать и на C# и не F#.
+1
> А что делает приложение нативным?
Приложение компилируется в стандартный для платформы байт-код, и использует API системы напрямую.
Приложение компилируется в стандартный для платформы байт-код, и использует API системы напрямую.
+9
Именно. В случае линукса — это будут, например, so файлы. А всякие питоны — это уже скрипты. Производительность, очевидно, лучше, когда ты используешь нативные средства. А всякие look&feel — это уже не существенный признак. Так-то я видел оболочки под winXP, которые убирали кнопку пуск, и наоборот оболочки, которые под линуксом имитировали интерфейс винды.
0
На самом деле всё просто до неприличия…
+5
1 Нативное приложение всегда лучше чем кроссплатформенное
2 Объяснять таким образом как указано выше можно только клиенту, специалист всегда знает в чем на самом деле разница и что указанные вами критерии к нативности отношения не имеют.
3 Любом более менее серьезное не нативное приложение при достижении возраста N будет переписано на нативный код под 1 платформу, лучше когда этот возраст 0.
Таким образом явно видно что выше указана просто очередная победа маркетологов над здравым смыслом.
Вот какие тезисы я вынес за время работы в этой сфере.
2 Объяснять таким образом как указано выше можно только клиенту, специалист всегда знает в чем на самом деле разница и что указанные вами критерии к нативности отношения не имеют.
3 Любом более менее серьезное не нативное приложение при достижении возраста N будет переписано на нативный код под 1 платформу, лучше когда этот возраст 0.
Таким образом явно видно что выше указана просто очередная победа маркетологов над здравым смыслом.
Вот какие тезисы я вынес за время работы в этой сфере.
+6
Нативное приложение всегда лучше чем кроссплатформенное
Всё-таки не следует противопоставлять native и cross-platform приложения. Потому что последнее может быть скомпилировано в native код для нескольких требуемых платформ.
Пример: C/C++ приложения (как консольные, так и с GUI), компилируемые из одних и тех же исходников в бинарники для Linux, Windows и Mac OS X.
+2
А что мешает вести мульти платформенную разработку с единой кодовой базой используя MVC архитектуру.
UI/UX компоненты будут нативными. А кодовую базу держать в простом model классе можно даже на java.
github.com/google/j2objc
UI/UX компоненты будут нативными. А кодовую базу держать в простом model классе можно даже на java.
github.com/google/j2objc
0
Если необходимо быстро сделать приложение или приложение простое — кроссплатформенные движки помогут. Как только возникнут ограничения движка, начнутся раздумья над разработкой именно на языке платформы и используя API системы.
Так было решено у нас в компании, приложение было выпущено на базе react-native. Но в последнее время начали поступать предложения и пожелания о том, что охота виджеты как для Andriod, так и для iOS, и охота приложение для Apple Watch, а средствами кроссплатформ это не реализовать. Так что пока сидим и думаем что же делать с такими пожеланиями.
Так было решено у нас в компании, приложение было выпущено на базе react-native. Но в последнее время начали поступать предложения и пожелания о том, что охота виджеты как для Andriod, так и для iOS, и охота приложение для Apple Watch, а средствами кроссплатформ это не реализовать. Так что пока сидим и думаем что же делать с такими пожеланиями.
0
Так делайте нативно, с советом выше.
0
Попробуйте Titanium! У них есть WatchSession; виджетов, конечно, пока на нем делать нельзя, но есть куда работать, например, использовать RemoteViews
0
1. Пишем нативно то, что невозвожно сделать кросплатформенно
2. Подключаем к React Native
3. Profit!
2. Подключаем к React Native
3. Profit!
+1
У каждого инструмента свои задачи и плюсы/минусы, как тут выше упоминали в комментариях. Просто не стоит забывать, что кроссплатформенные приложение будут дороже обходиться в поддержке и развитие. А это важный фактор для компаний.
+1
На одной из конференций, докладчик сказал, что на Phonegap можно быстро запилить приложение и выложить его. А пилить нативное можно потом не торопясь, сколько будет нужно. Хоть лет 5 ;)
0
Чем Титаниум лучше Хамарина?
+1
Вот здесь можно скачать и оценить: http://propertycross.com/frameworks/titanium/titanium.html
Плюс можно глянуть другие технологии, в том числе и xamarin: http://propertycross.com/
Плюс можно глянуть другие технологии, в том числе и xamarin: http://propertycross.com/
0
А в пулл-риквестах лежит код для React Native :)
0
Да простят меня автор перевода и уважаемый Фокке (огромный респект ему за вклад), но не берите Titanium для нового проекта. Очень вас прошу. Поберегите нервы себе, своим коллегам и близким.
Я знаком с Titnium'ом с самых первых версий, на моем счету около десятка проектов и пяток нативных модулей под разные платформы. Я провел очень много времени копаясь в его исходниках, пытаясь понять, почему не работает та или иная фича. И могу с уверенностью заявить, что поект написан плохо. Более того, похоже на то, что никто не собирается что-то с этим делать! Некоторые критические баги висят в трекере годами, а на форумах и stackoverflow кочуют для них костыли, которые иногда срабатывают. Особенно издевательски при этом выглядят письма с опросниками «какую фичу нам впилить? apple watch или что-то другое?». Это, блин, вместо того, чтобы довести до ума базовый функционал.
Про производительность промолчу. Скажу лишь, что активация строки поиска в простом списке на сотню элементов занимала у меня на iPod 5 пару секунд. И проблема была совсем не в биндинге с js: тормозил именно нативный код! Приложил профайлер, показал, что именно тормозит. Тикет закрыли со словами «это не драматически медленно». Пожалуй, это все, что можно сказать про уважение к комьюнити.
Если я вас уже напугал, то подождите, не спешите рачехлять Android Studio и xCode/AppCode :) В чем автор действительно прав, так это в том, что хорошие приложения не обязаны быть нативными.
Попробуйте React Native. Думаю, вы будете удивлены, как был удивлен я :)
Отличная скорость работы, писать код и верстать UI приятно и удобно. А самое главное, что упор сделан на производительность, UX и тестирование! Уже не говоря про правильно выбранные инструменты и образцовую работу с комьюнити. React Native — это то, чем должен был стать титаниум, но не смог. За год после официального релиза они сделали больше, чем титаниум за 7 лет своего существования!
И во главе проекта стоят девелоперы, а не менеджеры. Читаешь их переписку и понимаешь, что ребята действительно хотят сделать хороший инструмент и прикладывают к этому все усилия. А скорость разработки и число «звездочек» на гитхабе прекрасно показывает, что они двигаются в нужном направлении.
И минусов — сторонних библиотек и биндингов пока не сильно много. Но это дело наживное.
Я знаком с Titnium'ом с самых первых версий, на моем счету около десятка проектов и пяток нативных модулей под разные платформы. Я провел очень много времени копаясь в его исходниках, пытаясь понять, почему не работает та или иная фича. И могу с уверенностью заявить, что поект написан плохо. Более того, похоже на то, что никто не собирается что-то с этим делать! Некоторые критические баги висят в трекере годами, а на форумах и stackoverflow кочуют для них костыли, которые иногда срабатывают. Особенно издевательски при этом выглядят письма с опросниками «какую фичу нам впилить? apple watch или что-то другое?». Это, блин, вместо того, чтобы довести до ума базовый функционал.
Про производительность промолчу. Скажу лишь, что активация строки поиска в простом списке на сотню элементов занимала у меня на iPod 5 пару секунд. И проблема была совсем не в биндинге с js: тормозил именно нативный код! Приложил профайлер, показал, что именно тормозит. Тикет закрыли со словами «это не драматически медленно». Пожалуй, это все, что можно сказать про уважение к комьюнити.
Если я вас уже напугал, то подождите, не спешите рачехлять Android Studio и xCode/AppCode :) В чем автор действительно прав, так это в том, что хорошие приложения не обязаны быть нативными.
Попробуйте React Native. Думаю, вы будете удивлены, как был удивлен я :)
Отличная скорость работы, писать код и верстать UI приятно и удобно. А самое главное, что упор сделан на производительность, UX и тестирование! Уже не говоря про правильно выбранные инструменты и образцовую работу с комьюнити. React Native — это то, чем должен был стать титаниум, но не смог. За год после официального релиза они сделали больше, чем титаниум за 7 лет своего существования!
И во главе проекта стоят девелоперы, а не менеджеры. Читаешь их переписку и понимаешь, что ребята действительно хотят сделать хороший инструмент и прикладывают к этому все усилия. А скорость разработки и число «звездочек» на гитхабе прекрасно показывает, что они двигаются в нужном направлении.
И минусов — сторонних библиотек и биндингов пока не сильно много. Но это дело наживное.
+3
Cordova приложения это тоже «не сайты обернутые в приложения». Хотя могут и такими быть. Кордова прекрасна — HTML5/CSS/JS. Все основные платформы. Любой framework — хоть Ionic/Ionic2, хотя Angular, хоть ReacJS, хоть VanillaJS…
Всё хорошо, пока не встречаешь дефрагментацию WebView. И начинаются фиксы и компромиссы. Титаниум не имеет такой проблемы?
Всё хорошо, пока не встречаешь дефрагментацию WebView. И начинаются фиксы и компромиссы. Титаниум не имеет такой проблемы?
0
Пишу на Титаниуме третий год, конечно случались проколы, но в целом очень доволен технологией.
Весь стек проекта на 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
+1
Правильно писать «Titanium != HTML», а не «Titanium !== HTML».
0
Sign up to leave a comment.
Articles
Change theme settings
Что такое «Нативное приложение»?