LINUX.ORG.RU
ФорумTalks

[tl;dr] Android требует _очень_ хороших разработчиков


0

1

Наткнулся в Гуглоплюсе на забавный пост, просто переведу и оставлю здесь. Это было как откровение, почему так любят iOS и так не любят Андроид.

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

Итак, к делу.

Купил себе Nexus S. Программировал под Андроид несколько последних дней. Android API требует, чтобы пользователи являлись очень хорошими программистами. Абстракции Андроида намного более наворочены (раздуты, навязаны, переусложнены), чем их эквиваленты в iOS. Между тем, “intents” просто замечательны, но только если въехать в них.

Простите, все что дальше — поток сознания. tl;dr

После пары дней программирования iOS у меня было работающее приложение. После пары дней Андроида я только-только начал понимать абстракции.

Похоже, разработчики Андроида хотели дать потребителю API (разработчикам приложений) свободу делать всё, что захочешь. Между тем, глубина знаний паттернов проектирования требуется так сильно и так бессмысленно, что большинство разработчиков приложений изучат только 50% необходимых для выполнения задачи вещей, и закончат простреливанием ноги, внезапно разрушив юзабилити в оставшихся 50%. iOS позволяет навести пушку на ногу, но и дает возможность никогда не нажимать курок.

Например, чтобы корректно реализовать асинхронный HTTP, на iOS и Android нужно пройти абсолютно разные испытания. На iOS можно использовать встроенные библиотеки, и если пользователь вдруг переключается между приложениями в момент запроса, можно быть уверенным, что имеешь до 30 секунд, обычно больше, чтобы закончить свои задачи до завершения приложения. На андроиде же нужно реализовать android app service, апи для всех важных сетевых вызовов. Приложение может быть убито в любое время, поэтому ты должен хранить все свои аргументы, и попробовать снова сделать вызов в случае, если оно действительно умрет.

Это называется «хорошей практикой» и, как утверждается, подходит для 99% случаев (хотя и с большим количеством ненужного кода и работы с твоей стороны). Решения в области дизайна становятся очевидными, как только понимаешь, что ограничения аппаратуры и провайдеров являются неотъемлемой частью андроида, между тем разработчикам приложений это доставляет мало радости. iOS поддерживает методы, которые также подходят к 95% случаев, но при этом требуют намного меньше усилий со стороны разработчика для создания правильно работающего приложения.

Разработчики iOS имеют доступ к отличной документации. В тех местах, где библиотека документации iOS/Cocoa/Core* обычно очень хороша, вердя разработчика в верном направлении, в сторону более простых абстракций, документация Андроида делает несколько предположений, она предполагает отличное знание паттернов разработки Java, и это в дополнение к собственным андроидовым паттернам. Например, вот: «android.content.ContentProvider» или «android.app.Service».

В разработке под Андроид есть огромный потенциал, и есть несколько действительно хороших приложений. Только я чувствую, что они не в этой области. Необходимо больше абстракций, чтобы мы (разработчики мобильных приложений) могли быстрее разбираться в вопросе, с 95% точностью. В данный момент, мы имеем API, позволяющее сделать идеальное приложение, но только если мы хотим инвестировать месяцы в исследование (анти?)паттернов проектирования под Андроид для того, чтобы наш первый REST-запрос отработал корректно. А еще можно быть специалистом в Computer Science — но ведь на самом деле не все мы пошли по этому пути. По факту, немногие из нас (обратите внимание на почти все отличные приложения под iOS).

★★★★☆

Ты забыл.

[apple][вброс]

radg ★★★★
()

У нас абсолютно противоположная ситуация. Программист за 2 недели насобачил рабочий прототип программы под андроид, а вот под Ios пишет долго и нудно.

Deleted
()
Ответ на: комментарий от Deleted

У нас тоже. В том-то и интрига, что большинство комментаторов в гуглоплюсе абсолютно согласно с автором, а сейчас их там больше 80 человек.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от Deleted

«насобачить прототип» и получить нормальное, не глючное приложение - разные вещи.

zgen ★★★★★
()
Ответ на: комментарий от zgen

