Pull to refresh

Comments 20

Не нужно выделяться из общей массы программ, пожалуйста. Интерфейс должен быть стандартным и привычным.
Это совсем не исключает наличие кастомных компонентов, и уж точно не означает что девелоперы не должны уметь их писать.
Вы же против крайностей?
Хорошая статья, но именование переменных оставляет желать лучшего.
Контекст доступен через getContext();, но если уж хранить его отдельно, тогда context.getApplicationContext();
А еще, по моему мнению, сигнал о завершении скрытия ленты лучше посылать через обычный листенер, ну или хэндлер. В данном примере такое событие слишком мелкое, чтобы сообщать о нем всем. Ну а если уж действительно нужно сообщение — то его можно отправить из листенера. Лишний код и лишняя архетектура, но зато можно переюзать и красиво:)
Идея неплоха.
Уход от GUI Guidelines и создание своих контролов — спорно, но приемлемо.
Страшненькое именование, паблик переменные, использование классовых Float — плохо, но на общую суть не влияет.
Хендлер и меседжи вместо runOnUiThread — велосипед, незнание основ.
Вечный цикл со слипами в MyTimer — говнокод.
Хендлер и меседжи вместо runOnUiThread — велосипед, незнание основ.


public final void runOnUiThread(Runnable action) {
        if (Thread.currentThread() != mUiThread) {
            mHandler.post(action);
        } else {
            action.run();
        }
    }


на самом деле не все так страшно, в остальном жирный плюс
В разных источниках встречал: активность, форма, окно. Мне больше нравится второй вариант, но тем не менее склоняюсь к первому, наиболее близкому к оригиналу.
думаю будет лучше оставлять в тексте «activity» в таком случае
UFO just landed and posted this here
По треду на инстанс компонента ради таймера? О_О
Пример не должен учить плохому :)
Вместо такого ада с потоками можно хотя бы тот же countdown готовый использовать.
В избранное однозначно. Буду показывать джуниорам в качестве примера как не надо программировать UI под Android в частности и на Java в целом.
Примерно такие же мысли были :D
если пример претендует на нечто действительно рабочее, а не «вот как можно сделать для моего девайса», то больше, чем 3- я бы не поставил. действительно много велосипедов, нет адаптации под разные экраны, переопределение onMeasure будет работать не всегда правильно. в общем, как то не очень.
Хорошо описаный пример. Спасибо. Как было замеченно, с кодистайлом недочеты есть. Но, покажу пример на своих уроках во ВШЭ.

А по сути комментариев, хочу заметить, что хватит разводить холивары на счет «гайдлайна по GUI». Хорошие качественные приложения всегда имеют наитивный интерфейс. Это основная задача дизайнеров. Наша задача, как специалистов своей области, реализовать качественный интерфейс. Возьмем для примера приложения Path, Foursquare, Facebook. В них ничего нет от гайдлайнов, пожалуй, кроме TitleBar, но это качественные приложения. Собирать приложения на стандартных котролах проще, но кастомизация развивает мышление. Да и пользователя не интерисуют гайдланы. Ему нужно чтобы «красиво и удобно и с анимацией», а разработчики упираются в гайдлайны, и это нормально, потому что мы живем этим — стандартами разработки.

Простите, накипело.
Sign up to leave a comment.

Articles