Сегодня 14 февраля, пятница ГлавнаяНовостиО проектеЛичный кабинетПомощьКонтакты Сделать стартовойКарта сайтаНаписать администрации
Поиск по сайту
 
Ваше мнение
Какой рейтинг вас больше интересует?
 
 
 
 
 
Проголосовало: 7278
Кнопка
BlogRider.ru - Каталог блогов Рунета
получить код
RMCreative.ru - Блог
RMCreative.ru - Блог
Голосов: 1
Адрес блога: http://rmcreative.ru/feed/
Добавлен: 2008-06-12 21:34:00 блограйдером ZaiSL
 

Рекомендация HTML5

2014-10-29 15:00:38 (читать в оригинале)

Наконец-то, рекомендация HTML5 официально закончена. На сайте W3C можно почитать официальный анонс.

  • Полная спецификация


Рекомендация HTML5

2014-10-29 14:00:38 (читать в оригинале)

Наконец-то, рекомендация HTML5 официально закончена. На сайте W3C можно почитать официальный анонс.

  • Полная спецификация


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

2014-10-28 16:20:12 (читать в оригинале)

В 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.



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

2014-10-28 15:20:12 (читать в оригинале)

В 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.



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

2014-10-27 18:30:20 (читать в оригинале)

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

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

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

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

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

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

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

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



Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ... 

 


Самый-самый блог
Блогер ЖЖ все стерпит
ЖЖ все стерпит
по количеству голосов (152) в категории «Истории»
Изменения рейтинга
Категория «Музыка»
Взлеты Топ 5
+382
399
Follow_through
+328
331
שימותו הקנאים
+320
334
Tomas50
+317
357
krodico
+307
359
Ланин Сергей
Падения Топ 5


Загрузка...Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.