All streams
Search
Write a publication
Pull to refresh
2
0
Send message
У Санделла есть статья на эту тему:
www.swiftbysundell.com/tips/picking-between-for-and-for-each
Я бы еще все for in заменил, где можно, на forEach, с функциями первого класса
for toIndex in graph.adjacencyList[fromIndex].flatMap { $0.toIndices } where !visited.contains(toIndex) {
      stack.insert(toIndex, at: 0)
}
Спасибо, интересно. А как у Flutter с гейм-разработкой? Или все-таки не его/не предназначен?
Во время действия Grace period система iOS продолжает бомбить пользователя о том, что у него проблемы с биллингом, что ему нужно зайти в настройки и перепривязать свою карту. Это самый простой способ, достаточно просто его включить в iTunes и указать то количество дней, которое вы готовы дать пользователю бесплатно пользоваться вашим контентом, пока он налаживает биллинг.

Кол-во дней зависит от срока подписки, указать их нельзя, можно только включить/выключить.

The length of the grace period depends on the subscription duration.
help.apple.com/app-store-connect/#/dev58bda3212
У этого тестового сервера похоже есть лимит на кол-во запросов, о котором не сказано ни в одной документации: если повесить автотесты на совершение каких-то покупок, то мы у себя в компании часто нарывались на этот лимит, и у нас просто сервер Apple на Sandbox переставал нам отвечать, а мы долго и мучительно пытались понять что мы делаем не так.

Testing auto-renewable subscriptions

Duration times are shortened when test your auto-renewable subscriptions. Additionally, test subscriptions only auto-renew a maximum of six times.
help.apple.com/app-store-connect/#/dev7e89e149d
Спасибо, есть над чем задуматься. Хотя, дизайнеры скорее предпочтут кастомный вью стандартному алерту, с точки зрения хотя бы эстетики. Другое дело, что разработчикам проще использовать алерт и, возможно, это они когда-то убедили дизайнеров, что это по гайду )
Спасибо, в закладки )
Вы говорите про copy on write, array и slice ссылаются на одну и туже область памяти с данными, для оптимизации их хранения и доступа.
Спасибо, забавно. Только в 4 примере не «держит ссылку даже после окончания “срока службы” исходного массива», а ссылается на другой array в стеке, т.к. это value type.
Спасибо за статью.

В методе делегата все-таки лучше обновлять те данные, которые изменились, а не всю collectionView. Например, так: collectionView.reloadRows(at: [indexPath!], with: .automatic)

Еще можно задействовать методы делегата controllerWillChangeContent и controllerDidChangeContent, в которых выполнить beginUpdates и endUpdates.

Также можно, в зависимости от NSFetchedResultsChangeType, выполнить insertRows, deleteRows или reloadRows.
1. Не обязательно включать очередной pod в проект, достаточно установить SwiftLint локально
2. Пользуйтесь debugPrint вместо print, если он так нужен
3. Большой кусок кода во viewDidLoad на скриншоте так себе code style — лучше разбить на несколько приватных функций по функционалу

p.s.
Про SwiftLint было уже прилично статей на Хабре. Не увидел в статье других «статических анализаторов кода и опыте их применения», как написано в заголовке
Например, вот:

image
Видимо потому, что смотрели не последнюю редакцию книги :)

Цитата:
«Chapter 6. Working with Generics
I received a lot of feedback about protocol-oriented programming after the first version of this book was released. Almost all of this feedback was very positive; however, there was one conversation that I had, with one of the smartest people that I have had the privilege to meet, about what protocol-oriented programming was. One of the comments that he made was that I should not forget about generic programming. The conversation that we had about generic programming really stuck with me and when I had the opportunity to write the new version of this book, I took that opportunity to include this chapter on generics.»
Есть целая книжка про это: Hoffman, Jon. «Protocol-Oriented Programming with Swift». Рекомендую.
Спасибо за статью.
А почему используете .receive(on: RunLoop.main) вместо .receive(on: DispatchQueue.main)?
Давайте рассмотрим док-во от противного. Представим, что большинство людей незрячие и все приложения сделаны под Voice Over с доп. функциями для небольшого числа зрячих. Могут ли зрячие ими пользоваться? Безусловно. Удобно ли им, по сравнению с визуальным интерфейсом? Вряд ли (не говоря уже о скорости восприятия информации).
Общее в том, что это все-таки разные интерфейсы, как ни крути. Понятно, что для разработчика это всего лишь фича (а для компании — пиар, чего уж там). Было бы интересно услышать мнение product менеджера. Уверен, здесь поле непаханое, чтобы развернуться и сделать спец. версию. Но бизнесу это не нужно, это да, слишком мала доля ЦА. А нужно ли это ЦА — для этого нужно вначале попробовать.

Information

Rating
6,216-th
Registered
Activity