Архитектура Android приложений

[Dimezis]

Есть ли какая-то причина почему вы используете Otto Bus, вместо шины на Rx?

а "mMvp..." это шикарно :)
Почему все решили, что надо везде фигачить эти префиксы m? Это паттерн для разработки Android SDK. И антипаттерн для всего остального. Даже Гугл об этом говорит.

[artemgapchenko]

Есть ли какая-то причина почему вы используете Otto Bus, вместо шины на Rx?

Вопрос лучше адресовать автору оригинальной статьи.

Почему все решили, что надо везде фигачить эти префиксы m?

Насчет того, что "Гугл об этом говорит", я не уверен (если и говорит, то делает это крайне непоследовательно). Если посмотреть примеры от Гугла, то там венгерская нотация используется и в хвост и гриву. Официальная документация от Гугла тоже использует эту нотацию. В многих учебниках по Android от сторонних авторов, не связанных с Google, она тоже используется. В общем в начале изучения разработки под Android эту привычку проще подхватить, чем не заметить.

[Dimezis]

Пардон, не заметил, что перевод

[Yoto]

На самом деле, Гугл против венгерской нотации. (с) Jake Wharton

[artemgapchenko]

Я читал её. :) Тут конечно можно поспорить, что он ссылается на стандарт Гугла по написанию Java кода в общем, а не на стандарт по написанию Java кода для Android приложений, но, так как он меня убедил, и я больше венгерскую нотацию использовать не буду, то занудствовать я тут не стану. :)

[orcy]

Прочитал, но не понял в чем прикол. Автор объясняет почему можно не использовать венгерскую нотацию даже несмотря на то что AOSP ее использует, однако не объясняет что в ней плохого среди возможных стилей оформления кода.

[ookami_kb]

Что в ней плохого:

1. Она в большинстве случаев бесполезна.
2. При рефакторинге легко забыть обновить эту информацию, и тогда она становится еще и вредной.

Он вроде половину статьи именно об этом и говорит.

[orcy]

Нотация из AOSP вроде mFieldName, sFieldName по моим ощущением помогает при взгляд не код, что переменная является членом класса, а не локальной переменной. Занимает одну букву, сложности рефакторинга по моему надуманы.

Я не то чтобы категорично за, но какого-то категоричного научного вреда от нее тоже не вижу.

[ookami_kb]

Сложности рефакторинга совсем даже не надуманы. В больших проектах с несколькими людьми разного уровня подготовки эти сложности возникают чуть реже чем всегда. Люди забывают об этом, и это нормально, просто это надо учитывать.

Нормальные IDE и так выделяют цветом/начертанием локальные/статичные и т.д. переменные, так что тоже хватает одного взгляда; поэтому лично я тут за нормализацию – раз той же степени визуализации можно добиться, не прибегая к избыточности данных, то это стоит делать.

[orcy]

Например у меня vim и crucible не отличают контекст определения полей, так что AOSP style помогает понять откуда берется. Насколько я знаю в тулзах вроде gerrit и github pull request тоже подсветка не такая продвинутая, а code review делать надо.

Проблем рефакторинга я все же не вижу, если где-то и s,m установленные неправильно, исправление будет тривиальным и чаще всего безопасным. Поля это обычно приватные поля класса (кроме публичных констант), так что контекст исправления будет чаще всего небольшим (один файл).

[ookami_kb]

Например у меня vim и crucible не отличают контекст определения полей, так что AOSP style помогает понять откуда берется.

Это если префиксы установлены правильно.

Вообще же, это по большей части спор о вкусах фломастеров. Мне его аргументация кажется убедительной, возможно потому, что изначально совпадает с моим мнением. Главное, чтобы code style в принципе был.

[orcy]

Да, со всем согласен

[niveus_everto]

IDEA 2016.1 перестала подсвечивать =(