mindbox-cloud / ios-sdk Goto Github PK

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/checkout digest to 0ad4b8f

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency cocoapods to v1.15.2
• Update dependency fastlane to v2.220.0

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Столкнулся с такой проблемой, нет возможности подключить SDK в проект написаный на объектив-с, насколько я понял нахватает @objc аттрибутов

Привет. Мы подключаем к нашему проекту сразу две зависимости с именем ios-sdk:

• https://github.com/mindbox-cloud/ios-sdk.git, ~>2.8.6
• https://github.com/inappstory/ios-sdk, ~>1.23.2

При попытке зарезолвить граф SPM падает с ошибкой:

error: Dependencies could not be resolved because root depends on 'ios-sdk' 2.8.6..<3.0.0 and root depends on 'ios-sdk' 1.23.2..<2.0.0.

Это из-за того, что SPM в качестве названия зависимости использует имя репозитория, причем только последнюю часть. Пруф. В нашем случае у двух реп она одинаковая, ios-sdk.

Из-за этого мы не можем интегрировать обе либы через SPM одновременно.

Предлагаю вам переименовать репозиторий. Старая ссылка останется валидной и будет редиректить на новый адрес, так в документации Renaming a repository сказано. Это гарантирует, что ни у кого из текущих пользователей библиотеки ничего не сломается. Ну и SPM начнет вас различать.

Аналогичная Issue во втором репозитории

Окружение:

• xcode 14
• устройство с iOS16
• Mindbox 2.1.4

Шаги воспроизведения:

• запустить приложение
• свернуть приложение
• подождать 30-40 сек

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

• приложение не терминируется и продолжает работать в фоне

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

• приложение терминируется

Лог:

2022-10-05 13:58:31.262563+0500 AppName[469:9669] [General] [cloud.Mindbox 🤖 [ℹ️] 
UIApplication.didEnterBackgroundNotification
]
2022-10-05 13:58:31.262716+0500 AppName[469:9669] [Background] [cloud.Mindbox 🕳 [ℹ️] 
Beginnig BackgroundTask
]
2022-10-05 13:58:31.270289+0500 AppName[469:9669] [Background] [cloud.Mindbox 🕳 [ℹ️] 
Did begin BackgroundTaskID: UIBackgroundTaskIdentifier(rawValue: 100)
]
2022-10-05 13:58:31.270654+0500 AppName[469:9669] [Background] [cloud.Mindbox 🕳 [ℹ️] 
BackgroundTimeRemaining: 1.7976931348623157e+308
]
2022-10-05 13:58:31.271264+0500 AppName[469:9669] [Background] [cloud.Mindbox 🕳 [ℹ️] 
Scheduled BGAppRefreshTaskRequest with beginDate: Optional(2022-10-05 09:00:31 +0000)
]
2022-10-05 13:58:31.271476+0500 AppName[469:9669] [Background] [cloud.Mindbox 🕳 [ℹ️] 
Scheduled SendEventsBGProcessingTaskRequest
]
2022-10-05 13:58:31.271704+0500 AppName[469:9669] [Database] [cloud.Mindbox 📖 [ℹ️] 
Counting deprecated elements
]
2022-10-05 13:58:31.272046+0500 AppName[469:9669] [Database] [cloud.Mindbox 📖 [ℹ️] 
Deprecated Events did count: 0
]

