Люди склонны лучше относиться к тем, кому они помогали, чем к тем, кто помогал им.
Здесь пользователю дают способ немного "улучшить" сервис. По-умолчанию данные пользователя уже заполнены, но он может их "улучшить", указать "верные" данные.
Люди чувствуют себя более счастливыми и удовлетворенными, когда считают, что имеют контроль над ситуацией.
А здесь пользователю дают что-то настроить под себя. Это может быть не только настройка профиля.
В данном случае кейс с профилем подходит под оба принципа привлечения внимания.
В новых версиях библиотек разработчики добавляют файлы PrivacyInfo.xcprivacy. Таким образом вам в своём файле не нужно указывать причину использования API
Если версия библиотеки не будет содержать файл PrivacyInfo.xcprivacy, вам прилётся самостоятельно указать причину использования API в файле PrivacyInfo.xcprivacy в своём проекте
Если укажете всю информацию в своём PrivacyInfo.xcprivacy, то можно не обновлять
Да, всё так. Спасибо за замечание! Дополню статью.
Согласен, физика во Flutter лишь эмулируют нативную.
Однако, рендеринг, шрифты, малое количество "нативных "iOS виджетов, и т.д. часто не является блокерами для использования Flutter в продакшене. Компаниям дешевле написать один код и 2 приложения и решить свою задачу. А то, что там какая-то странная анимация уже никого не волнует.
На мой взгляд, подключить девайс и посмотреть логи будет проще, чем распаковать apk через APKTool или что-то аналогичное, и затем изучать содержимое билда.
Конечно, для разработчика, который хоть что-то знает про мобилки, оба способа являются достаточно простыми.
В документации сказано, что файлы должны быть в библиотеках, которые используют определённые API. Соответственно, если API не используются - файл не нужен.
При сборке проекта файлы из библиотек собираются в один общий файл. Таким образом не важно, где лежат файлы.
Если приложение уже в сторе, надёжнее всего ориентироваться на письмо Apple. Ещё могу добавить, что файл обязательно нужен, если используются библиотеки, перечисленные здесь. Ну, и, дополнительно, можно прогнать свой проект скриптом, на который я ссылался в статье. Он подсветит классы, которые используют api, попадащие под privacy.
Мне кажется, “ненативность” происходит из-за того, что Flutter-приложения часто являются чем-то средним между iOS и Android. Это проявляется в виджетах, анимациях, жестах, UX.
Если пытаться реализовать интерфейс максимально похожим на нативный, то преимущества кроссплатформы теряются. В таком случае многие предпочтут использовать KMM.
Да, вы правы. С 1 мая приложение должно содержать PrivacyInfo.xcprivacy, если использует приватные API, иначе оно будет отклонено.
Спасибо за уточнение!
Предположу, что целью.
Здесь пользователю дают способ немного "улучшить" сервис. По-умолчанию данные пользователя уже заполнены, но он может их "улучшить", указать "верные" данные.
А здесь пользователю дают что-то настроить под себя. Это может быть не только настройка профиля.
В данном случае кейс с профилем подходит под оба принципа привлечения внимания.
В новых версиях библиотек разработчики добавляют файлы PrivacyInfo.xcprivacy. Таким образом вам в своём файле не нужно указывать причину использования API
Если версия библиотеки не будет содержать файл PrivacyInfo.xcprivacy, вам прилётся самостоятельно указать причину использования API в файле PrivacyInfo.xcprivacy в своём проекте
Если укажете всю информацию в своём PrivacyInfo.xcprivacy, то можно не обновлять
Да, всё так. Спасибо за замечание! Дополню статью.
Реклама разработки под заказ?
Это не так, я абсолютно не заинтересован в рекламе. Тем более я работаю с продуктами.
А в чем проявляется агитация?
Да. Но, сложность 666 относится к APKTool
Согласен, физика во Flutter лишь эмулируют нативную.
Однако, рендеринг, шрифты, малое количество "нативных "iOS виджетов, и т.д. часто не является блокерами для использования Flutter в продакшене. Компаниям дешевле написать один код и 2 приложения и решить свою задачу. А то, что там какая-то странная анимация уже никого не волнует.
Пункт с Show Layout Bounds есть в статье.
А вот про Profile HWUI Rendering я даже не подумал, спасибо!
APKTool даёт больше информации: классы, расшифрованный манифест и т.д.
Но, если цель - только определить flutter, то zip хватает.
Я тоже написал около недели назад. Всё это время ждал модерацию, т.к. статья сначала попадает в песочницу
На мой взгляд, подключить девайс и посмотреть логи будет проще, чем распаковать apk через APKTool или что-то аналогичное, и затем изучать содержимое билда.
Конечно, для разработчика, который хоть что-то знает про мобилки, оба способа являются достаточно простыми.
Спасибо за отзыв!
В документации сказано, что файлы должны быть в библиотеках, которые используют определённые API. Соответственно, если API не используются - файл не нужен.
При сборке проекта файлы из библиотек собираются в один общий файл. Таким образом не важно, где лежат файлы.
Если приложение уже в сторе, надёжнее всего ориентироваться на письмо Apple. Ещё могу добавить, что файл обязательно нужен, если используются библиотеки, перечисленные здесь. Ну, и, дополнительно, можно прогнать свой проект скриптом, на который я ссылался в статье. Он подсветит классы, которые используют api, попадащие под privacy.
Мне кажется, “ненативность” происходит из-за того, что Flutter-приложения часто являются чем-то средним между iOS и Android. Это проявляется в виджетах, анимациях, жестах, UX.
Если пытаться реализовать интерфейс максимально похожим на нативный, то преимущества кроссплатформы теряются. В таком случае многие предпочтут использовать KMM.