20210917のiOSに関する記事は4件です。

iOSDC 2021セッション資料まとめ

iOSDC2021登壇資料、スライドのまとめです。 Twitter等で見つけ次第掲載しますが、もし資料を見かけた方or資料を公開した登壇者の方がいらっしゃいましたら、コメント等でお声がけください。 スライドや資料のリンクが見つかった場合はタイトルにリンクをつけてありますので、タイトルがリンクになっていない場合はまだ資料が見つかっていないものになります。 Day 0 Track A 大規模リファクタリングの極意 forteeのリンク SwiftUIで使ったアプリを1年運用してみてわかったこと forteeのリンク Initiatives in Rakuma iOS App forteeのリンク SwiftUI で実プロダクトを音速リリースした話 forteeのリンク Track B agoraを使ってライブ配信機能を1ヶ月半でリリースした話 forteeのリンク A Swift Stack Overflow forteeのリンク 組織横断チームとサービス及び開発体制の定期健康診断 forteeのリンク iOSアプリ開発に入門して、いきなりUnity as a Libraryに挑戦してわかったこと。 forteeのリンク Track C 運用6年目・500万人が使うアプリのDBをSQLiteからFirestoreに移行した話 forteeのリンク iOSアプリ開発者がテスラを買って色々調べたりアプリを作ったりしつつまだ見ぬApple Carを想像する forteeのリンク 従業員数4000人、老舗エンタメ企業のテックカンパニーへの挑戦 forteeのリンク iOS・Androidで使えるデザインシステムをどう実装するか forteeのリンク Track D オーディオ波形を表示するために知っておくべきこと forteeのリンク PickGo for Partnerの移行方法から学ぶ 既存のネイティブアプリをFlutterへリプレイスする方法 forteeのリンク 動画プレイヤーアプリの開発を通じて学んだ機能を実現するための要点解説 forteeのリンク Track E 振り返りながら学ぶPackage Manager forteeのリンク Day 1 Track A とあるアプリのサービス終了を見届ける 〜サブスクリプション型アプリのサービス終了ベストプラクティス〜 forteeのリンク Network ExtensionでiOSデバイス上で動くパケットキャプチャを作る スクリプト入りの資料 forteeのリンク エンジニアの視点から見る(株)ゆめみの働き方 forteeのリンク 実践 iOS オープンソースプロジェクトの始め方 forteeのリンク noteのiOSアプリで実装したアクセシビリティの全て 文字起こし forteeのリンク Combine を使ったコードのテストを Scheduler で操る方法とその仕組み forteeのリンク 「スタディサプリ」がFull SwiftUIを選択した先に見えてきたもの。 forteeのリンク Track B シームレスな体験を実現する本人確認フローの構築 〜家計簿プリカB/43でのeKYC開発実例〜 forteeのリンク 日本語でもいい感じに改行したい!! forteeのリンク アプリ間連携で薬局・クリニックのユーザー体験価値を最適化した話 〜 Medpeer iOS開発〜 forteeのリンク Appleプライバシー保護の最新事情と適応戦略 forteeのリンク MDMを使って業務用アプリの初期設定を自動化する技術 forteeのリンク 宣言的UIの状態管理とアーキテクチャ - SwiftUIとGraphQLによる実践 forteeのリンク Finder Sync Extension で Mac 向け便利ツールを作ろう forteeのリンク タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから forteeのリンク Track C Source Editor ExtensionとSwiftSyntaxでコード自動生成ツールを作る forteeのリンク 機能ごとに動作するミニアプリでプレビューサイクルを爆速にした話 forteeのリンク だれもが当たり前に使うアプリへ noteのこれまでとこれから forteeのリンク iOSではじめるWebAR 2021 forteeのリンク 100日間AR表現を実装して見つけた面白い実装を全力解説 forteeのリンク Mediapipeを使ったARアプリ開発事例〜カメラをかざして家の中で売れるものを探そう forteeのリンク App Size Optimizationへの挑戦 forteeのリンク 歴史のある大規模アプリに Design System を導入して開発をスケールさせる forteeのリンク Track D 初めてのハードウェア対応 forteeのリンク App Store用スクリーンショットの自動生成をアラビア語対応してSwiftUIで実装してみた forteeのリンク 未知のファイル形式をCodableで読み書きするのに役立つテクニック 『Apple Watchの文字盤ファイル』 forteeのリンク バーチャル背景を導入しよう forteeのリンク Swift 5.5 async/await を支えるモナド、継続、コルーチン forteeのリンク 僕たちが『Appのプライバシーに関する質問への回答』そして『ATT』に対応するまでの物語 forteeのリンク iOSエンジニアがKMPで大規模アプリのロジック共通化をしてうまくできている話 forteeのリンク Track E React Nativeにおける状態管理サバイバルガイド Discordで貼られたpdfのリンク forteeのリンク StoreKit のこれまでとこれから forteeのリンク 知られざる課金ステータス forteeのリンク UITestを活用しまだまだ不安定なSwiftUIアプリを安定的に実務運用する方法 forteeのリンク Day 2 Track A ランタイムデバッグのススメ forteeのリンク 大規模なアプリのマルチモジュール構成の実践 forteeのリンク アプリ開発プラットフォーマー特有の開発課題とアプローチ forteeのリンク ケースに応じたUICollectionViewのレイアウト実装パターン forteeのリンク UICollectionViewの最新のAPIを使いましょう forteeのリンク iOSアプリのセキュリティ基礎 forteeのリンク Track B バックグラウンドでアプリがキルされても怖くない!アプリの状態を元に戻すリストア機能の全て forteeのリンク Hello, Swift Concurrency world. forteeのリンク KMMを使って感じたPros/Cons forteeのリンク MultipeerConnectivityを使った動画のリアルタイム端末間共有 〜料理動画撮影アプリの事例〜 forteeのリンク SwiftUI+GraphQLで新規プロダクトの継続的破壊(Continuous Destruction)に立ち向かう forteeのリンク async/awaitやactorでiOSアプリ開発がどう変わるか Before&Afterの具体例で学ぶ forteeのリンク SceneKitを使ってアプリのクオリティを劇的に上げる forteeのリンク Track C LiDARを活用したARアプリを作ろう forteeのリンク 作ってわかる!LiDARによるカメラの暗所オートフォーカス機能 forteeのリンク LINEアプリのモバイル体験改善に向けた取り組み forteeのリンク WidgetKitで良い体験を作るには forteeのリンク ローカライゼーションマネージメント プラットフォーム導入の話 forteeのリンク Swift Package中心のプロジェクト構成とその実践 forteeのリンク async/awaitの性能をDartとSwiftとの比較で読み解く forteeのリンク Track D 実践 SharePlay / Group Activities forteeのリンク あらゆる情報を楽に正しく String にフォーマットする - 令和2021年から脱却せよ forteeのリンク DateComponentsと仲良くなる forteeのリンク App Extension のスタックトレース情報からクラッシュを解析/集計する forteeのリンク オフライン編集もできる複雑なデータ構造を端末間で同期するために forteeのリンク 対話を頑張らなくても作れるSiri Shortcuts向けIntents App Extension forteeのリンク Track E 自己管理の夢と Screen Time API forteeのリンク 元ゲーム開発者が贈る描画パフォーマンス改善 forteeのリンク App Clips はどこから来たのか&何者か&どこへ行くのか forteeのリンク AVPlayerできちんとコンテンツ保護 forteeのリンク hak & tomzoh 特別企画 forteeのリンク その他(アンカンファレンス資料、LT資料など)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

kivy-iosのインストールでtoolchain build kivy python が途中までコンパイルできるのにエラーが出る時

URLリンク切れかも その場合、以下のディレクトリのファイルをいじる。 "作業ディレクトリ/lib/python3.x/site-packages/kivy-ios/recipes/freetype/__init__.py"の8行目URLを "http://download.savannah.gnu.org/releases/freetype/freetype-{version}.tar.bz2" から "http://download.savannah.gnu.org/releases/freetype/freetype-old/freetype-{version}.tar.bz2" に変更すればコンパイルできる。 アーキテクチャがarm64かも(m1 mac) armになっていると、コンパイルが通らない。 homebrewのパッケージインストールからx86_64に切り替えてやり直す。(環境をどちらか一方に固定する場合) armとx86_64環境を切り替えて使用したい場合は、下記リンクのようにするといいかもしれない。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Flutter】ListViewでD&Dソートに対応しつつ並び順を保存する

はじめに Flutterだとドラッグアンドドロップで並べ替え可能なListView自体はかなり楽に実装できるのですが、ネイティブ同様(?)並び順の保存に関しては自前で作る必要があります(たぶん)。 もし適当に保存しようものなら並べ替えやアイテムの追加・削除でごちゃごちゃになってしまいます(経験済み)。 なんとなく一番簡単そうな方法を書き綴っておきますので良ければ参考にしてみてください(もっといい方法があればコメント頂けると嬉しいです)。 因みにFlutterは始めたばかりなのでおかしなところがあるかも知れません。 それとListView自体の実装とSQL関連の詳細説明は省略しますので適宜調べて貰えると幸いです。 前提 ListViewに並べるアイテムはDBに実装済みのものとします。 今回は以下のアイテムを用意して進めます。 item.dart class Item { var id; var title; var sort; //その他省略 } 実装 ListViewの実装 先ずはD&Dソート可能なListViewを実装します。 Main.dart class _MainPageState extends State<MainPageState> { List<Item> itemList = []; @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar(title: Text("Sample"),), body: FutureBuilder( future: _createList(), builder: (BuildContext context, AsyncSnapshot<List<Item>> snapshot){ if (!snapshot.hasData) { return Text("Loading..."); }else{ return ReorderableListView.builder(//ReorderableListViewにすることでD&Dソート可能 padding: EdgeInsets.all(10), itemCount: itemList.length, onReorder: (oldIndex, newIndex){//onReorderを追加、D&Dすると呼ばれる if (oldIndex < newIndex) { newIndex -= 1; } Item movedItem = itemList.removeAt(oldIndex);//アイテムの場所を入れ替える itemList.insert(newIndex, movedItem); }, itemBuilder: (context, index){ return _buildListItem(itemList[index], index); }, ); } }, ), ); } Widget _buildListItem(Item item, int index){ return Container( key: Key(item.id),//ソートに必要な一意のキー(なんでもいい) child: Card( child: ListTile( onTap: (){}, //onLongPress: (){},//無効化する title: Text(item.title), trailing: Text("$index/${item.sort}"),//インデックスと保存してある並び順 ), ), ); } Future<List<Item>> _createList() async { itemList = await DBProvider.db.getAllItem();//DBからとってくる itemList.sort((a,b) => a.sort.compareTo(b.sort));//保存済みの順番でソート return itemList; } } これでドラッグアンドドロップによるソートが可能なListViewが実装できました。 ポイントはListView.builderからReorderableListView.builderに変更すること、onReorderを追加すること、ListViewに並べるWidgetに一意のキーを持たせること、です。 ListViewに並べるWidgetの中身は特に何でもいいんですが分かりやすくする為に保存されている並び順とインデックスを表示してます。 次は並び順の保存を実装します。 並び順の保存 保存するタイミングは色々あると思いますが、今回はD&D時に毎回保存しようと思います。 先程のonReorder内に以下のメソッドを追加します。 main.dart class _MainPageState extends State<MainPageState> { //省略 onReorder: (oldIndex, newIndex){ //省略 _saveSort(); } _saveSort(){ itemList.asMap().forEach((index, item) {//asMap()でindexを持たせる item.sort = index.toString();//アイテムに保存する並び順を現在のインデックスに変える DBProvider.db.updateItem(item);//DBのアイテムを更新 }); } } これで_saveSort()が呼ばれるたびにD&D後のインデックスがDBに保存されると思います。 アイテムを追加したり削除したりしても並べ替え後のインデックスで上書きするので問題ないはずです(たぶん)。 ただ、これだと一つ問題というかUPDATE文が何回も呼ばれてしまうので、必要であればDBProviderを以下のように少し変更します。 db_provider.dart class DBProvider { //省略 updateItem(Item item) async {//こっちではなく final db = await database; var res = await db.update( tableName, item.toMap(), where: "id = ?", whereArgs: [item.id], ); return res; } updateAllItem(List<Item> itemList) async {//こっちを追加 final db = await database; var batch = db.batch(); itemList.forEach((item) { batch.update( tableName, item.toMap(), where: "id = ?", whereArgs: [item.id], ); }); var res = await batch.commit(); return res; } } main.dartも書き換えます。 main.dart _saveSort(){ itemList.asMap().forEach((index, item) {//asMap()でindexを持たせる item.sort = index.toString();//アイテムに保存する並び順を現在のインデックスに変える //DBProvider.db.updateItem(item);//これを削除して }); DBProvider.db.updateAllItem(item);//これを追加 } SQLあまり詳しくないのですがバッチ更新を行うことでパフォーマンスが良くなるみたいなので、データが多くなる場合はこのほうがいいっぽいです。 おしまい 問題があったり、もっといい方法があれば教えてください!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Swift CustomNSErrorを利用して、より詳しいエラー情報を定義する

概要 CustomNSError を使ってより詳細なエラーを定義します。 はじめに Swiftでコーディングするとき、何かの失敗を表すときに Error を使うことがよくあるかと思います。 enum MyError: Error { case one case two } エラーを見て何が起こったかを調べて問題を解決していくことがあると思いますが、 例えば次の analyzeError のような、MyErrorに限らず何のエラーが来るかわからないError を引数に取った場合、一度NSError に変換することによってdomainやcodeなど、より詳しい情報を得ることが可能です。 enum MyError: Error { case one case two } func analyzeError(error: Error) { let nsError: NSError = error as NSError print(nsError.domain) // __lldb_expr_1.MyError print(nsError.code) // 0 print(nsError.userInfo) // [:] } analyzeError(error: MyError.one) このように、単なる Error を設定すると、domainおよびcodeは自動で決定され、userInfoには空の辞書が入っています。 CustomNSError CustomNSError を使うと、domain、codeおよびuserInfoの定義が可能になります。 errorDomain はdomain、errorCode はcode、errorUserInfo はuserInfoとして表現されるようになります。 enum YourError: Error { case one } enum MyError: CustomNSError { case one([String : Any]) case two var errorCode: Int { switch self { case .one: return 1 case .two: return 2 } } var errorUserInfo: [String: Any] { switch self { case .one(let userInfo): return userInfo case .two: return [:] } } static var errorDomain: String = "CustomMyError" } func analyzeError(error: Error) { let nsError: NSError = error as NSError print(nsError.domain) // CustomMyError print(nsError.code) // 1 print(nsError.userInfo) // ["NSUnderlyingError": __lldb_expr_7.YourError.one] } analyzeError(error: MyError.one([NSUnderlyingErrorKey : YourError.one]))
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む