Kotlin для Android: упрощаем работу со слабыми ссылками в асинхронных вызовах

1) Возможно, стоило озаглавить "… в Java и Kotlin". Конечно, получилось вроде "безопасная обработке асинхронных вызовов в той же части кода, в которой этот вызов был совершен", но это немного жирно для заголовка. Да и тут представлен именно подход.

2) MVP — это еще одно равноправное решение данной проблемы. В своем проекте я использую Clean Architecture (VIP). Очень удобно декларировать слабую ссылку того же презентора на view через делегирование:

var view by weak<View>()

В Swift я бы написал

weak var view: View?

3) thisRef в лямбду захватывается сильной ссылкой. Очистится ли сама ссылка? Cложно поверить, что GC очистит слабую ссылку на валидный объект.

4) По-хорошему количество новых методов соответствовать количеству разных классов, на объектах которого вызывается данный метод.

все же это просто инструмент

Согласен.

Kotlin для Android: упрощаем работу со слабыми ссылками в асинхронных вызовах

Смысл в том, чтобы обрабатывать асинхронные вызовы в одном месте кода. Не вижу решения проблемы через static inner (или просто static) классы.

Поизучал лямбды в Java 8. Они действительно ведут себя лучше, чем анонимные классы, т.е. захватывают контекст только по потребности. Обновлю статью.

12 недельный скетч марафон, сделать или умереть

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

В каждом макете чувствуется какое-то веяние ubuntu или популярных китайских оболочек для Android типа MIUI (субъективно)

Method Swizzling и Swift: но есть нюанс

Подождите, тут предлагается адаптированная под русского пользователя копия статьи с NSHipster (структура повествования + код, за исключением названий класса и пары методов), плюс в конце дополнение, что чтобы это работало, то надо чтобы класс и метод был виден в obj-Runtime.
По мне это перевод + чуть-чуть автора.

Магия IBDesignable или расширяем функциональность Interface Builder в Xcode

По мне явное указание лучше и может исключить некоторые ошибки при рефакторинге. Для любителей conventions конечно будет норм.

Магия IBDesignable или расширяем функциональность Interface Builder в Xcode

Сталкивался с этой проблемой в Xcode 6. Кинул это дело до выхода 7. Сейчас поведение стабильно. Ребилдится только при изменении исходного кода приложения или лайаута текущего контроллера. И только если открыт сам билдер.