Вот гляди.
1) Не кажется ли тебе, что описанные в оппосте решения гугла совпадают с аналогичными решениями в linux (по сравнению с маком и виндой)?
2) Не кажется ли тебе странным, что чел ноет «я не специалист, жаву и андроид не знаю и знать не хочу», но при этом хотящий сделать супер-корректно реализованое приложение как раз на жаве и андроиде?
3) Не кажется ли тебе странным, что единственная обсужденная в оппосте техническая особенность андроида - возможность потушить и возобновить любое приложение с любого места - являющееся нифиговой оптимизацией сразу по всем ресурсам, было воспринято автором строго негативно?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Насколько я понял, автор вбросил на тему того, что для разработки под ведроид надо быть программером, а ябблоос позволяет писать даже быдлокодерам. Порог вхождения.

pekmop1024 ★★★★★
()

> Android API требует, чтобы пользователи являлись очень хорошими программистами

Крутой аргумент: я плохой программист, в то время как для программирования с помощью ондроеда надо быть хорошим; следовательно ондроед — говно. Желаю автору долгой и мучительной смерти.

fang
()
Ответ на: комментарий от stevejobs

1) да
2) кажется
3) да

А теперь ответь мне, не кажется ли тебе, что легкость программирования корректно работающего приложения = успеху приложения = выгоде разработчика?

Не кажется ли тебе, что сложность создания и работы приложений в linux и являются той самой причиной, по которой на десктопах его до сих пор ничтожно малое количество?

Если что, то я фанат андроида, да.

zgen ★★★★★
()

Ведропроблемы. Пусть учит пхоне7.

thesis ★★★★★
()
Ответ на: комментарий от zgen

> Не кажется ли тебе, что сложность создания и работы приложений в linux и являются той самой причиной

И чего там сложного? В линуксе Java другая? — Нет, такая же самая. Или, может, posix API сложнее, чем WinAPI? — Опять нет, в разы проще.

fang
()

документация Андроида делает несколько предположений, она предполагает отличное знание паттернов разработки Java, и это в дополнение к собственным андроидовым паттернам

Абалдеть! Для разработки на Java под Android, надо знать и Java и Android! Как такое может быть?

Black_Shadow ★★★★★
()

Да, чтобы нормально разбираться в Android SDK нужно знать паттерны проектирования, и я не вижу в этом ничего плохого. Если понять какие паттерны используются в реализации %SomeAPI% Android SDK, то довольно просто становится.

Другое дело багофичи, но это уже вопрос кривости реализации.

mono ★★★★★
()
Ответ на: комментарий от fang

поэтому каждое второе приложение linux - это исключительная кучка экскриментов, которую даже видеть не хочется, не то, чтобы пользоваться.

zgen ★★★★★
()
Ответ на: комментарий от zgen

Хочешь сказать, что любительские говноподелки в других системах чем-то лучше и их меньше? Ох и сомневаюсь я.

fang
()
Ответ на: комментарий от zgen

какая нафиг доля истины? пост писал человек, который разбирался с API в лоб, не ознакомившись с матчастью. Удивительно! нужно знать Java и паттерны.

а iOS и Objective-C это большей частью вещь в себе.

mono ★★★★★
()

Это все конечно хорошо, но я более чем уверен, что дядек наверху абсолютно не волнуют паттерны и прочие страшные для них вещи. Есть платформа, которая рвется к захвату мира, есть миллионы клиентов - значит есть потребность в софте. А значит эти приложения будут писаться несмотря на стенания разрабов.

spoilt ★★★
()
Ответ на: комментарий от pekmop1024

> ябблоос позволяет писать даже быдлокодерам. Порог вхождения.

ой не скажите. ИМХО порог входжения в Java будет пониже чем в Objective-C, причем даже для знакомых с программированием. Cocoa это штука очень хорошая, но, большей частью, сама в себе.

hellra1ser
()

Ну и зачем этот яблопиар нужно было переводить и постить на ЛОР?

segfault ★★★★★
()

Собственно, с Java начал знакомиться именно из-за Андроида. После C++ язык вполне можно выучить за пару дней. Паттерны программирования Андроида достаточно просты, любой усидчивый программист без проблем с ними справится. Думаю, основная проблема в том, что кому-то просто лень изучать API Андроида, а хочется всё и сразу. Тут уж извините.

