Несколько полезных шаблонов для Android-разработки под eclipse

[sl4mmer]

Если честно я вообще с трудом понимаю смысл по прежнему сидеть на эклипсе (ну кроме привычки)

[bershadskiy]

если говорить об Android Studio (которая на базе идеи построена), то я все еще с удовольствием работаю в эклипсе, потмоу что привычка настраивать проекты уже есть, а переучиться править gradle конфиги ручками, чтобы заставить правильно заработать мультибиблиотечный проект меня как то утомляет. Но должен заметить, что как только JetBrains вместе с гуглом починят работу UI, то я с удовольствием перейду на студию, работать в ней дествительно приятно, даже не смотря на то, что это только превью версия.

[Tronum]

Использую Android Studio с самого первого ее появляния(пришел с Google IO и сразу скачал) для мультибиблиотечного, мультимодульного проекта. Никаких трудностей не испытываю, никто не заставляет исспользовать gradle. Попрежнему собираем maven или самой IDE. Все прекрасно взлетело с пол оборота. В команде есть люди сидящии на eclipse и никаких проблем и конфликтов нет тоже. Не в коем случае не хочу Вам перечить, но Ваше негодование мне не понятно. Около 2 лет использовал eclipse, после чего перешел на idea, которая понравилась больше. Сейчас использую постоянно «сырую» Android Studio и кроме довольства ничего не испытываю. Тут вопрос вкуса и тянет на холивар, чего не хотелось бы. Так что… на вкус и цвет.

[evilduck]

Возможно, вы не заметили слова «пока» в первом абзаце. Android Studio еще сырая, и никто не будет тратить уйму времени на перенос уже существующих и настроенных проектов на сырую IDE, в которой пока навалом багов. Как только выйдет стабильная версия, у которой не будет префикса 0., я с удовольствием перейду на нее, а пока я лучше буду пользоваться старым добрым и проверенным эклипсом.

[bershadskiy]

это Вы не совсем поняли смысл моих слов. я знаю, что пока Студия — только превью. Но уже в превью она обещает быть очень приятной. Потому я сожалею, что в ней еще есть всего пара багов, которые мешают мне сменить IDE. Как только их устранят, я с радостью буду пользоваться софтом, который доставляет меньше страданий, чем Эклипс. Ничего плохого не хочу о нем сказать, но Студия действительно получается лушим продуктом.

[evilduck]

Мы действительно друг друга не понимаем :) Я с Вами согласен, и сказал, по сути, то же самое. Суть в том, что это был ответ на сообщение от sl4mmer, а не Ваше :)

[evilduck]

Ого, ничего себе. Анонимные минусовальщики не только молча статье минусы поставили, но и в карму поднагадили. А смелости написать открыто, в чем проблема, не хватает?

[evilduck]

Побольше ненависти!

[4ex]

Полгода как переехал на IDEA, но Eclipse еще не удалил. Порылся в настройках нашел несколько однострочников.

1. Создание тега для логов:

private static final String TAG = ${enclosing_type}.class.getSimpleName();

2. Запись в лог с именем метода для удобства (у меня было 4 версии этого шаблона для разных уровней логирования):

${:import(android.util.Log)}
Log.d(TAG, "${enclosing_method}: ${cursor}");

3. Поиск виджета:

${type} ${new_name} = (${type}) findViewById(R.id.${cursor});

[Aux]

Всегда делайте проверку на тип при вызове findViewById(), а то потом вдруг для разных типов устройств случатся разные лейауты и будет у вас крэш, как было внутри SystemUI в CyanogenMod (:

[rimmer]

Проверка на тип довольно ресурсоемкая операция (если вы об instanceof). И нигде в исходниках не видел проверку типа, если не предполагается какой-то мультилейаут.
Да и у меня никогда подобных проблем не было, если использовать документированные Views.

[Aux]

Сейчас рекомендуется использовать responsive design с различными лейаутами. Вобщем, я предупредил (:

[4ex]

Давать одно имя экземплярам разных классов — это какой-то моветон. Обычно просто проверка идет на null, если макеты для разных конфигураций различаются, как, например, в документации: http://developer.android.com/training/multiscreen/adaptui.html.

[evilduck]

Нонсенс. Вы правда считаете, что «responsive design с различными лейаутами» влечет необходимость _ВСЕГДА_ делать проверку на тип? Зачем мне делать проверку, например, Button? Если я делаю в своем приложении несколько layout'oв, я точно знаю, где и когда что-то может измениться. Я либо постараюсь использовать базовый класс (AdapterView, CompoundButton), если я знаю, что там могут быть разные их реализации, или на крайний случай, сделаю несколько вариантов обработки. Но только конкретно для этого view. Но никак не для всех, как вы рекомендуете.

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

[Aux]

Я такое видел в исходниках андроида и цм. Думайте что хотите. Штука в том, что в больших проектах xml и код пишут разные люди.

[rimmer]

Вообще, если делать проверку на тип, то вероятность допустить ошибку как раз повышается. Так вы сразу получите class cast exception, а если делать проверку, то выполнение пойдет дальше и непонятно что там дальше будет.
Мне кажется, такие проверки нужны в строго определенных случаях, когда неизвестно что в лейауте и нельзя его поменять.

[zavyrylin]

Кстати. Не рекомендую теги для логов конструировать, используя конструкции вида SomeClass.class.getSimpleName(). А ну как вы вдруг решите использовать proguard со включённой обфусацией? И забудете про теги! Вот уверяю Вас: нет ничего замечательного расследовать крэш приложения, читая логи с тегами вида aQ, Bh и тому подобными. Ага, а место ошибки обозначено как SomeFile: ххх. Конечно, есть приблуды для расшифровки логов (а Вы ведь маппинги не забыли сохранить от версии N приложения?), но…

[4ex]

Я считаю хорошей практикой вырезать логи при релизе — нечего пользователям знать о внутренней кухне моего приложения. А если давать тегу имя по моему шаблону, то я получаю плюшку из коробки: тег всегда будет соответствовать правильному классу — и при переименовании класса, и при создании нового класса «копи-пастом» (по крайней мере в IDEA). Что же до расшифровки логов — если я вдруг не сохранил файлы для расшифровки, то ведь всегда есть система контроля версий и теги к ней: откатываемся до нужной ревизии, заново генерируем подписанный apk-файл и файл соответствия (mapping) для логов, и дальше уже работаем с ним.

[alcsan]

Давно использую шаблоны для Android-разработки, почерпнул немного нового из статьи.
От себя могу добавить простенький шаблон:

Log.i("Invoked", "" + this);

Теперь, когда нужно быстро проверить проходит ли приложение через некоторую точку, сколько раз, когда и сколько времени проходит между посещениями этой точки, нажимаю Ctrl + Space и пишу «log_inv».
Разумеется, использовать это стоит только при разработке и не оставлять лишних логов в приложении.

[yanchenko]

Для таких целей лучше использовать Log.wtf(...). (:

[yanchenko]

Шаблон для создания статических factory-методов, возвращающих Intent(пример):

${:import (android.content.Intent)}

public static Intent getIntent(Context ctx${cursor}) {
	Intent intent = new Intent(ctx, ${enclosing_type}.class);
	return intent;
}