13日目となりました。通知センターを開きすぎて親指にグッときました。開発する時に困ったことと、その解決策を紹介したいと思います。データを利用する前提に設計されていないことが多いと思います。直接アクセスできません。データをコピーします。簡単に実装ができるアプローチです。データが重複するのでディスク容量を余計に消費しますし、いろんな場所でデータを書き出すアプリの場合、データの整合性が問題になってくる可能性もあります。大きなファイルだとデータの反映に時間がかかる可能性なども出てきます。データを書き込めばよいですし、ディスクの使用量は一番少なくて済みます。他のアプリもアクセスできるため、すべてのデータを移動してしまうと、関係のないデータを他のアプリから参照できてしまう可能性がありますので、あまりよいアプローチとは言えません。側からは必要なデータだけ読み込めばいいので、メモリーの節約にもなります。時間と共に表示が変わるようなアプリは定期的にデータの更新をしてやる必要が出てくるかもしれません。表示されない、といったことがよくあります。この場合、メモリー不足の可能性が高いです。メモリー制限は通常のアプリよりかなり厳しく、通常のアプローチでは全然メモリーが足りない可能性もあります。強制終了されて何も表示されなくなります。通常のアプリ開発では、手間のかからない仕組みを使って実装するようなところも、最適化が必要になるかもしれません。開発した時に試した内容を紹介します。描画する方式は、カスタムビューを実装する時によく使いますが、結構メモリーを消費します。セットすると良いかもしれません。減らすことができました。代入するなどして、破棄するタイミングを制御します。読み込んでいるデータのサイズにもよりますが、ピークのメモリー使用量が若干ですが、抑えられます。哲学に反しますが、1や2のようなアプローチをする場合、どうしてもアプリ本体とカスタムビューやロジックの共通化ができない場合があります。作るというアプローチが必要になるかもしれません。制約が通常のアプリより厳しくなっています。本当にその情報は通知センターで見る必要があるのか、といった観点で表示する情報を整理するとよいでしょう。することで、ロードが必要なデータも減ってメモリー使用量も減るかもしれません。自体が必要なくなるかもしれません。等他のプラットフォームの自動レイアウトと比べてまだまだノウハウが少ないのが現状です。使うのがベターかと思います。縦横のサイズが決まっていません。サイズが決まるようにすべきです。メソッドをオーバライドして、あらかじめカスタムビューのサイズがどうなるか決めてやるとよいでしょう。開発者が高さを決めることができます。実際のところは1つのウィジェットが画面内に収まりきるように調整されるようです。作ってやるとよいでしょう。値をセットしてやるとうまくいくかもしれません。自分で決めてやる必要があります。ハマりどころを紹介しました。実用的な機能かと思います。用量用法を守って正しく使い、アプリの利便性を向上しましょう。アカウントでは、フェンリルプロダクトの最新情報などをつぶやいています。