Соглашусь в том, что документация объёмная: GUI, разделение layout'ов, локализация, Binder как IPC, сервисы в других процессах, intent'ы, JNI, различные API Level. Практически весь API Андроида — вещь в себе, читать нужно много.

Dendy ★★★★★
()
Ответ на: комментарий от fang

>В линуксе Java другая? — Нет, такая же самая

заметь, на sourceforge жаба приложений больше чем на C и C++ вместе взятых. но луноходы упорствуют и предпочитают бороться с GTK и Gnome вместо клепания рабочих программ

Karapuz ★★★★★
()

чтобы вот такое написать http://www.youtube.com/watch?v=56XseC2DBB4 даже паттерны знать недостаточно, нужно железо на низком уровне знать, поэтому iOS говно, потому что не позволяет такие крутые игры писать первому бангладешцу с улицы

Karapuz ★★★★★
()

имхо, наоборот После андройдовской, iOsная библиотека кажеться мненеудобной и нелогичной

koirn
()

Пиздежь и провокация. Чтобы написать простое приложение под андроид, достаточно знать жабу и за 30 минут из первого попавшегося из гугла туториала узнать, как внутри активити цеплять ссылки на виджеты из xml-файла. Сервисы и прочая хрень приходят только тогда, когда это действительно нужно - читай через полгода и к тому времени ты к ним уже вовсю готов и морально и информации обрывками нацеплять успел. Про 30 секунд бонуса вообще смешно - насколько я знаю (по крайней мере так было точно до 4й версии), в айфоне при нажатии большой круглой кнопки приложению автоматом наступает пипец и что там происходит дальше вообще никого не волнует, а в андроиде все эти сервисы, паттерны и бест-практисы имеет смысл изучать только тогда, когда ты хочешь, чтобы приложение жило и после этого знаменательного события (читай - после того, что в айфоне вообще никак не обрабатывается и считается точкой отсчета большого взрыва новой вселенной). Вообще говоря, жабу знать тоже не сильно обязательно по большому счету - заявляю авторитетно на своем опыте (не про знание жабы) и опыте пары десятков студентов (незнание жабы прилагается).

bender ★★★★★
()
Ответ на: комментарий от bender

> написать простое приложение под андроид, достаточно знать жабу

достаточно знать жабу


Опыт показал, что даже это необязательно.

rival ★★
()
Ответ на: комментарий от fang

>Или, может, posix API сложнее, чем WinAPI? — Опять нет, в разы проще.
А почему сразу WinAPI? Им пользуются только для мелких быстрых нативных приложений (кстати, нереализуемо в линуксе по-нормальному) и для разработки более высокоуровневой фигни.
Win-девелоперы всегда могут писать на .NET либо выбрать из ~пяти нативных наборов API. И в любом случае приложение будет выглядеть родным, а не как в линуксе.

x3al ★★★★★
()
Ответ на: комментарий от x3al

> А почему сразу WinAPI?

Ну не с .NET же posix API сравнивать, верно. Вещи одного уровня абстракции и сравниваю.

для мелких быстрых нативных приложений (кстати, нереализуемо в линуксе по-нормальному)

Попахивает абсурдом, но, на всякий случай, спрошу: пример подобной мелкой прикладной задачи, которая в линупсе по нормальному нереализуема?

Win-девелоперы всегда могут писать на .NET

А линупс-девелоперы всегда могут писать на жабе. Правда, как было верно замечено выше по треду, многие предпочитают жрать кактус в виде GTK, Qt etc.

И в любом случае приложение будет выглядеть родным, а не как в линуксе

Расшифруй.

fang
()
Ответ на: комментарий от fang

>Попахивает абсурдом, но, на всякий случай, спрошу: пример подобной мелкой прикладной задачи, которая в линупсе по нормальному нереализуема?

У меня в процессах висит менеджер клипборда, который по хоткею выдаёт всплывающее (прямо от курсора в нативном софте) меню с историей. Весит 1Мб RAM (которая настолько дёшева, что Gtk+-helloworld весит до 20 метров). Умеет юникод, причём по-настоящему, а не как X Core Fonts.

На чём можно сделать такое в линуксе?

Расшифруй.

А что расшифровывать? Нет проблем с разными темами, шрифтами, диалогами. Look-n-feel не зависит от того, на чём написан софт.
С Ribbon и directwrite это слегка начало ломаться, но до линуксового зоопарка далеко.

