Как стать Android разработчиком? (4 стр)

Try
> Вместо доки написан код
  Ай-яй-яй. Что за несправедливость, ведь надо было для тупых написать, что этот код делает то же самое, что и код "getActivity().getResources()". Хотя не, погоди, да там ведь практически так и написано :)

> Реализация в 4.3:
  Что не так? Метод делает то, что написано в документации - вызывает getActivity().getResources(). Ты точно ту ссылку дал? Не верю, что ты такой идиот.

> Нужно ли проверять результат на нул?
  Ну я бы не стал надеяться, что getString("my absent id") вернёт что-то отличное от нуля. В итоге документация опять вполне исчерпывающая и даже то, что написано написано для галочки специально для таких как ты.

> Аналогично.
  Аналогично исчерпывающе.

> Что оно вернет на этом?)
  Ну так как документация допускает возврат null, то я считаю, что что бы там ни вернулось, оно на 100% ею покрыт. К тому же результат зависит от вендора. Если кто-то на его основе наворачивает какую-то логику, то таких разработчиков можно только пожалеть.

  Итого - ни одного примера вопиющего несоответствия или отсутствия документации. Если это все косяки андроида, то я теперь могу с полной уверенностью сказать, что это система с самым документированным API из существующих.

  Теперь вопросы к тебе: что вернёт std::vector.front(), если вызвать его на пустом векторе? Документация кроме undefined behavior не говорит ничего. Это вообще типичный ответ документации на всё, что ею не покрывается, в стандарте С++ подобное встречается более ста раз. Результат: http://ideone.com/weXrUw. Это к слову о том, какого качества документация у STL, если вдруг кто-то не в курсе. Аналогичный метод из JDK: http://docs.oracle.com/javase/7/docs/api/java/util/Vector.html#firstElement() - "NoSuchElementException - if this vector has no components". Коротко и по делу.
  Кстати, особенно стоит отметить упор на exception safe в STL. Когда в документации написано, что метод exception safe, то это следует понимать как что если в нём случается что-то плохое, то не нужно ждать выпадания исключения и ловить его, потому что исключения это плохо и небезопасно. Вместо этого прога просто по тихой свалится как в приведённом случае :)

> Внутренняя реализация(которая будет у каждого вендора своя) != устройство.
  Не знаю, что ты там себе думал, но для любого программиста это слова-синонимы. Уже начинаешь как картонажник выкручиваться и буквоедствовать.

Zefick
> Хотя не, погоди, да там ведь практически так и написано
Не понимаешь что в код делает и стесняешься сказать?

throw new IllegalStateException("Fragment " + this + " not attached to Activity");

- не вернет Activity) И если, ты будшь "верить" getActivity().getResources(), проверив только NullPointerException, то будешь на следующий день выпускать патч. И можешь сколько угодно называть всех идиотами - падать будет твоя прога)

Zefick
> что написано написано для галочки
Чем писать ложную информацию, лучше не писать. Автор getString, тоже решил ничего не проверять при написании метода - они и нулл вернет и упадет, может случится все что угодно. И еще иногда возвращается строка)

Zefick
> Теперь вопросы к тебе: что вернёт std::vector.front(), если вызвать его на пустом векторе?
> Документация кроме undefined behavior не говорит ничего.
Полностью исчерпывающий ответ. Т.е. тебе честно написали что может случится все что угодно.

А как это относится к Android? Или недостатки других как-то отменяют проблемы android?

Zefick
> Если кто-то на его основе наворачивает какую-то логику, то таких разработчиков
> можно только пожалеть.
Т.е +1 неюзабельный метод?)

Zefick
> exception safe в STL. Когда в документации написано, что метод exception safe,
> ... то не нужно ждать выпадания исключения
Ты точно в курсе, что такое exception-safe?

Zefick
> ни одного примера вопиющего несоответствия или отсутствия документации
Каждая такая функция в твоем проекте - будующий крэш. Крэш от того, что ты взял и поверил их докам и додумал что там не написано, параллельно занимаясь копипастой примеров)

Try
> - не вернет Activity)
  Как и getActivity().getResources(), собственно не вернёт то, что нужно. В чём проблема?

> проверив только NullPointerException,
  Охлол. Ты вообще не умеешь исключеня ловить, чтоли? Конкретно NPE никто не ловит. Никогда, даже в андроиде. Ловят Exception. Вот что кресты с людьми делают-то.
  Ну и я себе не представляю, что это за говноконтора, которая выпускает приложение, в котором фрагмент оказывается неприатаченным к активити. Фигак-фигак и в продакшен?

> Т.е. тебе честно написали что может случится все что угодно.
  Ахаха. Под столом. Это называется документация. Честно сказали, что не знают, что случится :D

> А как это относится к Android? Или недостатки других как-то отменяют проблемы android?
  Ну как, твои же слова.
> у конкретно этих нормальная документация(в случае stl, в java все как в java).
  А теперь"как это относится к андроид". Когда ты это писал, я не спрашивал как оно относится, я просто сразу знал, что это чушь. В итоге у JDK нормальная документация, а в STL написано, что может случиться всё, что угодно :)

> Каждая такая функция в твоем проекте - будующий крэш.
  В моём проекте работоспособность функций не зависит от наличия у них документации или того, что в ней написано. Не путай пожалуйста меня и всяких кодомакак, которые пишут программы перебором.
  Наглядный пример в твоём случае это уже хотя бы то, как ловишь исключения ты и как это делают нормальные разработчики. Если ты не знал, то на секундочку просвещу тебя, что независимо от документации к конкретному методу спецификация JVM не запрещает кидать в любом месте RuntimeException, потому что потенциально любой указатель может оказаться нулевым, в любом месте может не хватить памяти, любое обращение по индексу может выходить за пределы массива и тд и тп - на всех или большей части этих случаев нативная программа просто сваливается. А JavaDoc в принципе не заставляет описывать все случаи поведения (поэтому авторы SDK ещё молодцы что где-то это делают, в отличие от авторов STL), ведь если для каждой функции описывать все возможные кейсы, то один только список всех рантайм исключений, которые рекурсивно могут выпасть из вызываемых функций займёт много места. Поэтому ты выпускаешь патчи неделями, а нормальные разработчики ловят всё уже на этапе разработки.

