パン太
パン太
こちらの提案を実装する場合は後方互換性を意識した実装にしていただきたいです。 JSONのデータ構造がオブジェクト型から配列型に変わってしまうと 既存のサードパーティがJSONをデコードできなくなってしまうので できれば別のフィールドを用意していただいて現状のフィールドを非推奨にするなどをして後方互換性を維持していただきたいです。
@myConsciousness おっしゃる通り大幅な変更が入る場合APIのパスなどを分けるなどをして 後方互換性を維持したりするソフトウェアもありますが Misskeyは今までに後方互換性を意識しないような予告のない破壊的変更が何度かあったため このようなコメントをしました🙇♂️
テーブルの構造を変えない方法としては DriveFileの内容をRedisにキャッシュしてしまうのはどうでしょうか？ DriveFileはNoteやUserに比べそこまで更新されるわけではないので、 まだ実装の容易性は高そうだと思いました。 またMisskeyの特性上基本的に同じ投稿が多数のユーザから参照される傾向があるので キャッシュのヒット率も高くなるのではないかと思いました。
こちらのフィールドの属性を未指定にした場合どうなることが想定されているのでしょうか？… 後方互換性などがどうなるのか気になりました。
ぜひよろしくお願いします
通報自体はそこまで使用されないが、長年アプリを使用すればそれなりの件数にはなるので、 データストア周りの設計が難しい。 メモリ上に展開してしまうのが一番楽ではある。 一万件までなら大丈夫か？・・・
設定 > 見た目 から設定できるのが好ましいか？
Android Viewが一括で動的にデフォルトのフォントを指定する仕組みを提供していないので リフレクションでなんとかするか TextViewを使用しているすべてのViewを継承して独自のAndroid Viewを作るしかない
継承して実現する場合 TabLayoutとかは力技でなんとかなりそうだけど MenuとかNavigationViewとかどうするんだろう
Menuとかの場合はSpannableStringで対応するのが良さそう