В своей статье хочу рассказать об очередной хитрости, которую можно довольно просто реализовать с помощью Gradle — переупаковке пакетов библиотек. Каждый, кто хоть чуть чуть работал с этой системой сборки, знает, что она автоматически умеет решать конфликты разных версий библиотек, а при желании можно повлиять на это, например зафорсить конкретную версию какой-нибудь библиотеки:

configurations.all {
    resolutionStrategy {
        force "org.ow2.asm:asm:7.2"
    }
}

К сожалению, это не всегда помогает решить проблему конфликта версий. Например, есть известная проблема, что некоторые устройства htc в прошивке уже имеют библиотеку gson и если ваша версия gson-а отличается от встроенной, то могут возникнуть проблемы, так как ClassLoader загрузит в память только один класс и в данном случае это будет системный.

Такая проблема также может возникнуть и при разработке библиотек. Если вы подключите в свой проект 2 библиотеки, использующие одну и ту же стороннюю библиотеку разных версий, например 1 и 2, то Gradle разрулит и возьмет самую новую версию, вторую. Но если в этой сторонней библиотеке нет обратной совместимости и вторая версия не может быть просто так использована вместо первой, то будут проблемы, которые наверняка будет очень сложно отследить по стектрейсу. Библиотека, ожидающая первую версию, получит классы второй и просто упадет.

Я столкнулся с конфликтом версий при написании градл плагина, в нем используется библиотека asm, которая и конфликтовала. После написания плагина, я проверил его работоспособность на тестовом проекте: все отлично, проверил на pet project-е, тоже все хорошо, но когда подключил к реальному рабочему проекту с кучей сторонних зависимостей, столкнулся с проблемой.

Решение проблемы под катом.

• Первая часть
• Пример на Github

В этой статье расскажу о том, как решал проблемы, с которыми столкнулся в предыдущей части при реализации проекта.

Во-первых, при анализе трансформируемого класса, нужно как-то понять, является ли этот класс наследником Activity или Fragment, чтобы с уверенностью сказать, что класс подходит для нашей трансформации.

Во-вторых, в трансформируемом .class файле для всех полей с аннотацией @State нужно явно определить тип, чтобы вызвать соответствующий метод у бандла для сохранения/восстановления состояния, а точно определить тип можно лишь проанализировав всех родителей класса и реализуемые ими интерфейсы.

Таким образом, нужно просто иметь возможность анализировать абстрактно синтаксическое дерево трансформируемых файлов.

• Вторая часть

Вместо вступления

Всё началось с того, что мне захотелось изучить тонкости настройки Gradle, понять его возможности в Android разработке (да и вообще). Начал с жизненного цикла и книги, постепенно писал простые таски, попробовал создать свой первый Gradle плагин (в buildSrc) и тут понеслось.

Решив сделать что-то, приближенное к реальному миру Android разработки, написал плагин, который парсит layout xml файлы разметки и создает по ним Java объект со ссылками на вьюхи. Затем побаловался с трансформацией манифеста приложения (того требовала реальная задача на рабочем проекте), так как после трансформации манифест занимал порядка 5к строк, а работать в IDE с таким xml файлом довольно тяжело.

Так я разобрался как генерировать код и ресурсы для Android проекта, но со временем захотелось чего-то большего. Появилась мысль, что было бы круто трансформировать AST (Abstract Syntax Tree) в compile time как это делает Groovy из-под коробки. Такое метапрограммирование открывает много возможностей, была бы фантазия.

Дабы теория не была просто теорией, я решил подкреплять изучение темы созданием чего-то полезного для Android разработки. Первое, что пришло на ум — сохранение состояния при пересоздании системных компонентов. Грубо говоря, сохранение переменных в Bundle максимально простым способом с минимальным бойлерплейтом.