Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
(обратите внимание на почти все отличные приложения под iOS).
Тут скорее дело в том как приложение попадает в App Store
Тут скорее дело в том как приложение попадает в App Store
Интересный взгляд. Не скажу насчёт ios, но после мобильной винды (и на cf.net и, особенно, на api на плюсах), palmos и j2me мне андроид показался исключительно, прямо на редкость продуманной и элегантной системой в смысле api. Особенно много всего сделано для упрощения создания интерфейсов. После visual studio + cf.net — прямо бальзам на душу.
В частности, для меня, как для никудышнего дизайнера важно, что на андроиде я могу, не будучи художником, без своих картинок, сделать красивый интерфейс. На винде этого не получилось =)
В частности, для меня, как для никудышнего дизайнера важно, что на андроиде я могу, не будучи художником, без своих картинок, сделать красивый интерфейс. На винде этого не получилось =)
Да после winmo почти все как бальзам на душу, от WP7 API я просто в восторге, и бесконечно рад, что они забили на обратную совместимость и сделали все с нуля.
Позволю себе не согласиться. По поводу API — пока читаешь документацию, все кажется очень продуманным. Как только переходишь к практике, оказывается, что что-то задокументировано неправильно, что-то не упомянуто в документации совсем, а работает далеко не очевидным образом, какие-то элементарные функции в API отсутствуют напрочь. По всем пунктам готов привести конкретные примеры.
По дизайну — простенькие вещи делаются относительно легко, это да. Как только нужно что-то немножко не очень стандартное — начинаются чудеса. И опять же, плохая документация, кривоватый API и т.п. дают о себе знать. Например, сможете навскидку сказать, как писать правильно в андроиде 2.1: layout_width=«match_parent» или layout_width=«fill_parent»? И какая разница между этими двумя и layout_width=«0dp»? Я это выяснял либо по форумам, либо методом тыка. И в некоторых случаях отличия весьма заметны.
Про iOS ничего не могу сказать, но андроидный API (по крайней мере, 2.х) производит впечатление очень сырого и непродуманного.
По дизайну — простенькие вещи делаются относительно легко, это да. Как только нужно что-то немножко не очень стандартное — начинаются чудеса. И опять же, плохая документация, кривоватый API и т.п. дают о себе знать. Например, сможете навскидку сказать, как писать правильно в андроиде 2.1: layout_width=«match_parent» или layout_width=«fill_parent»? И какая разница между этими двумя и layout_width=«0dp»? Я это выяснял либо по форумам, либо методом тыка. И в некоторых случаях отличия весьма заметны.
Про iOS ничего не могу сказать, но андроидный API (по крайней мере, 2.х) производит впечатление очень сырого и непродуманного.
Раз тут переводят посты, то я переведу комменты:
Paul Robins: «Ты программировал всего несколько дней и думаешь, что можешь авторитетно о чем-то заявлять? Мне кажется правдой, что говорят о разработчиках под iOS.»
Paul Robins: «Ты программировал всего несколько дней и думаешь, что можешь авторитетно о чем-то заявлять? Мне кажется правдой, что говорят о разработчиках под iOS.»
Сняли с языка.
Кстати, если интересны каменты, то основной замес на хакерньюсах: news.ycombinator.com/item?id=2825164
ну глупый же комментарий. Автор говорит о сложности входа, и да как новичок он может авторитетно заявлять об этом. Вполне возможно, что разобравшись/научившись разработка станет намного проще и может быть даже удобней ios, но именно этап обучения на android сложней. И я подпишусь под каждым его словом.
Сложность входа — это как раз плюс. Однако даже такая «лернинг курве» не обеспечивает отсуствия тысяч хелловордов в маркете! Всех на ассемблер или расстрелять!
в какой то степени да, но для платформы ни хрена в этом хорошего нет. Сложность входа в совокупности с помойкой-маркетом только прибивает всякий интерес у разработчиков. Сейчас большинство приложений пишутся в первую очередь для ios, потом для android. И когда я сравниваю статистику аппстора с маркетом я понимаю, что со временем разрыв будет только увеличиваться. Так как нет никакого смысла затрачивать больше усилий получая меньший результат.
Что значит прибивает интерес у разработчиков? Интерес в чём?
… Сидел-сидел абстрактный разработчик в вакууме, ковырял в носу, думал чем бы ещё заняться… А вот, займусь андроидом, ага. Заодно и яву выучу. Сунулся, а там ява какая-то непонятная, шаблоны везде используются вместо привычного спагетти-кода, знать надо кучу всего… Не… Пропал интерес у разработчика и вернулся разработчик дальше ваять свои хоумпейджи на пхп. Всё плохо, разработчика потеряли… :)
По-моему, вы как-то не правильно оцениваете причину по которой разработчики пишут под андроид (да и любую другую платформу).
… Сидел-сидел абстрактный разработчик в вакууме, ковырял в носу, думал чем бы ещё заняться… А вот, займусь андроидом, ага. Заодно и яву выучу. Сунулся, а там ява какая-то непонятная, шаблоны везде используются вместо привычного спагетти-кода, знать надо кучу всего… Не… Пропал интерес у разработчика и вернулся разработчик дальше ваять свои хоумпейджи на пхп. Всё плохо, разработчика потеряли… :)
По-моему, вы как-то не правильно оцениваете причину по которой разработчики пишут под андроид (да и любую другую платформу).
Интерес бывает не только у абстрактного кодера в вакууме, а и руководителей студий, и у заказчиков приложений. И именно они определяют, что будет делаться в первую очередь. А в данный момент мы имеем следующее:
iOS — довольно легкий вход для разработчика, белее быстрая разработка, прекрасный aпптор
Android — сложнее обучаемость, более сложный и долгий цикл разработки, что соответственно влияет на стоимость, а на выходи пшик из за паршивости маркета.
в данный момент у меня есть прекрасная возможность сравнить эти 2 рынка — одинаковое приложение для планшетов разработанное клиенту с большой аудиторией в России, полное отсутствие какой либо маркетинговой поддержки, так вот получилось, что клиент не проявляет никакого интереса к рекламе и даже сообщить своим пользователям о том что вышли приложения не потрудился. Но это только добавляет чистоты эксперименту, т.е. продвижение происходит только за счет механизмов магазинов.
Итак цифры за несколько дней — AppStore — 12000, Market — 20
Да, пока приложения только для айпада и андройд планшетов и тут у ios преимущество в кол-ве. Через неделю мы опубликуем для всех девайсов, тогда будет возможность сравнить и телефоны, но что то я сомневаюсь, что картина изменится.
И вот поставьте себя на место абстрактного заказчика в вакууме, который видит такую разницу при равных затратах. Или разработчика который на android затрачивает больше ресурсов.
Да андройд хорош, да перспективен, но к сожалению я вынужден сначала сосредоточится на ios, а потом уже на android, а иногда и вовсе от него отказываться :(
iOS — довольно легкий вход для разработчика, белее быстрая разработка, прекрасный aпптор
Android — сложнее обучаемость, более сложный и долгий цикл разработки, что соответственно влияет на стоимость, а на выходи пшик из за паршивости маркета.
в данный момент у меня есть прекрасная возможность сравнить эти 2 рынка — одинаковое приложение для планшетов разработанное клиенту с большой аудиторией в России, полное отсутствие какой либо маркетинговой поддержки, так вот получилось, что клиент не проявляет никакого интереса к рекламе и даже сообщить своим пользователям о том что вышли приложения не потрудился. Но это только добавляет чистоты эксперименту, т.е. продвижение происходит только за счет механизмов магазинов.
Итак цифры за несколько дней — AppStore — 12000, Market — 20
Да, пока приложения только для айпада и андройд планшетов и тут у ios преимущество в кол-ве. Через неделю мы опубликуем для всех девайсов, тогда будет возможность сравнить и телефоны, но что то я сомневаюсь, что картина изменится.
И вот поставьте себя на место абстрактного заказчика в вакууме, который видит такую разницу при равных затратах. Или разработчика который на android затрачивает больше ресурсов.
Да андройд хорош, да перспективен, но к сожалению я вынужден сначала сосредоточится на ios, а потом уже на android, а иногда и вовсе от него отказываться :(
>приложение для планшетов разработанное клиенту с большой аудиторией в России
Если честно, мне удивительно слышать о наличии большой аудитории владельцев планшетов в России :). Но, может я и правда здесь сильно не в курсе. Да и андроид-планшеты — это же пока штука настолько сильно странная, что говорить о рынке как этих планшетов, так и приложений для них, несколько преждевременно, нет? Впрочем, темы это касается весьма опосредованно.
>Или разработчика который на android затрачивает больше ресурсов.
Для меня это пока не очевидно. Вспоминаю себя многолетней давности — переход на яву с перла и сей тоже был болезненный :). А сейчас кто б меня загнал назад под си (даже объектное). И на сколько бы я больше ресурсов при этом тратил… Наверное, всё или почти всё зависит от направления перехода.
>но к сожалению я вынужден сначала сосредоточится на ios, а потом уже на android
Угу. Но большинство ваших причин не относятся к решению разработчика. Я на это и намекал. А, да, под разработчиком я понимал конкретного исполнителя. Если под разработчиком понимать фирму-разработчика ПО, то согласен, конечно. Но причины ведь всё-равно не в архитектуре системы, а в основном маркетинговые.
Если честно, мне удивительно слышать о наличии большой аудитории владельцев планшетов в России :). Но, может я и правда здесь сильно не в курсе. Да и андроид-планшеты — это же пока штука настолько сильно странная, что говорить о рынке как этих планшетов, так и приложений для них, несколько преждевременно, нет? Впрочем, темы это касается весьма опосредованно.
>Или разработчика который на android затрачивает больше ресурсов.
Для меня это пока не очевидно. Вспоминаю себя многолетней давности — переход на яву с перла и сей тоже был болезненный :). А сейчас кто б меня загнал назад под си (даже объектное). И на сколько бы я больше ресурсов при этом тратил… Наверное, всё или почти всё зависит от направления перехода.
>но к сожалению я вынужден сначала сосредоточится на ios, а потом уже на android
Угу. Но большинство ваших причин не относятся к решению разработчика. Я на это и намекал. А, да, под разработчиком я понимал конкретного исполнителя. Если под разработчиком понимать фирму-разработчика ПО, то согласен, конечно. Но причины ведь всё-равно не в архитектуре системы, а в основном маркетинговые.
что-то не очень это плюс, если сравнивать содержимое эпп сторов обоих платформ.
первые впечатления часто обманчивы.
вообще интересно бы было посмотреть голосовалку от разработчиков, которые знают обе платформы, на чем они предпочитают писать.
вообще интересно бы было посмотреть голосовалку от разработчиков, которые знают обе платформы, на чем они предпочитают писать.
>>этом требуют намного меньше усилий со стороны разработчика
Это все из-за фрагментации, разработчики под iOS на 100% уверены на каком устройстве будут работать их приложение, и что это устройство по начинке одно и тоже, а Android система, которое ставится на абсолютно разные аппараты, поэтому и больше возни с графикой (хотя же те же картинки надо делать в 3-х размерах) и кодом.
Сам под iOS не писал, и с явой не особо был знаком до начала программирования на Андроид, но быстро разбираюсь во всем, ничего сложного нет.
Это все из-за фрагментации, разработчики под iOS на 100% уверены на каком устройстве будут работать их приложение, и что это устройство по начинке одно и тоже, а Android система, которое ставится на абсолютно разные аппараты, поэтому и больше возни с графикой (хотя же те же картинки надо делать в 3-х размерах) и кодом.
Сам под iOS не писал, и с явой не особо был знаком до начала программирования на Андроид, но быстро разбираюсь во всем, ничего сложного нет.
А кроме этого буржуи ещё и балованные сильно, у них образование совсем не такое, как у нас. С одной стороны, у них вроде бы оно более системное, с другой, почему-то часто отбивает способность к нестандартным решениям.
Проблема фрагментации сильно раздута. Она влияет далеко не на все типы приложений. Игры под ударом, да. А вот, например, клиент для какого-нибудь твиттера ни о какой фрагментации никогда и не узнает.
Сложностей хватает, как впрочем и в других платформах.
для того что бы сделтаь асинхронный вызов надо всеголишь отнаследоваться от AsyncTask и сделать все что надо в doInBackground.
настчет доков — спорный вопрос. в java почти все понятно по имени класса и его методам.
например обычная замена в строке:
java — метод называетя replace
ios — stringByReplacingOccurrencesOfString
конечтно тут без доков никуда!
я кодил на ios как-то несколько дней. после Java там все запутаней как по мне.
тут ты знаешь точно, что надо передеать такой-то интерфест туда-то. и ты должен реализовать такой набор методов.
а в iOS ты выискиваеш в доках какой метод должне быть у тебя в классе, что бы его передать как делегат куда-то. я раз опечатался в названии метода — долго искал ошибку. ведь эта штука код скомпилила и сказала что все ок.
настчет доков — спорный вопрос. в java почти все понятно по имени класса и его методам.
например обычная замена в строке:
java — метод называетя replace
ios — stringByReplacingOccurrencesOfString
конечтно тут без доков никуда!
я кодил на ios как-то несколько дней. после Java там все запутаней как по мне.
тут ты знаешь точно, что надо передеать такой-то интерфест туда-то. и ты должен реализовать такой набор методов.
а в iOS ты выискиваеш в доках какой метод должне быть у тебя в классе, что бы его передать как делегат куда-то. я раз опечатался в названии метода — долго искал ошибку. ведь эта штука код скомпилила и сказала что все ок.
Все правильно в iOS с именованием. у NSMutableString есть метод replaceOccurrencesOfString:withString:options:range: то есть по replace и автодополнению он находится на ура.
NSString — неизменяемый, поэтому у него метод называется stringBy… потому что он создает и возвращает новую строку.
NSString — неизменяемый, поэтому у него метод называется stringBy… потому что он создает и возвращает новую строку.
в java String тоже не изменяемвый поэтому replace возвращает строку.
Да и в java названо плохо. Там неочевидно, что создается новый объект.
Насколько я помню, на одном очень популярном лет 5 назад java-форуме каждую неделю прибегал кто-нибудь и спрашивал, почему код:
так адово тормозит?
Насколько я помню, на одном очень популярном лет 5 назад java-форуме каждую неделю прибегал кто-нибудь и спрашивал, почему код:
String s = "";
for (int i=0; i<1000000; i++) {
s+="hello";
}
так адово тормозит?
А Андроид-то тут при чем? В любом руководстве по Андроиду указано, что вы изначально должны знать Java.
Пять лет назад это тормозило, а сейчас — нет. Сейчас компилятор такое в StringBuilder оборачивает.
ну если обезьяне дать гранату то тоже ничего хорошего не получится
для этого люди и учаться и доки читают
для этого люди и учаться и доки читают
Мухаха! В джаве, говорите, все понятно по имени класса? Но мы-то не про джаву, а про андроид. Так что вопрос на засыпку: есть BluetoothDevice.ACTION_ACL_CONNECTED для синезубой гарнитуры и Intent.ACTION_HEADSET_PLUG для проводной. Как по названию определить, что первый работает через манифест, а второй — нет? И почему оно сделано именно так?
Плюсую, документация на developer.android.com вполне себе качественная и много примеров готовых приложений разных типов.
+ настчет закрытия приложения — раздутая проблема.
ты просто должен понимать что как и точек входа в программу так и точек выхода может быть много.
да, немного сложнее, но зато есть intents :)
ты просто должен понимать что как и точек входа в программу так и точек выхода может быть много.
да, немного сложнее, но зато есть intents :)
У меня есть достаточно приличный опыт в разработке под обе платформы. Мне iOS «изнутри» нравится гораздо, несоизмеримо больше чем Android. В Apple работают очень грамотные архитекторы — простое и логичное в освоении API оказыается на практике очень мощным, позволяя создать почти все что угодно. Это касается работы во всех направлениях — звук, графика, интерфейс пользователя, сетевые коммуникации… Также без преувеличения могу сказать — у iOS лучшая документация, с которой я сталкивался. На любую задачу у них обязательно найдется огромная статья, с рисунками, ссылками, подробнейшим описанием что и как работает. Это — настоящий рай для разработчика :)
Отдельно стоит упомянуть Interface Builder и инструменты для анализа кода. Особенно понравился Open GL ES Analysis — после запуска приложения под ним он стрелочкой показал в код и выдал на литературном английском подробный совет, как этот участок улучшить :)
У Android'a же все это находится в каком-то зачаточном состоянии, а ту надстройку, которая позволяет редактировать xml-ки с описанием GUI даже назвать редактором интерфейса язык не поворачивается.
Моя бы воля — писал бы только под iOS. Но, законы рынка диктуют свои условия :)
P.S. Надеюсь, ничьих чувств не оскорбил.
Отдельно стоит упомянуть Interface Builder и инструменты для анализа кода. Особенно понравился Open GL ES Analysis — после запуска приложения под ним он стрелочкой показал в код и выдал на литературном английском подробный совет, как этот участок улучшить :)
У Android'a же все это находится в каком-то зачаточном состоянии, а ту надстройку, которая позволяет редактировать xml-ки с описанием GUI даже назвать редактором интерфейса язык не поворачивается.
Моя бы воля — писал бы только под iOS. Но, законы рынка диктуют свои условия :)
P.S. Надеюсь, ничьих чувств не оскорбил.
да Interface Builder — очень крутая штука[сарказм] надо потягать за линнии что бы забиндить компоненты.
GUI редактора для UI нет в андроиде. пишешь XML и все ок.
т.к. интерфес резиновый то нет надобности и в GUI редакторе.
описываешь layout-ы и компоненты в них
GUI редактора для UI нет в андроиде. пишешь XML и все ок.
т.к. интерфес резиновый то нет надобности и в GUI редакторе.
описываешь layout-ы и компоненты в них
А что плохого в «тягании за линии», если не секрет? Почему [сарказм]-то?
очевидно же, что это не тру программинг. Настоящий программист, должен все писать руками, вычисляя в голове все размеры и подбирая значения цветов. Крайне желательно это делать в блокноте! и что бы никаких подсветки, автокомплита и боже упаси «линий»
Сарказм лишний. Если редактор делает это хорошо и удобно, и не надо за ним поправлять код, то это же прекрасно!
Кстати, интересно, чем руководствуются люди, выкашивая в иосовых проектах ксибки и создавая то же самое с нуля?
Очевидно, это люди, которым с клавиатуры редактировать интерфейс проще, нежели мышой. Мне, например, проще. По крайней мере, я точно знаю, что с клавиатуры я выставлю в точности те значения, которые хочу, а не на пиксель меньше или больше.
С последним обновлением есть, через Eclipse. Но, как обычно, вопрос качества генерируемого кода. Однако факт в том, что сейчас там можно мышкой таскать компоненты, менять их размеры, привязывать к разным участкам родителя или окна и многое другое.
кстати почему в Java абсолютно все Interface Builder'ы генерируют код, а не какой-то бинарный/текстовый формат для файлов интерфейсов?
Давайте сначала уточним: Java — язык программирования (в данном случае), Interface Builder — программа от Apple для рисования (хотя это больше, чем рисование) интерфейса для OS X и iOS. В чём заключался вопрос?
Что для OS X/iOS файл интерфейса (*.nib) — бинарный xml, что для Андроида файл интерфейса — чистый xml (при упаковке в приложение текстовый xml тоже пакуется в бинарный, с возмжностью обратной распаковки). Кто у вас там код-то генерирует?
Что для OS X/iOS файл интерфейса (*.nib) — бинарный xml, что для Андроида файл интерфейса — чистый xml (при упаковке в приложение текстовый xml тоже пакуется в бинарный, с возмжностью обратной распаковки). Кто у вас там код-то генерирует?
Я имел ввиду, почему в Java (не Android) IDE применяется подход генерирования кода по интерфейсам, который обычно получается довольно страшный с кучей названий типа _button1, Button1ActionListener и так далее. В Android я знаю, что XML-ники используются для интерфейсов.
Опять же, что для вас Java IDE? Писать можно хоть в блокноте, а собирать через ant. Редактор, имеющийся в Eclipse, неплох по функционалу (как я понимаю, разработчики системы пользуются им и не собираются разрабатывать сторонние решения или решения для других IDE).
А генерация кода в целом, имхо, всегда не очень красивая. Ну откуда тупой программе знать, что эту кнопку вы хотите назвать так, а ту иначе? Пишите ручками. Я визуальный редактор использую для тестирования интерфейсов, положений и пр. За ним либо переделываю (оптимизируя), либо пишу заново, основываясь на полученном опыте. Вольностей, типа создания какого-нибудь Button1ActionListener при случайном двойном щелчке, не допускаю — иначе потом захлебнуться можно в этих непонятных названиях.
А генерация кода в целом, имхо, всегда не очень красивая. Ну откуда тупой программе знать, что эту кнопку вы хотите назвать так, а ту иначе? Пишите ручками. Я визуальный редактор использую для тестирования интерфейсов, положений и пр. За ним либо переделываю (оптимизируя), либо пишу заново, основываясь на полученном опыте. Вольностей, типа создания какого-нибудь Button1ActionListener при случайном двойном щелчке, не допускаю — иначе потом захлебнуться можно в этих непонятных названиях.
Кстати, я сам работаю в IntelliJ IDEA. Одна из проблем – это отсутствие инкрементальной фоновой компиляции при сохранении файла, как в Эклипсе (поэтому на сборку требуется некоторое время, аж несколько секунд), вторая – отсутствие указанного визуального редактора, но для меня это и не проблема вовсе. В целом, плане анализа кода, автоподстановки и меньшей тормознутости/глюкавости, Идея меня устраивает сильно больше Эклипса.
> это отсутствие инкрементальной фоновой компиляции при сохранении файла, как в Эклипсе
я использовал то, и то. У Эклипсы проблемы с адовыми глюками, временами приводящими в хлам то, что сгенерировано «инкрементальной фоновой компиляцией». Приходится перезапускать, удалять криво сгенеренные файлы, создавать магические папочки, и, в конце концов, все равботает, но осадочек остается.
я использовал то, и то. У Эклипсы проблемы с адовыми глюками, временами приводящими в хлам то, что сгенерировано «инкрементальной фоновой компиляцией». Приходится перезапускать, удалять криво сгенеренные файлы, создавать магические папочки, и, в конце концов, все равботает, но осадочек остается.
Назови кнопку не «Button1», а в яблочных традициях повербознее «RedButtonForActionPanel», в результате будут появляться осмысленные названия типа RedButtonForActionPanelActionListener =)
Кроме того, и лиснеры, и кнопки, и всё остальное — можно переиспользовать. Особенно актуально это для веб-приложений, когда каждый лиснер после сборки на клиенте превращается в гору JavaScript'а.
Кроме того, и лиснеры, и кнопки, и всё остальное — можно переиспользовать. Особенно актуально это для веб-приложений, когда каждый лиснер после сборки на клиенте превращается в гору JavaScript'а.
С ходу сможете написать layout, в котором несколько input-ов, а внизу (прилеплена к нижнему краю экрана) кнопка Ok? Вот так сразу, не методом проб и ошибок и не подглядывая в документацию (хотя, последнее вряд ли поможет)? А написать несколько текстовых полей в одну строку так, чтобы каждое заворачивалось при длинном тексте независомо от предыдущих (этого я, если честно, так и не смог добиться)? Я-то пишу через xml, поскольку гуевый редактор в эклипсе очень уж гуевый. Но пробовать правильность написанного приходится по многу раз. Не всегда успешно.
Как и с кодом, всё и сразу наверняка не получится, что-то где-то недоглядишь — то поле забудешь сделать однострочным, то ещё чего. Гуйный редактор неживой для полноценной работы (только в нём), но он неплох для создания эскиза, для общего расположения элементов. Дальше их всё равно надо настраивать и править, это можно хоть в редакторе, хоть вручную. Интерфейс можно хоть программным кодом генерировать при работе приложения, не забываем о системных диалогах, которые можно подправить (а не создавать свои с нуля).
Странно, у меня немного другие ощущения от iOS. Там есть как высокоуровневые и очень продуманные вещи, типа UIKit, CoreAnimation или там, например, CoreFoundation с GCD, но в некоторых местах там какие-то ямы в низкоуровневость.
Ну, простой пример — не пользуясь сторонними библиотеками попробуйте получить пиксель в формате RGBA из картинки. Или, выкачайте асинхронно файл с интернета. Это все пишется конечно, потом таскается с собой по всем проектам библиотечка своя, но хочется такие вещи стандартизировать и писать в 1-2 строчки вместо 50-100.
Ситуация очень похожа на OpenGL. Сверхгибкое API, но именно им без каких-то надстроек пользоваться тяжело, загрузки моделей из разных форматов нет, загрузки текстур из разных форматов нет, стоковых шейдеров, которые реализуют что-то похожее OpenGL ES 1.0 — нет.
Ну, простой пример — не пользуясь сторонними библиотеками попробуйте получить пиксель в формате RGBA из картинки. Или, выкачайте асинхронно файл с интернета. Это все пишется конечно, потом таскается с собой по всем проектам библиотечка своя, но хочется такие вещи стандартизировать и писать в 1-2 строчки вместо 50-100.
Ситуация очень похожа на OpenGL. Сверхгибкое API, но именно им без каких-то надстроек пользоваться тяжело, загрузки моделей из разных форматов нет, загрузки текстур из разных форматов нет, стоковых шейдеров, которые реализуют что-то похожее OpenGL ES 1.0 — нет.
> а ту надстройку, которая позволяет редактировать xml-ки с описанием GUI даже назвать редактором интерфейса язык не поворачивается.
так никто ее, в основном, и не не использует. Только в самом начале, чтобы понять идею. Да и не под всеми IDE она есть.
так никто ее, в основном, и не не использует. Только в самом начале, чтобы понять идею. Да и не под всеми IDE она есть.
к меня есть знакомый php-шник — написал прогу за пару дней. одновременно разбираясь с java.
В целом в статье поток мыслей, но я с ней согласен. Касательно php: я не представляю, какой монструозный код могут писать программисты, не знакомые (плохо знакомые) с другими языками. Тут очень сильно помогает наличие исходников всей системы: можно посмотреть, как именно устроен тот или иной компонент или вся программа. Разработчику дана бóльшая гибкость, но она нужна не всем и не всегда.
В iOS всё хорошо, пока используеются стандартные объекты. Тут была статья о разработке приложения под iOS с элементами в интерфейсе с нестандартными свойствами (например, поле ввода с автоподстановкой, и прочее), вот это, конечно, был квест. Я читал статью, как детектив: было любопытно, добьются ли разработчики своего.
В iOS всё хорошо, пока используеются стандартные объекты. Тут была статья о разработке приложения под iOS с элементами в интерфейсе с нестандартными свойствами (например, поле ввода с автоподстановкой, и прочее), вот это, конечно, был квест. Я читал статью, как детектив: было любопытно, добьются ли разработчики своего.
Кстати, в iOSе же можно понемножку реверсинженирить фреймворки с помощью IDA Pro. Круто если бы кто-нибудь написал на хабре подробную статью на эту тему.
Ну, она и андроидные либы (*.so) берёт. Или только делает вид, потому что читаемость там нулевая (я просто не увидел код, были лишь какие-то блоки данных; может настройки «импорта» не подошли).
Но переводить обратно из мобильного машинного кода в objC — спасибо, врагу не пожелаешь)) Всё же армовый ассемблер весьма специфичен…
Но переводить обратно из мобильного машинного кода в objC — спасибо, врагу не пожелаешь)) Всё же армовый ассемблер весьма специфичен…
В чем то я даже согласен с автором, Андроид достаточно сложная система. Но ведь для того чтобы что то упростить нужно и что то усложнить. С этой точки зрения Андроид очень продуман. Если какой то функционал сложно реализовать на начальном этапе то в большенстве случаев эта реализация оказывается очень гибкой и ее легко использовать повторно. А по поводу качества приложений, как уже говорили выше, дело не в API а в контроле. А по поводу того что для iOS легче написать небольшое приложение, по моему не аргумент.
Выскажусь тоже. Активно использую платформу не так давно и все же выводы сделать могу.
1) Меня радует, что основной язык — это Java. Это во многом плюс благодаря тому, что есть куча библиотек, прекрасных библиотек, которые портируют и под Андроид. Кроме того когда хорошо знаешь Java писать на ней приятно и быстро(не Питон конечно), но довольно быстро.
2) Бесит фрагментация. Бывает так, что девайсы одной марк(НТС, к примеру) работаю по-разному. Про это уже говорилось не раз и тут нужно сидеть и думать как выкрутиться и не всегда получается придумать.
3) Вход, как пишит автор, не такой уж и сложный. Не знаю, что он там писал, но простенькое приложение за два дня написать вполне можно не являясь гуру в Андроид. С другой стороны действительно есть вещи, которые загоняют в тупик(но тут еще часто помогает в этом требование переноса приложения из под ios). Примером могут быть задачи, которые по суте простые(к примеру я хочу сделать всплывающее окно аля MediaController, а вот фиг его сделаешь так просто… и VISIBLE/GONE да помогут, и тем не менее нужно еще отследить момент когда всплывать, а когда нет, полазев в исоднике MediaController понимаешь… Боже какой же изврат и я до сих пор смутно понимаю как там фиксировано событие показа окна). Может быть сказывается молодость платформы, хотя не такая уж она и молодая, может быть политика гугла. Так или иначе мнение у меня двоякое. Для функциоального приложениянужно знать действительно очень много. Стадартные вещи делаются просто, не стандартные весьма не просто.
4) Все равно как пользователь и разработчик мне многие моменты нравятся, но многие хотелось бы сделать проще, надеюсь гугл так и поступит. И да, пора бы в маркете порядок навести. Hello World-ы поубирать явно пора бы. Хотя с другой стороны есть куча альтернативных маркетов.
5) Также не нравится, что люди хотят видеть приложение под Андроид похожим на ios(по дизайну и плюшечкам). Это разные платформы с разными подходами и это нужно понимать.
6) Как я вижу решение проблемы — это выделение большего времени на изучение базы(апи и компонентов) и более продвинутых апи, библиотек, а также на написание простеньких и не очень приложений.
А вообще, есть такое мнение, что Андроид заточен под игры и пожалуй так оно и есть(привет RenderScript, аха)
Итог: все не так плохо как у автора, но над многим поработать Google и альянсу нужно.
1) Меня радует, что основной язык — это Java. Это во многом плюс благодаря тому, что есть куча библиотек, прекрасных библиотек, которые портируют и под Андроид. Кроме того когда хорошо знаешь Java писать на ней приятно и быстро(не Питон конечно), но довольно быстро.
2) Бесит фрагментация. Бывает так, что девайсы одной марк(НТС, к примеру) работаю по-разному. Про это уже говорилось не раз и тут нужно сидеть и думать как выкрутиться и не всегда получается придумать.
3) Вход, как пишит автор, не такой уж и сложный. Не знаю, что он там писал, но простенькое приложение за два дня написать вполне можно не являясь гуру в Андроид. С другой стороны действительно есть вещи, которые загоняют в тупик(но тут еще часто помогает в этом требование переноса приложения из под ios). Примером могут быть задачи, которые по суте простые(к примеру я хочу сделать всплывающее окно аля MediaController, а вот фиг его сделаешь так просто… и VISIBLE/GONE да помогут, и тем не менее нужно еще отследить момент когда всплывать, а когда нет, полазев в исоднике MediaController понимаешь… Боже какой же изврат и я до сих пор смутно понимаю как там фиксировано событие показа окна). Может быть сказывается молодость платформы, хотя не такая уж она и молодая, может быть политика гугла. Так или иначе мнение у меня двоякое. Для функциоального приложениянужно знать действительно очень много. Стадартные вещи делаются просто, не стандартные весьма не просто.
4) Все равно как пользователь и разработчик мне многие моменты нравятся, но многие хотелось бы сделать проще, надеюсь гугл так и поступит. И да, пора бы в маркете порядок навести. Hello World-ы поубирать явно пора бы. Хотя с другой стороны есть куча альтернативных маркетов.
5) Также не нравится, что люди хотят видеть приложение под Андроид похожим на ios(по дизайну и плюшечкам). Это разные платформы с разными подходами и это нужно понимать.
6) Как я вижу решение проблемы — это выделение большего времени на изучение базы(апи и компонентов) и более продвинутых апи, библиотек, а также на написание простеньких и не очень приложений.
А вообще, есть такое мнение, что Андроид заточен под игры и пожалуй так оно и есть(привет RenderScript, аха)
Итог: все не так плохо как у автора, но над многим поработать Google и альянсу нужно.
Для статистики.
У меня абсолютно иная история освоения iOS и Android.
Под iOS.
Лишь через полгода смог выложить первое приложение в аппстор. Долго вживался в IB.
Под Android — через 2 дня. Возможно сказался опыт с j2me.
У меня абсолютно иная история освоения iOS и Android.
Под iOS.
Лишь через полгода смог выложить первое приложение в аппстор. Долго вживался в IB.
Под Android — через 2 дня. Возможно сказался опыт с j2me.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новичок о переходе с iOS на Android