x3al ★★★★★
()

Забавный персонаж по ссылке. С постом не соглашусть — обе платфомы до определённой степени позволяют писать «не приходя в сознание».

REST request

What the fuck am I reading?

ufw
()
Ответ на: комментарий от Karapuz

> на sourceforge жаба приложений больше чем на C и C++ вместе взятых. но луноходы упорствуют и предпочитают бороться с GTK

так нету годных гуе-биндингов до GTK/Qt для жавы. Qt Jambi — закопали, то есть отдали сообществу. Есть SWT, который на линуксе рендерится через GTK, а на маке - через Cocoa, но это ни разу не биндинг.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от bender

Судя по всему, автор хотел за пару дней портировать готовое iOS'овское приложение, и «сервисы и прочая хрень» у него появились сразу, а не через полгода. А еще более лютый баттхерт доставило, что структура iOSовской проги отличается от андроидовой на уровне паттернов, поэтому просто перекопипастать код, заменив названия методов у него не получилось. Еще более лютый баттхерт доставило отсутствие некой «единственно правильной» предопределенной архитектуры, которой можно было бы скормить пачку лиснеров и получить приложение. Чувак погуглил доки, нашел доки по фреймворкам, а доков по «тысяче лиснеров, которые просто нужно запомнить» и по «единственно правильной архитектуре» - не нашел, и его это очень, очень опечалило.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от x3al

Win-девелоперы всегда могут писать на .NET либо выбрать из ~пяти нативных наборов API. И в любом случае приложение будет выглядеть родным, а не как в линуксе.

