Как стать автором
Обновить

Комментарии 48

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я старался. Может не все аспекты затронул. Постараюсь дополнить пост по результатам комментирования.
Тактические:
1) Избегайте создания лишних объектов.
2) По возможности делайте методы статичными.
3) Используйте прямой доступ к полям вместо методов посредников.
4) Используйте static final для констант.
5) Не используйте перечисления там, где достаточно обычной переменной целого типа.

Эти принцыпы всегда работали для мобильных устройст. — Это точно над делать когда пишете под не совем свежий телефон.

вот только пугать людей сильно не стоит — никто не заставляет отступать от ООП. и перебегать в процедурное програмирование.
можно и сетеры/геторы делать. ничего страшного не случится.
производительность утсройст славы богу нормальное — чего стоит только процессоры — меньше 600 нет, и память для вашего приложения тоже имееться.

так что по большому счету ООП надо юзать тут.

Я хотел сказать, что ООП нужно использовать только там где это действительно нужно.
ООП надо почти везде :) как только вы отнаследовались от Activity — вы уже используте ООП
да и классы у Вас свалины в один пакет — хотя явно должны быть в разных
Как их лучше распределить по пакетам?
скрины лежат либо в корневом пакете либо можно сделать пакет activities
классы отвечающие за доступ к данных — пакет dao или data
вспомогательные классы — в utils
вьюхи — views
компонеты — components
диалоги — dialogs
обработчики кнопок и прочего нужно выносить из анонимных классов в отдельные методы, что бы код был нормально читаемый.
ну кроме обработчиков в 2-3 строчки.
это просто правила хорошего тона — если потмо собираетесь разбирать то, что писали или комуто показывать :)
это облегчает чтение кода.

большая вложеность кода — нечитаема

по два вложенных класса :)
для About можно юзать AlerdDialog.Builder — ну или отнаследоваться от Dialog.
Правда, дальше в статье рассматривается такая возможность…
Совершенно верно. Хотел описать разные пути.
Отличный пост. Коротко, по делу и с примерами.
Запишите всё с помощью Камтасии Студио и цены вам не будет! :)
Хорошая идея. Постараюсь найти время.
Когда мне надо было быстренько вьехать в программирование под Android, смотрел вот эти видеотуториалы. Достаточно четко и понятно, советую.
Статья нормалек, но стилистически ужасна — порой язык заплетается от прочтения.
НЛО прилетело и опубликовало эту надпись здесь
Кнопка Exit? Как бы идеология Android говорит что мы не должны принудительно закрывать приложение, что жизненным циклом каждого конкретного приложения управляет Android OS
Это игра — ей позволительно, игры обычно стандартный интерфейс ОС никогда не используют.
При чем тут игра это или нет?
Первый же рисунок в статье дает нам однозначное толкование жизненного цикла ЛЮБОГО приложения на Андроиде. Если пользователь нажал Home или Back во время игры — все, мы подготавливаемся к выходу. А вот сам выход из приложения происходит только тогда, когда ОС сама это решит.
на Exit можно повесить банальный finish() и не килить процесс, и OS потом сама закроет приложение когда надо.
Скорее бы Android 2.2 с JIT вошел в массы, можно будет сильно не извращаться.
>5) Не используйте перечисления там, где достаточно обычной переменной целого типа

Я не знаю, как это устроено в Java и в Davlik, но в C enum всегда при компиляции становится обычным int. Неужели для явы это не так?
Это рекомендация с оф.сайта.
в офф гайдаг было напсиано, что enum тяжеловеснее чем просто константа.
но это было до 2.2 — как там в 2.2 пока сказать не могу

но использование enum, как известно, дает типизацию константам.

Но если посмотреть на стандартные класс — они нигде не юзают enum только константы
не так — енумы превращаются в классы, причём достаточно большие — поэтому, собственно, их и не рекомендуют использовать. подробнее — на офсайте.
Спасибо за статью, руки зачесались написать небольшой проектик под Android :)
Пожалуйста.
поздравляю, вы делаете успехи — в этой статье явных ошибок заметно меньше
замечания:
диалоги лучше показывать через showDialog

>Их также можно расширить на основе книг Effective Java — Joshua Bloch
многие советы Блоха для андроида, увы, не только неприменимы, но и вредны — например «preffer interfaces over implementation»

>Цвет задается в формате ARGB
и не только — возможны rgb, argb, rrggbb, aarrggbb

>Нужно просто скопировать нужные файлы в папку /res/raw (форматы WAV, AAC, MP3, WMA, AMR, OGG, MIDI).
wma может андроидом и не поддерживаться

>Класс содержит статический экземпляр MediaPlayer, что позволяет не создавать отдельный проект для каждого запуска звукового ресурса.
эээ… а я в коде вижу
mp = MediaPlayer.create(context, resource);
+код не thread-safe
upd:
похвалил я вас, как вижу, зря — код-то не ваш, а из книги. Более того:
Copyrights apply to this code. It may not be used to create training material, courses, books, articles, and the like.
Я указал, что код из книги.
как по мне, так указано очень неявно
В начале поста я указал, что пример из книги. (строчка 3)
Как это указать более явно? Что Вы порекомендуете?
>В начале поста я указал, что пример из книги. (строчка 3)
Как это указать более явно? Что Вы порекомендуете?
описание из книги!=полный копипаст кода

>Как это указать более явно? Что Вы порекомендуете?
написать как есть — рассматриваемый код взят из такой-то книги под такой-то лицензией
Это не совсем оригинальный код из книги. Я читал книгу, учился, писал.
Скажите пожалуйста, а как правильно использовать код под таким копирайтом в своих постах?

Я думаю, что если я вносил в код изменения, то я могу его использовать.
>Скажите пожалуйста, а как правильно использовать код под таким копирайтом в своих постах?
этот код — скорее всего никак, ибо у него явно максимально жёстка лицензия

>Я думаю, что если я вносил в код изменения, то я могу его использовать.
сильно сомневаюсь — если уж в чистом виде запрещено использовать, то вряд ли разрешено и в изменённом
Большое спасибо. Буду внимательнее к копирайтам.
>диалоги лучше показывать через showDialog

как-то не совсем удобно его юзать.
если надо показать несколько диалогов — то приходится завести несколько констант
потмо написать switch в showDialog
и еще один в prepareDialog

много лишних действий.
я понимаю, что он там кеширует диалоги и все такое, но уж сильно неудобно…

Это самый правильный путь, зато при смене ориентации экрана, эти диалоги остаются на экране, а если создавать обычным способом, придется отслеживать все это дело. Вообще лучше именно так создавать ))
НЛО прилетело и опубликовало эту надпись здесь
>При открытии файлов ресурсов в редакторе может возникнуть ошибка…

Гадский баг, который появился после обновления эклипса до версии 3.6. Вылечился добавлением неймспейса к тэгу ресурса:

<resources xmlns:android="ht_tp://schemas.android.com/apk/res/android">

ht_tp -> http, борьба с парсером.
Спасибо. В избранное.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации