diff --git a/_i18n/en/factors/prefer-local-over-remote.md b/_i18n/en/factors/prefer-local-over-remote.md index 829811d..34c9986 100644 --- a/_i18n/en/factors/prefer-local-over-remote.md +++ b/_i18n/en/factors/prefer-local-over-remote.md @@ -15,7 +15,7 @@ Most iOS apps require some kind of backend for certain tasks, like authenticatio All parts of the app that don't necessarily **need** an internet connection (e.g. login) should work without any internet connection at all: -- Your app's startup screen ([that shouldn't exist in the first place](https://developer.apple.com/ios/human-interface-guidelines/icons-and-images/launch-screen/)) should never wait for the first successful web response, as this causes bad UX for users with a spotty internet connection. +- Your app's startup screen ([that shouldn't exist in the first place](https://developer.apple.com/design/human-interface-guidelines/patterns/launching/)) should never wait for the first successful web response, as this causes bad UX for users with a spotty internet connection. - If your app requires an internet connection for everything (e.g. social networking app or ride sharing app), your app should still work (in read-only mode) without an internet connection to access historic data (e.g. recent rides, recent direct messages). - Any feature of your app that needs a working internet connection should show a clear error message that the server couldn't be reached. - As WiFi hotspots might require a login or confirmation of some sorts (e.g. hotel or airport), HTTPS requests will often get stuck and time-out after about a minute. Until Apple resolves this issue on a system level, we as developers have to make sure to properly handle those situations. diff --git a/_i18n/es/factors/persistence-of-data.md b/_i18n/es/factors/persistence-of-data.md index d671591..5197c20 100755 --- a/_i18n/es/factors/persistence-of-data.md +++ b/_i18n/es/factors/persistence-of-data.md @@ -1,6 +1,6 @@ Almacenar información y configuración de acuerdo a los lineamientos de Apple es crucial para el ciclo de vida de la aplicación, en particular cuando se refiere a la sincronización con iCloud, renovación del dispositivo telefónico y restauración de una copia de seguridad en el teléfono. -Asegurarse de seguir los lineamientos oficiales de Apple para [almacenamiento de información en iOS](https://developer.apple.com/icloud/documentation/data-storage/index.html): +Asegurarse de seguir los lineamientos oficiales de Apple para [almacenamiento de información en iOS](https://developer.apple.com/documentation/foundation/optimizing_your_app_s_data_for_icloud_backup): - `Documents`: Usar este directorio para contenido generado por el usuario, se genera una copia de respaldo del mismo. - `Caches`: Usar este directorio para información que puede ser regenerada. diff --git a/_i18n/es/factors/prefer-local-over-remote.md b/_i18n/es/factors/prefer-local-over-remote.md index 6827473..b65ce2a 100755 --- a/_i18n/es/factors/prefer-local-over-remote.md +++ b/_i18n/es/factors/prefer-local-over-remote.md @@ -15,7 +15,7 @@ La mayoría de aplicaciones iOS requieren algún tipo de back-end para ciertas t Todos los componentes de una aplicación que no necesariamente **necesitan** una conexión a internet (ej. login) deberían funcionar por completo aún sin estar conectados a la red: -- La pantalla de inicio de la aplicación ([que no debería existir en primer lugar](https://developer.apple.com/ios/human-interface-guidelines/icons-and-images/launch-screen/)) jamás debe esperar por una primera respuesta exitosa del servidor web, ya que esto causa una mala experiencia de usuario cuando la conexión a internet es mala. +- La pantalla de inicio de la aplicación ([que no debería existir en primer lugar](https://developer.apple.com/design/human-interface-guidelines/patterns/launching/)) jamás debe esperar por una primera respuesta exitosa del servidor web, ya que esto causa una mala experiencia de usuario cuando la conexión a internet es mala. - Si la aplicación requiere una conexión a internet para todo (ej. red social o aplicación de navegación), debería funcionar de todas maneras (en modo de solo lectura) sin una conexión a internet para acceder a información histórica (ej. viajes recientes, mensajería privada). - Toda característica de la aplicación que requiera una conexión a internet debería mostrar un mensaje de error claro sobre la incapacidad de conectarse al servidor. - Ya que los puntos de acceso WiFi podrían solicitar inicio de sesión o confirmación de algún tipo (ej. hotel o aeropuerto), las solicitudes HTTPS se atascarán con frecuencia y se invalidarán por time-out después de un minuto aproximadamente. Hasta que Apple resuelva este inconveniente a nivel del sistema, nosotros como desarrolladores tenemos que asegurar un manejo adecuado de estas situaciones. diff --git a/_i18n/ja/factors/prefer-local-over-remote.md b/_i18n/ja/factors/prefer-local-over-remote.md index 964b2e4..4017068 100644 --- a/_i18n/ja/factors/prefer-local-over-remote.md +++ b/_i18n/ja/factors/prefer-local-over-remote.md @@ -15,8 +15,8 @@ インターネット接続を**必ずしも必要としない**部分（ログインなど）はインターネット接続なしでも動作すべきです。 -- アプリの起動画面（[そもそも存在するべきではありません](https://developer.apple.com/ios/human-interface-guidelines/icons-and-images/launch-screen/)）は Web のレスポンスを待つべきではありません。これは不安定なインターネット接続が悪い UX を引き起こすためです。 +- アプリの起動画面（[そもそも存在するべきではありません](https://developer.apple.com/design/human-interface-guidelines/patterns/launching/)）は Web のレスポンスを待つべきではありません。これは不安定なインターネット接続が悪い UX を引き起こすためです。 - もしアプリのすべての機能（ソーシャルネットワーキングアプリやライドシェアアプリ）でインターネット接続が必要であっても、履歴データ（乗車履歴、ダイレクトメッセージなど）へのアクセスはインターネット接続なしで（読み取り専用モードで）動作すべきです。 - インターネット接続が必要なアプリではサーバーに接続できないという明確なエラーメッセージを表示すべきです。 -- Wi-Fi ホットスポットはログインや何らかの確認が必要な場合があり（ホテルや空港など）、HTTPS リクエストは停止して1分後にタイムアウトになることがよくあります。Apple がこの問題をシステムレベルで解決するまでは、開発者がこれらの状況を適切に対処する必要があります。 +- Wi-Fi ホットスポットはログインや何らかの確認が必要な場合があり（ホテルや空港など）、HTTPS リクエストは停止して 1 分後にタイムアウトになることがよくあります。Apple がこの問題をシステムレベルで解決するまでは、開発者がこれらの状況を適切に対処する必要があります。 - アプリの初回起動時にユーザーがネットワークに接続していることを前提にしないでください。ユーザーはアプリをインストールしてからインターネット接続なしで出かけるまでアプリを開かないかもしれません。デプロイ時に最新のデータを使ってすぐ使える状態でアプリを出荷する責任があります。これは [Deployment](/deployment) ファクターで説明している毎週のリリーストレインとともに行います。 diff --git a/_i18n/ko/factors/persistence-of-data.md b/_i18n/ko/factors/persistence-of-data.md index 6b79bc0..11ea3cf 100644 --- a/_i18n/ko/factors/persistence-of-data.md +++ b/_i18n/ko/factors/persistence-of-data.md @@ -1,6 +1,6 @@ Apple의 가이드라인에 따라 데이터와 설정을 저장하는 것은 앱의 라이프 사이클에 치명적입니다. 특히 iCloud 동기화, 새로운 폰으로 업그레이드 그리고 백업에서 폰을 복원하는 경우에서 그렇습니다. -Apple의 공식 [iOS 데이터 저장 가이드라인](https://developer.apple.com/icloud/documentation/data-storage/index.html)을 따르고 있는지 확인하세요. +Apple의 공식 [iOS 데이터 저장 가이드라인](https://developer.apple.com/documentation/foundation/optimizing_your_app_s_data_for_icloud_backup)을 따르고 있는지 확인하세요. - `Documents`: 이 폴더는 유저가 생성한 컨텐츠를 위해 사용하세요. 이 폴더는 백업이 될 것입니다. - `Caches`: 이 폴더는 다시 생성할 수 있는 데이터를 위해 사용하세요. diff --git a/_i18n/ko/factors/prefer-local-over-remote.md b/_i18n/ko/factors/prefer-local-over-remote.md index 2e57d69..901f5d5 100644 --- a/_i18n/ko/factors/prefer-local-over-remote.md +++ b/_i18n/ko/factors/prefer-local-over-remote.md @@ -13,7 +13,7 @@ 인터넷 연결이 반드시 필요하지 않은 앱의 모든 부분은 인터넷 연결 없이 작동해야 합니다. -- 여러분의 앱 시작 화면([처음부터 존재하지 말았어야 하는 화면](https://developer.apple.com/ios/human-interface-guidelines/icons-and-images/launch-screen/))은 처음 웹 리스폰스를 기다리지 맗아야 합니다. 이는 왔다갔다 하는 와이파이 환경에선 사용자에게 나쁜 UX를 선사합니다. +- 여러분의 앱 시작 화면([처음부터 존재하지 말았어야 하는 화면](https://developer.apple.com/design/human-interface-guidelines/patterns/launching/))은 처음 웹 리스폰스를 기다리지 맗아야 합니다. 이는 왔다갔다 하는 와이파이 환경에선 사용자에게 나쁜 UX를 선사합니다. - 만약 앱이 모든 것에 인터넷 연결(예. 소셜 네트워킹 혹은 라이드 쉐어링 앱)이 필요하더라도, 인터넷 연결 없이 역사적인 데이터(예. 최근 운전, 최근 다이렉트 메세지 목록)라도 읽기 전용으로 볼 수 있게 해야합니다. - 인터넷 연결이 필요한 어떤 기능이 있다면 서버에 접근할 수 없을 때 확실한 에러 메세지를 띄워줘야 합니다. - 와이파이 핫스팟이 호텔이나 공항처럼 로그인이나 확인이 필요하다면, HTTPs 리퀘스트는 1분 넘게 타임아웃이 걸릴 것입니다. Apple이 이 이슈를 시스템 단계에서 해결할 때까지, 우리가 개발자로서 이러한 상황을 적절하게 다뤄줘야 할 것입니다. diff --git a/_i18n/pt_BR/factors/persistence-of-data.md b/_i18n/pt_BR/factors/persistence-of-data.md index 754718e..b9735ca 100644 --- a/_i18n/pt_BR/factors/persistence-of-data.md +++ b/_i18n/pt_BR/factors/persistence-of-data.md @@ -1,6 +1,6 @@ De acordo com os guias da Apple, armazenar dados e configurações é fundamental para o ciclo de vida de seu aplicativo, especialmente quando se trata de sincronização com o iCloud, troca de telefone ou restauração de um telefone a partir de um backup. -Certifique-se de seguir o [Guia de armazenamento de dados](https://developer.apple.com/icloud/documentation/data-storage/index.html) oficial da Apple: +Certifique-se de seguir o [Guia de armazenamento de dados](https://developer.apple.com/documentation/foundation/optimizing_your_app_s_data_for_icloud_backup) oficial da Apple: - `Documents`: Use esse diretório para conteúdos gerados pelo usuário. Ele será incluído em backups - `Caches`: Use esse diretório para dados que possam ser regerados @@ -13,4 +13,4 @@ A API do Keychain lhe dá o controle de como o dado está sendo armazenado no ap Um questionamento muitas vezes ignorado que você deve se fazer é: quando o usuário fizer um upgrade para um novo aparelho, o dado (ex: sessão de login) deve ser migrado também? -Se você usa [`kSecAttrAccessibleWhenUnlockedThisDeviceOnly`](https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly), o dado não será incluído no backup do iCloud ou do iTunes, o que significa que o usuário irá perder o dado quando fizer o upgrade do aparelho. \ No newline at end of file +Se você usa [`kSecAttrAccessibleWhenUnlockedThisDeviceOnly`](https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly), o dado não será incluído no backup do iCloud ou do iTunes, o que significa que o usuário irá perder o dado quando fizer o upgrade do aparelho. diff --git a/_i18n/pt_BR/factors/prefer-local-over-remote.md b/_i18n/pt_BR/factors/prefer-local-over-remote.md index 5fb1c1f..966110f 100644 --- a/_i18n/pt_BR/factors/prefer-local-over-remote.md +++ b/_i18n/pt_BR/factors/prefer-local-over-remote.md @@ -15,7 +15,7 @@ A maioria dos aplicativos iOS requer algum tipo de backend para determinadas tar Todas as partes do aplicativo que não necessariamente **precisam** de uma conexão com a internet (o que não é o caso do login, por exemplo) devem ser capazes de funcionar sem conexão com a internet: -- A tela inical do aplicativo, ou _launch screen_, ([que a propósito nem deveria existir](https://developer.apple.com/ios/human-interface-guidelines/icons-and-images/launch-screen/)), nunca deve esperar pela primeira resposta de sucesso do servidor, pois isso gera uma experiência ruim para o usuário com uma conexão inconsistente +- A tela inical do aplicativo, ou _launch screen_, ([que a propósito nem deveria existir](https://developer.apple.com/design/human-interface-guidelines/patterns/launching/)), nunca deve esperar pela primeira resposta de sucesso do servidor, pois isso gera uma experiência ruim para o usuário com uma conexão inconsistente - Se seu aplicativo requer conexão de internet para tudo (ex: aplicativo de rede social ou de carona compartilhada), ele deve ainda assim funcionar (de modo passivo) sem uma conexão com a internet para acessar dados históricos (ex: caronas recentes, mensagens recentes). - Toda funcionalidade do aplicativo que precise de uma conexão funcional com a internet deve mostrar uma mensagem de erro clara de que não foi possível se conectar ao servidor. - Dado que hotspots WiFi podem requerer um login ou uma confirmação de algum tipo (ex: hotel ou aeroporto), requisições HTTPS irão ficar travadas com frequência e darão time-out após cerca de 1 minuto. Até que a Apple resolva esse problema a nível de sistema, nós como desenvolvedores temos que garantir que estamos tratando essas situações da forma correta. diff --git a/_i18n/ru/factors/prefer-local-over-remote.md b/_i18n/ru/factors/prefer-local-over-remote.md index 28eeee7..678dc94 100644 --- a/_i18n/ru/factors/prefer-local-over-remote.md +++ b/_i18n/ru/factors/prefer-local-over-remote.md @@ -1,4 +1,4 @@ -В последние годы некоторые группы разработчиков начали использовать подходы, которые требуют меньше усилий по разработке, за счет снижение качества *user experience*, перенеся больше логики на бэкэнд и сделав приложение iOS тонким клиентом, показывающим результаты сервера. Такой подход приводит к разочарованию пользователя, когда приложение используется в ситуации с неидеальным подключением к Интернету (например, в метро, ​​лифте или неровном WiFi). +В последние годы некоторые группы разработчиков начали использовать подходы, которые требуют меньше усилий по разработке, за счет снижение качества _user experience_, перенеся больше логики на бэкэнд и сделав приложение iOS тонким клиентом, показывающим результаты сервера. Такой подход приводит к разочарованию пользователя, когда приложение используется в ситуации с неидеальным подключением к Интернету (например, в метро, ​​лифте или неровном WiFi). **Приложение должно выполнять как можно больше бизнес-логики и вычислений на устройстве** по целому ряду причин: @@ -15,7 +15,7 @@ Все части приложения, которым не обязательно **требуют** подключение к Интернету (например, логин), должны работать вообще без подключения к Интернету: -- Экрану запуска вашего приложения([которого не должно существовать](https://developer.apple.com/ios/human-interface-guidelines/icons-and-images/launch-screen/)) никогда не следует ждать первого успешного ответа от бека, так как это вызывает плохой UX для пользователей с нестабильным подключением к Интернету. +- Экрану запуска вашего приложения([которого не должно существовать](https://developer.apple.com/design/human-interface-guidelines/patterns/launching/)) никогда не следует ждать первого успешного ответа от бека, так как это вызывает плохой UX для пользователей с нестабильным подключением к Интернету. - Если вашему приложению требуется подключение к Интернету для всего функционала (например, приложение для социальных сетей или приложение для обмена поездками), оно должно по-прежнему работать (в режиме только для чтения) без подключения к Интернету для доступа к историческим данным (например, недавние поездки, недавние прямые сообщения). - Любая функция вашего приложения, для которой требуется работающее подключение к Интернету, должна отображать четкое сообщение об ошибке, что сервер не может быть достигнут. - Поскольку для точек доступа WiFi может потребоваться вход в систему или подтверждение каких-либо действий (например, в отеле или в аэропорту), запросы HTTPS часто зависают и время ожидания истекает примерно через минуту. Пока Apple не решит эту проблему на системном уровне, мы, как разработчики, должны быть в состоянии должным образом справиться с этими ситуациями. diff --git a/_i18n/zh_cn/factors/persistence-of-data.md b/_i18n/zh_cn/factors/persistence-of-data.md index 274d981..0c218e2 100644 --- a/_i18n/zh_cn/factors/persistence-of-data.md +++ b/_i18n/zh_cn/factors/persistence-of-data.md @@ -1,15 +1,16 @@ 根据苹果官方指南，数据和配置的存储对应用的生命周期至关重要，尤其是在 iCloud 同步、更新数据至一个新手机以及恢复手机备份时。 -请参考苹果官方的 [iOS 数据存储指南](https://developer.apple.com/icloud/documentation/data-storage/index.html): +请参考苹果官方的 [iOS 数据存储指南](https://developer.apple.com/documentation/foundation/optimizing_your_app_s_data_for_icloud_backup): + - `Documents`：该目录用于存储用户生成的内容，且会备份 - `Caches`：该目录用于存储可以被重新生成的数据 - `tmp`：该目录用于存储临时文件 - 使用文件的 `do not back up` 属性 -绝不应该在这些目录中存储用户敏感信息（如：密码或会话），而应该使用钥匙串（Keychain）的API。 +绝不应该在这些目录中存储用户敏感信息（如：密码或会话），而应该使用钥匙串（Keychain）的 API。 钥匙串 API 可以让你控制数据的存储方式。请确保你对[这些属性](https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_and_values)是如何影响应用的生命周期有着足够的理解。 你应该问自己一个问题——这个问题经常被人忽视——当用户升级到了一个新的 iOS 设备，数据（如：登录会话）是否也应该迁移过去？ -如果你使用 [`kSecAttrAccessibleWhenUnlockedThisDeviceOnly`](https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly) 属性，则数据不会被 iCloud 或 iTunes 的备份，这意味着用户如果更新他们的设备，则会丢失这些数据。 \ No newline at end of file +如果你使用 [`kSecAttrAccessibleWhenUnlockedThisDeviceOnly`](https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly) 属性，则数据不会被 iCloud 或 iTunes 的备份，这意味着用户如果更新他们的设备，则会丢失这些数据。 diff --git a/_i18n/zh_cn/factors/prefer-local-over-remote.md b/_i18n/zh_cn/factors/prefer-local-over-remote.md index 7586e6c..52dcaed 100644 --- a/_i18n/zh_cn/factors/prefer-local-over-remote.md +++ b/_i18n/zh_cn/factors/prefer-local-over-remote.md @@ -15,8 +15,8 @@ 应用程序中所有不需要联网的部分(如登录)应该在没有任何互联网连接的情况下工作： -- 应用的启动界面（[不适合第一时间做的任务](https://developer.apple.com/ios/human-interface-guidelines/icons-and-images/launch-screen/)）绝对不要等待第一个网络请求响应，因为在网络不稳定的情况下会造成极差的用户体验； +- 应用的启动界面（[不适合第一时间做的任务](https://developer.apple.com/design/human-interface-guidelines/patterns/launching/)）绝对不要等待第一个网络请求响应，因为在网络不稳定的情况下会造成极差的用户体验； - 如果应用的所有任务都依赖网络（如：社交应用或共享乘车应用），那么那些不需要网络连接的历史数据（如：近期行程，近期消息）也要能够正常获取（在只读模式下）； - 应用内任何需要连接网络才能使用的功能，应当在服务器连接失败的时候显示清晰的错误信息； - 在某些 WiFi 热点需要登录或验证（如：酒店或机场）的场景下，HTTPS 请求会经常卡住，并且在大约一分钟后超时。在苹果在系统层面上解决这个问题之前，作为开发者的我们必须能够妥善处理这类情况； -- 不要假设用户在第一次使用应用的时候一定有网络。用户可能安装了应用，但不会马上打开，而打开应用的时候又没有了网络连接。你应该让应用“开箱即用”并且保证应用里的资源都是最新的。[部署](/deployment)中提到的“发布列车”可以帮助你解决每周发布的问题。 \ No newline at end of file +- 不要假设用户在第一次使用应用的时候一定有网络。用户可能安装了应用，但不会马上打开，而打开应用的时候又没有了网络连接。你应该让应用“开箱即用”并且保证应用里的资源都是最新的。[部署](/deployment)中提到的“发布列车”可以帮助你解决每周发布的问题。