Для Linux наиболее часто используются GTK и Qt (и их биндинги для других языков, и тулкиты, работающие поверх них). GTK умеет работать через Qt, Qt умеет выглядеть как GTK. Любое приложение будет родным а не как в винде. Lin-девелоперы всегда могут писать на .NET Mono (Gtk#), Java (SWT (работает через GTK), Qt Jambi), C++ (Gtkmm, Qt, WxWidgets), Python (PyQT, PySide, PyGTK), Pascal (LCL - умеет работать поверх GTK и Qt, биндинги GTK и Qt) и других языках с другими тулкитами-обертками над GTK или Qt. И в любом случае приложение будет выглядеть родным, а не как в винде.

PS. Знаю, сейчас набежат фанаты FLTK, Tk, Xaw3d и прочих недотулкитов. Так вот, под виндой они тоже есть и выглядят ненативно. Но ИМХО они таки не нужны (может, FLTK нужен для сверхлегкого десктопа, но остальные-то точно не нужны).

Deleted
()
Ответ на: комментарий от x3al

У меня в процессах висит менеджер клипборда, который по хоткею выдаёт всплывающее (прямо от курсора в нативном софте) меню с историей. Весит 1Мб RAM (которая настолько дёшева, что Gtk+-helloworld весит до 20 метров). Умеет юникод, причём по-настоящему, а не как X Core Fonts.

На чём можно сделать такое в линуксе?

:D Скажите лучше, на чем нельзя.

Gtk+-helloworld весит до 20 метров

:D А почему у меня все GTK-шные бинарники (как и qt-шные), меньше?

Deleted
()
Ответ на: комментарий от Deleted

>GTK умеет работать через Qt, Qt умеет выглядеть как GTK. Любое приложение будет родным а не как в винде.
Что, прямо и look, и feel? Да быть не может. Look пилят фридесктоповцы, а feel — не пилит вообще никто.

Так вот, под виндой они тоже есть и выглядят ненативно.

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

:D Скажите лучше, на чем нельзя.

Весит 1Мб RAM


Кроме чистого xcb + pango через xft ничего не приходит в голову. Но это будет выглядеть ненативно и непонятно как получить координаты курсора в этом зоопарке тулкитов. Да и всё равно будет жирнее.
А без pango (который и составляет большую часть жира) поддержки юникода тупо не будет.

:D А почему у меня все GTK-шные бинарники (как и qt-шные), меньше?

Потому, что у тебя 32 бита. Либо GTK собрано без интеграции с Qt (метров 8, емнип). Либо что-то из этого собрано без OpenGL (тоже немало).
Я прекрасно знаю, сколько весят линуксовые библиотеки.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Что, прямо и look, и feel? Да быть не может. Look пилят фридесктоповцы, а feel — не пилит вообще никто.

Look - в этом плане все, что можно сделать, уже сделано. Feel - не совсем, но разнообразия не больше, чем в винде.

Потому, что у тебя 32 бита. Либо GTK собрано без интеграции с Qt (метров 8, емнип). Либо что-то из этого собрано без OpenGL (тоже немало). Я прекрасно знаю, сколько весят линуксовые библиотеки.

Тогда все ясно - вы в вес программы посчитали и вес самого gtk, pango и прочей ерунды. Вас ведь никто не заставляет линковать их статически (и под виндой вы тоже не линкуете дотнеты и прочие статически, иначе каждый бинарник у вас весил бы много Мб). Кто вам мешает нативную для никсов библиотеку (какими являются gtk, pango и прочее) линковать динамически, как это делают все? Вы ведь на винде msvcrt, mfc и дотнеты линкуете динамически.

PS. Почти все найденные в системе бинарники размером намного меньше одного Мб.

Deleted
()
Ответ на: комментарий от Deleted

PS. Почти все найденные в системе бинарники размером намного меньше одного Мб.

Система 64-битная.

Deleted
()
Ответ на: комментарий от Deleted

>PS. Почти все найденные в системе бинарники размером намного меньше одного Мб.
Это по потреблению RAM? Можешь замерять как угодно (хоть free до и после запуска), всё равно до 1Мб с GTK+/Qt ты не дойдёшь.

x3al ★★★★★
()
Ответ на: комментарий от stevejobs

Значит у него сбоит логика, т.к. он делает выводы о сложности системы для новичков основываясь на мягко говоря нетрадиционном опыте да еще с изначально дефективным подходом к решению задачи - по сути все обвинения можно сжать в одну фразу - «Android полное г, потому что это не iOS».

bender ★★★★★
()
Ответ на: комментарий от Deleted

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

Вы ведь на винде msvcrt, mfc и дотнеты линкуете динамически.

Это winapi. Ничего динамически слинкованного, кроме user32/kernel32/advapi32.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Ничего динамически слинкованного, кроме user32/kernel32/advapi32.

MFC, дотнеты и msvcrt вы тоже с собой таскаете?

Deleted
()
Ответ на: комментарий от x3al

По размеру файла. По RAM ради 1 Мб придется извращатся, и в винде тоже, если писать не на голом WinAPI.

Deleted
()
Ответ на: комментарий от Deleted

>А почему сразу WinAPI? Им пользуются только для мелких быстрых нативных приложений (кстати, нереализуемо в линуксе по-нормальному) и для разработки более высокоуровневой фигни.

кстати, нереализуемо в линуксе по-нормальному

Что и требовалось доказать.
Кстати, вес вместе со всеми либами и x64-версией — 117 килобайт.

x3al ★★★★★
()
Ответ на: комментарий от x3al

кстати, нереализуемо в линуксе по-нормальному

Что нереализуемо? WinAPI нереализуемый? man wine (кстати, я когда-то (во времена 0.9.x) смотрел в исходники - код достаточно качественный и понятный, без извращений).

А зачем WinAPI? Чем его не могут заменить нативные API?

Deleted
()
Ответ на: комментарий от Deleted

Ты не умеешь читать? Нативно выглядящая программа в x64 семёрке весит 1 метр RAM. В линуксе этого не достичь вообще никак. wineserver будет весить больше.
Это — далеко не единственный пример, кстати.

x3al ★★★★★
()
Ответ на: комментарий от x3al

А, собственно, почему вы привязались к этому 1 метру рамы?

Вброшу немного: последний Debian легко стает и нормально работает при 128 Мб рамы без свопа. C LXDE можно иметь абсолютно юзабельный и удобный десктоп (удобный даже для человека, не знакомого с никсами вообще), и даже своп не понадобится. И приложения все будут выглядеть нативно - GTK+ ведь. И гномоофис мжожно юзать - если не грузить очень большие документы, своп не понадобится. А можно ли последнюю винду, в которой существуют выглядящие нативно приложения, едящие меньше 1 Мб рамы, хотя бы поставить на такой компьютер? :)

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.