Zefick
> Конкретно NPE никто не ловит. Никогда, даже в андроиде. Ловят Exception
Есть такой паттерн)

Zefick
> Ахаха. Под столом. Это называется документация.
Боюсь возьми ты книжку по математике или по физике еще смешнее будет)
Тем временем в реальности: информация о том, что zero_vec.first()=UB, достаточна чтобы не сломаться от пустого массива. Информация из android-доков - нет. И из Java - тем более)

Zefick
> Когда ты это писал, я не спрашивал как оно относится, я просто сразу знал, что
> это чушь
Что я не так написал? Или примеры библиотек с нормальными доками вне закона?

Zefick
> В итоге у JDK нормальная документация
Нет. Уже обсуждали примерно год назад - Set тому пример.

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

Zefick
> фрагмент оказывается неприатаченным к активити.
А ты хорошо подумал, прежде чем это сказать? В нормальной программе таких большинство, а в доке даже есть диаграмка) Ему даже события могут приходить в таком состоянии)
Не говоря про тупо буги версий до 4.1, где replace мог добавить фрагмент, но не прокинуть ему указатель на activity.

Zefick
> Не путай пожалуйста меня и всяких кодомакак, которые пишут программы
> перебором.
Разве такое можно подумать про человека, который советует копипастить примеры не глядя?)

Try
> Уже обсуждали примерно год назад - Set тому пример.
  Это тот эпичный тред, где ты в очередной раз посливался на незнании основ устройства или внутренней реализации контейнеров (как там у тебя правильно, что ты должен знать, а что не должен, я уже забыл) и в итоге выдал перл о том, что идеальная хэш-функция это такая, которая возвращает константу (хорошо хоть не рандом, лол)? Да, такое хрен забудешь, ты там ещё жаловался, что для тебя сравнить два объекта на равенство в Java это уже проблема. После такого я бы эту тему опять поднимать не стал, но ты вижу любишь рисковать. Хотя оно и понятно - терять всё равно уже нечего, раз уж опускаться, так ещё ниже и по второму кругу :)

> Тем временем в реальности: информация о том, что zero_vec.first()=UB,
> достаточна чтобы не сломаться от пустого массива. Информация из android-доков - нет. И из Java - тем более)
  Перечитал три раза, так и не понял то тут написано. Как будто какая-то обезьяна прошлась по клавиатуре, а потом автокомплит заменил всю абракадабру на похожие читаемые слова. Это всё равно, что сказать, что знание закона всемирного тяготения достаточно, чтобы никогда не спотыкаться, к вопросу о физике. Только тогда странно, что информации о том, что для сравнения двух объектов нужно использовать equals не достаточно, чтобы всегда использовать equals для сравнения двух объектов :)

> Или примеры библиотек с нормальными доками вне закона?
  Да я уже понял, что для тебя дока, в которой ничего толком не написано, а которая только напичкана всякими UB полезнее, чем та, в которой всё разложено по полочкам и по делу. Из этого делаем вывод, что документация в Java у тебя проходит искжающий постпроцессинг в мозгу с целью обязательно найти изъян, а любая другая считается за непогрешимую, какая бы ерунда там ни была написано. Дальше пытаться спорить с таким упорышем бесполезно.

Zefick
А в этой твоей документации есть подробные примечания, типа "данный метод не следует применять на устройствах Samsung таких-то моделей"? Или, например, "данная функция не работает на прошивке 4.1.134241 сборки такой-то"?

Zefick
> на незнании основ устройства или внутренней реализации
Если бы ты знал зачем нужны абстракции, то понимал бы: разработчик не должен знать каким именно образом авторы реализовали Set. Если на одной реализации это сортированный массив, на другой дерево, а на третьей список пропусков. Как разработчика, меня должно интересовать только то что там нет повторяющихся элементов.
То что авторы молчат про то что их контейнер сломается если[...] - это делает невозможным его использование.

Zefick
> чтобы всегда использовать equals для сравнения двух объектов
Ты так и не научился даже таки простым вещам) equals возращает, что попало а не результат сравнения)

Zefick
> хэш-функция это такая, которая возвращает константу (хорошо хоть не рандом, лол)?
Это точно лучше чем рандом. Но до авторов jvm это не пока не дошло.

Zefick
> Дальше пытаться спорить с таким упорышем бесполезно
Что, отвлекаю от срочного выпуска патча?)

TarasB
> не работает на прошивке
Это еще что, есть фичи в духе вызов одной функции ломает другую, или использование возращенного рузультата приводит к крашу)

Try
> equals возращает, что попало а не результат сравнения)
  Смотря как напишешь, но вообще это диагноз :)

Zefick
> Смотря как напишешь
Вот так например:

void foo(final CharSequence a, final CharSequence b){
    if(a!=null && b!=null)
      Log.d("equals",String.valueOf(a.equals(b)));
    }

SpannableString s1 = new SpannableString("sdfsd");
SpannableString s2 = new SpannableString("sdfsd");
foo(s1,s2);
foo("sdfsd","sdfsd");

Вывод:

05-07 23:31:32.671  13182-13182/com.example.myapp D/equals﹕ false
05-07 23:31:32.671  13182-13182/com.example.myapp D/equals﹕ true