RMCreative.ru - Блог Голосов: 1 Адрес блога: http://rmcreative.ru/feed/ Добавлен: 2008-06-12 21:34:00 блограйдером ZaiSL

Android: обрабатываем нажатие back в фрагментах

В Android-приложениях иногда требуется особым образом обработать нажатие кнопки back. Если у вас не используются фрагменты, всё просто. Перекрываем метод onBackPressed у Activity и делаем что нам нужно. Если же используются фрагменты и по нажатию back необходимо что-то поменять в фрагменте, обработку хочется сделать именно в нём.

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

Начнём с интерфейса для фрагментов. Готового в фреймворке нет, сделаем свой:

public interface OnBackPressedListener {
    public void onBackPressed();
}

Далее перекроем метод onBackPressed в нашем FragmentActivity:

public class MyActivity extends FragmentActivity {
    @Override
    public void onBackPressed() {
        FragmentManager fm = getSupportFragmentManager();
        OnBackPressedListener backPressedListener = null;
        for (Fragment fragment: fm.getFragments()) {
            if (fragment instanceof  OnBackPressedListener) {
                backPressedListener = (OnBackPressedListener) fragment;
                break;
            }
        }
 
        if (backPressedListener != null) {
             backPressedListener.onBackPressed();
        } else {
            super.onBackPressed();
        }
    }
}

Вытаскиваем все фрагменты, которые у нас есть. Ищем первый попавшийся, который реализует наш интерфейс OnBackPressedListener. Тут можно было придумать что-то, чтобы работать с несколькими обработчиками, но чаще всего он один. Если есть фрагмент, который реализует OnBackPressedListener, вызываем его единственный метод. Если нет — обрабатываем back как обычно.

Ну и, наконец, сам фрагмент:

public class MyFragment extends Fragment implements OnBackPressedListener {
    @Override
    public void onBackPressed() {
        // полезный код
    }
}

Плюс данного подхода в том, что можно, например, отнаследовать все наши activity от MyActivity и использовать OnBackPressedListener без каких-либо изменений в коде MyActivity.

Хорошие программисты и сложность

Частенько мне встречаются хорошие, на первый взгляд, программисты: они говорят правильные вещи, цитируют отцов основателей, критикуют плохие подходы. К сожалению, на практике они нередко оказываются не настолько хороши.

Чаще всего мешают им фанатичность, нетерпимость к альтернативам и полное отсутствие прагматичного подхода. От них часто можно услышать что-то вроде:

• Код надо обязательно покрыть юнит-тестами на 100%. В тестах надо делать моки через мок-фреймворк.
• Ни в коем случае нельзя писать связанный код.
• Всегда без исключений надо следовать SOLID, DRY, GRASP и т.д.
• Абсолютно все приложения надо строить по DDD.
• Для доступа к данным обязательно нужен крутой ORM.
• Писать документацию нет смысла, потому как она всегда отстаёт от кода. Код — лучшая документация.
• Если в коде есть комментарии, код недостаточно отрефакторен. Всегда можно разделить код и назвать методы так, чтобы отразить предметную область.
• Невозможно построить хорошую архитектуру без ООП.
• И так далее.

Знакомо? Всё это выливается в непрактичные решения, реальной целью которых является доказать собственную правоту и крутость сделав «как учат в умных книгах». Реальность при этом частенько не учитывается.

Не следует забывать, для чего на самом деле мы пишем код. А именно:

1. Чтобы он работал и решал поставленные задачи.
2. Чтобы его могли прочитать, осознать и изменить другие программисты.

Для пункта номер два следует вносить в код как можно меньше сложности. Оправдана она только в том случае, когда другого выхода нет. Можно проще — делайте проще.

Это не означает, что не надо изучать шаблоны проектирования, читать Фаулера и т.д. Надо. Просто во всём надо знать меру и не бросаться применять прочитанное с особым энтузиазмом и уж, тем более, не стоит это делать, если вы не понимаете, для чего это и как оно упростит вам жизнь (и упростит ли вообще).

Хорошие программисты и сложность

Частенько мне встречаются хорошие, на первый взгляд, программисты: они говорят правильные вещи, цитируют отцов основателей, критикуют плохие подходы. К сожалению, на практике они нередко оказываются не настолько хороши.

Чаще всего мешают им фанатичность, нетерпимость к альтернативам и полное отсутствие прагматичного подхода. От них часто можно услышать что-то вроде:

• Код надо обязательно покрыть юнит-тестами на 100%. В тестах надо делать моки через мок-фреймворк.
• Ни в коем случае нельзя писать связанный код.
• Всегда без исключений надо следовать SOLID, DRY, GRASP и т.д.
• Абсолютно все приложения надо строить по DDD.
• Для доступа к данным обязательно нужен крутой ORM.
• Писать документацию нет смысла, потому как она всегда отстаёт от кода. Код — лучшая документация.
• Если в коде есть комментарии, код недостаточно отрефакторен. Всегда можно разделить код и назвать методы так, чтобы отразить предметную область.
• Невозможно построить хорошую архитектуру без ООП.
• И так далее.

Знакомо? Всё это выливается в непрактичные решения, реальной целью которых является доказать собственную правоту и крутость сделав «как учат в умных книгах». Реальность при этом частенько не учитывается.

Не следует забывать, для чего на самом деле мы пишем код. А именно:

1. Чтобы он работал и решал поставленные задачи.
2. Чтобы его могли прочитать, осознать и изменить другие программисты.

Для пункта номер два следует вносить в код как можно меньше сложности. Оправдана она только в том случае, когда другого выхода нет.

Это не означает, что не надо изучать шаблоны проектирования, читать Фаулера и т.д. Надо. Просто во всём надо знать меру и не бросаться применять прочитанное с особым энтузиазмом и уж, тем более, не стоит это делать, если вы не понимаете, для чего это и как оно упростит вам жизнь (и упростит ли вообще).

Yii 2.0 релиз

Свершилось! После трёх лет работы и почти десяти тысячи коммитов за авторством более 300 человек мы выпустили Yii 2.0.

Перевод официального анонса читайте на хабре

Сюрреализм на JavaScript

Вышла довольно занятная свободно распространяемая книга Бахирева Алексея «Сюрреализм на JavaScript».

В ней содержатся различные рекомендации, советы и идеи касательно разработки сложного фронтенда на JavaScript. Рассматривается архитектура игровых движков и проблемы создания веб-игр и веб-приложений. Так же в книге приведено множество рекомендаций касательно вёрстки интерфейсов под различные устройства и особенностей разработки на JavaScript под различные платформы.

• Скачать в PDF.
• Скачать в epub.
• Читать онлайн.
• Другие варианты и печатная версия.