2022-10-05 13:59:06.045257+0500 AppName[469:9669] [BackgroundTask] Background Task 100 ("F68EDFF3-51E3-432E-BB31-8CB4135A3062"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.
Message from debugger: Terminated due to signal 9

Можно-ли начать распространять релизы в виде архива XCFramework-а?

Привет, встретил проблему с ресайзом картинок в Rich Push, если использовать SDK:

Файл: MindboxNotificationService метод: createImageView

• в коде есть ограничение на 300 поинтов по высоте
• выставлен contentMode = .scaleAspectFill

Картинки, которые использовал для теста:

• https://happypik.ru/wp-content/uploads/2019/09/top4.jpg
• https://solomonvet.ru/uploads/images/blog/bolezni-kastrirovannyh-kotov-txt.jpg
• https://koshka.top/uploads/posts/2021-12/1639989820_2-koshka-top-p-lits-kotov-2.jpg
• https://www.purina.ru/sites/default/files/2020-08/vibor-sobak.jpg

Вот что получилось:

Далее я попробовал немного переписать логику выставления констрейнтов, вот что получилось:

Доступа к созданию ПР у меня нет, но вот так выглядят изменения:

Сейчас нам на проекте приходится делать форк и затягивать его с исправлениями, можно ли это как то поправить в будущем релизе?

Crash on NSManagedObjectContext

iOS 14, 15, 16
Mindbox 2.4.0

В версии 2.4.2 столкнулись с проблемой переиспользование методов жизненного цикла приложения. В файле MindboxAppDelegate.swift для методов вы используете public. Эти методы нам нужны в приложении, не могли бы вы использовать open вместо public, иначе у нас не работает приложение и мы не можем override использовать.

public func applicationWillEnterForeground(_ application: UIApplication) {
   Logger.common(message: "Enter foreground", level: .info, category: .general)
}

public func applicationDidEnterBackground(_ application: UIApplication) {
    Logger.common(message: "Enter background", level: .info, category: .general)
}
    
public func applicationWillTerminate(_ application: UIApplication) {
    Logger.common(message: "App is closed", level: .info, category: .general)
}
    
public func applicationDidBecomeActive(_ application: UIApplication) {
     Logger.common(message: "App is active", level: .info, category: .general)
}

Логгеры это конечно хорошо, но в версии 2.4.1 получаем вот такое

откатил до 2.4.0 там все ок

.Хочу получать id от mindBox, для этого создала в appDelegate конфигурацию, но при инициализации Mindbox.shared.initialization(configuration: configuration) выходит ошибка Thread 1: Fatal error: containerURL not found for group от MBUtilitesFetcher
. Почему так может быть, помогите пожалуйста

Ошибка происходит только на реальном девайсе, на симуляторе ее нет

Crash on MBLoggerCoreDataManager.saveContext

iOS 17
Mindbox 2.8.5

Last Exception Backtrace:
0 CoreFoundation 0x19ca065e0 __exceptionPreprocess + 164 (NSException.m:249)
1 libobjc.A.dylib 0x194d3bc00 objc_exception_throw + 60 (objc-exception.mm:356)
2 CoreData 0x1a4bb9410 -[NSPersistentStoreCoordinator _introspectLastErrorAndThrow] + 120 (NSPersistentStoreCoordinator.m:0)
3 CoreData 0x1a4aa3fbc __65-[NSPersistentStoreCoordinator executeRequest:withContext:error:]block_invoke.541 + 680 (NSPersistentStoreCoordinator.m:0)
4 CoreData 0x1a4aa3c2c -[NSPersistentStoreCoordinator routeHeavyweightBlock:] + 264 (NSPersistentStoreCoordinator.m:641)
5 CoreData 0x1a4a805b4 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 1048 (NSPersistentStoreCoordinator.m:2768)
6 CoreData 0x1a4a805d8 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 1084 (NSPersistentStoreCoordinator.m:3425)
7 CoreData 0x1a4a71e84 -[NSManagedObjectContext save:] + 972 (NSManagedObjectContext.m:1625)
8 MindboxNotificationServiceExtension 0x100afbeb4 specialized MBLoggerCoreDataManager.saveContext(:) + 68 (MBLoggerCoreDataManager.swift:175)
9 MindboxNotificationServiceExtension 0x100af8e80 MBLoggerCoreDataManager.saveContext(:) + 12 (:0)
10 MindboxNotificationServiceExtension 0x100af8e80 MBLoggerCoreDataManager.saveEvent(withContext:) + 28 (MBLoggerCoreDataManager.swift:170)
11 MindboxNotificationServiceExtension 0x100af8e80 closure #1 in MBLoggerCoreDataManager.create(message:timestamp:) + 232 (MBLoggerCoreDataManager.swift:82)
12 MindboxNotificationServiceExtension 0x100afa378 partial apply for closure #1 in MBLoggerCoreDataManager.create(message:timestamp:) + 20 (:0)
13 MindboxNotificationServiceExtension 0x100afc448 specialized thunk for @callee_guaranteed () -> (@out A, @error @owned Error) + 4 (:0)
14 MindboxNotificationServiceExtension 0x100afc448 partial apply for specialized thunk for @callee_guaranteed () -> (@out A, @error @owned Error) + 20
15 MindboxNotificationServiceExtension 0x100afc664 partial apply for specialized thunk for @callee_guaranteed () -> (@out A, @error @owned Error) + 12
16 MindboxNotificationServiceExtension 0x100afb3a8 specialized closure #1 in #1 in NSManagedObjectContext._performAndWaitHelper(fn:execute:rescue:) + 44 (NSManagedObjectContext+Extension.swift:33)
17 MindboxNotificationServiceExtension 0x100afc338 thunk for @callee_guaranteed () -> () + 4 (:0)
18 MindboxNotificationServiceExtension 0x100afc338 partial apply for thunk for @callee_guaranteed () -> () + 20
19 MindboxNotificationServiceExtension 0x100afb370 thunk for @escaping @callee_guaranteed () -> () + 20 (:0)
20 CoreData 0x1a4a7d8ec developerSubmittedBlockToNSManagedObjectContextPerform + 156 (NSManagedObjectContext.m:3975)
21 libdispatch.dylib 0x1a4847300 _dispatch_client_callout + 20 (object.m:561)
22 libdispatch.dylib 0x1a48566b4 dispatch_lane_barrier_sync_invoke_and_complete + 56 (queue.c:1085)
23 CoreData 0x1a4a7d7f8 -[NSManagedObjectContext performBlockAndWait:] + 264 (NSManagedObjectContext.m:4092)
24 MindboxNotificationServiceExtension 0x100af8fb8 implicit closure #2 in implicit closure #1 in NSManagedObjectContext.performAndWait(:) + 20 (NSManagedObjectContext+Extension.swift:15)
25 MindboxNotificationServiceExtension 0x100af8fb8 specialized closure #1 in NSManagedObjectContext._performAndWaitHelper(fn:execute:rescue:) + 20 (NSManagedObjectContext+Extension.swift:31)
26 MindboxNotificationServiceExtension 0x100af8fb8 specialized NSManagedObjectContext.performAndWaitHelper(fn:execute:rescue:) + 20 (NSManagedObjectContext+Extension.swift:30)
27 MindboxNotificationServiceExtension 0x100af8fb8 specialized NSManagedObjectContext.performAndWait(:) + 264 (NSManagedObjectContext+Extension.swift:14)
28 MindboxNotificationServiceExtension 0x100af8aa0 MBLoggerCoreDataManager.create(message:timestamp:) + 208 (MBLoggerCoreDataManager.swift:78)
29 MindboxNotificationServiceExtension 0x100af7534 MBLogger.writeToCD(message:timestamp:) + 48 (MBLogger.swift:120)
30 MindboxNotificationServiceExtension 0x100af7534 closure #1 in MBLogger.log(level:message:date:category:subsystem:) + 80 (MBLogger.swift:50)
31 MindboxNotificationServiceExtension 0x100af7598 thunk for @escaping @callee_guaranteed @sendable () -> () + 28 (:0)
32 libdispatch.dylib 0x1a48456a8 _dispatch_call_block_and_release + 32 (init.c:1530)
33 libdispatch.dylib 0x1a4847300 _dispatch_client_callout + 20 (object.m:561)
34 libdispatch.dylib 0x1a484e894 _dispatch_lane_serial_drain + 748 (queue.c:3885)
35 libdispatch.dylib 0x1a484f3c4 _dispatch_lane_invoke + 380 (queue.c:3976)
36 libdispatch.dylib 0x1a485a004 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:6913)
37 libdispatch.dylib 0x1a4859878 _dispatch_workloop_worker_thread + 404 (queue.c:6507)
38 libsystem_pthread.dylib 0x205afe964 _pthread_wqthread + 288 (pthread.c:2629)
39 libsystem_pthread.dylib 0x205afea04 start_wqthread + 8

Could you rename repository? I can not use it in SPM because I have two Libs with name ios-sdk.
Could you rename it to Mindbox-ios-sdk for example?

Было бы здорово подключать sdk не только через Cocoapods, а еще и через Swift Package Manager.

Привет!
В приложении пользователь может отключить пуш уведомления, не делая системный нативный запрет через настройки iOS.
В SDK есть метод:
/// Use this method to notify Mindbox for notification request authorization changes. public func notificationsRequestAuthorization(granted: Bool) { coreController?.checkNotificationStatus(granted: granted) }
Куда можно послать false и от SDK уйдет запрос, что у юзера пуши отключены, все ок.
Но проблема в том, что SDK еще и сама при инициализации чекает статус пушей и посылает на сервер новые данные, основываясь на UNAuthorizationStatus.authorized. Что приводит к тому, что при перезаходе в аппу (при инициализации SDK) на сервер уходит, что юзер разрешил пуши.

Возможно нужно сделать параметр в конфигурации для отключения автоматической проверки разрешения уведомления (В repeatInitialization не будет вызываться checkNotificationStatus()), тогда SDK будет основываться только на методе notificationsRequestAuthorization(granted: Bool), который вызывает разработчик приложения.