Невозможно реализовать Firebase в нескольких модулях Swift - PullRequest
2 голосов
/ 19 июня 2020

Это для Firebase 6.26.0 и 6.27.0 (я пробовал оба по причинам, которые станут понятны)

У меня есть приложение Swift, которое я пытаюсь разложить на модули из текущего монолита , но до сих пор мне не удалось раскрыть классы Firebase в модулях (т.е. фреймворках), установив модули Firebase в каждом отдельном модуле. Он будет работать только тогда, когда есть только одна существующая библиотека и когда эта библиотека установлена ​​в целевом приложении, где она создается в AppDelegate.

Кто-нибудь знает, можно ли реализовать Firebase для нескольких модулей в единое рабочее пространство?

Ожидаемые результаты

Эти классы Firebase будут доступны для всех модулей в многомодульном приложении Swift с одной или несколькими копиями библиотеки Firebase. , позволяя всем модулям вызывать методы Firebase и реализовывать классы Firebase в одном глобальном экземпляре FirebaseApp.

Фактические результаты

Либо Firebase отказывается создавать экземпляр из-за наличия из более чем одной библиотеки Firebase в рабочей области или, если присутствует только одна библиотека, классы Firebase не могут быть доступны другим модулям в рабочей области.

Что я сделал

  1. Установлены отдельные модули Firebase в каждом модуле, необходимом дайте им. При запуске я получил эту ошибку:
    .
    The default FirebaseApp instance must be configured before the defaultFirebaseApp instance can be initialized
    .
    Согласно ответу члена команды Firebase в другом сообщении StackOverflow , это вызвано наличием из более чем одной библиотеки Firebase в рабочей области.

  2. Установлен только один модуль для создания модуля FirebaseProxy, который может совместно использоваться как целью приложения, так и всеми другими модулями. Используя typealiases и расширения, я смог позволить классам реализовывать классы Firebase без необходимости открывать фактическую библиотеку Firebase, например:

    import Firebase

    public typealias FirebaseUserProxy = Firebase.User
    public extension FirebaseUserProxy {}

Таким образом, реализующий класс мог используйте тип Firebase.User, используя вместо него FirebaseUserProxy, и без необходимости прямого доступа к библиотеке Firebase.
.
Однако были некоторые проксированные классы, которые все еще, казалось, требовали доступа к полной библиотеке . (Мой мозг немного запутался от всего этого, поэтому я забыл, какие именно, я считаю, что это был FirebaseApp.) Но даже использование @_exposed import Firebase в определении прокси не помогло, и я получил только сообщение Missing required module 'Firebase'.

То же решение, что и в # 2, но с использованием use_frameworks! :linkage => :static в моем Podfile. Не повезло. И да, я пробовал использовать $(SRCROOT)/Stat в настройках построения путей поиска в моих фреймворках.

Наконец, я попытался интегрировать библиотеку прямо в свой проект без использования Cocoapods. Здесь я использовал 6.26.0, так как ссылка на загрузку Firebase с 6.27.0 в URL-адресе привела к сообщению Not Found, поэтому я вручную изменил его на 6.26.0, и он загрузился нормально
.
Я установил библиотеки в приложении и в другом модуле, надеясь, что каким-то образом этот метод закроет каждую библиотеку от другой, но в итоге выдает то же сообщение об ошибке, что и в # 1 ... The default FirebaseApp...
.
Я также попытался использовать метод прокси из # 2, но это привело к той же ошибке.
.
Мне пришлось установить :linkage => :static в моем Podfile, чтобы установленные модули хорошо работали с интегрированной библиотекой. Выключение привело к ошибке.

Альтернативы

  1. Если я не могу заставить это работать, я возможно, придется реорганизовать мой код, чтобы код, зависящий от Firebase, существовал в самом приложении, а не в отдельном модуле фреймворка. Это не повлияет на функциональность, но нарушит архитектуру и сделает код более запутанным и хрупким.

  2. В репозитории Firebase git есть решение (я не пробовал), предлагающий вернуться к версии 6.15.0. Однако я не хочу этого делать, так как самая последняя версия - 6.27. 0, и я не хочу, чтобы у меня была возможность выполнить обновление и рискнуть использовать более старую версию, которая, несомненно, рано или поздно выйдет из строя.

Наконец

Прискорбно, что такой широко используемый и жизненно важный инструмент можно использовать только в монолитных приложениях, что в основном ограничивает разработчиков одним, часто неоптимальным, типом архитектуры. Я что-то упустил? Может быть. Это будет не в первый раз. Но если кто-то может найти выход из моей дилеммы, я был бы счастлив купить вам пиво и, учитывая текущие правила социального дистанцирования, выпить его от вашего имени.

...