質問編集履歴

5

一部文章構成が壊れていたのを修正

2017/06/15 04:38

投稿

tetsukay
tetsukay

スコア232

test CHANGED
File without changes
test CHANGED
@@ -152,7 +152,7 @@
152
152
 
153
153
  - リソースを追加したら管理クラスに追加しないといけないのが面倒
154
154
 
155
- - リソースがライブラリに入っていると,ライブラリの `UserResource` と アプリの `UserResource` ができて,中々にカオス
155
+ - リソースがライブラリに入っていると,ライブラリの `UserResource` と アプリの `UserResource` ができて,中々にカオス
156
156
 
157
157
 
158
158
 
@@ -182,6 +182,16 @@
182
182
 
183
183
 
184
184
 
185
+ の弱点改良版.
186
+
187
+ `man_` `woman_` のprefixを外したコアテキスト( `button` )と種類( `drawable` ) を渡すと,よしなに `R.drawable.man_button` をコード生成してくれるとか.
188
+
189
+ コード生成されればリフレクションと違って直接参照されるので,unused警告やリソースがない場合にコンパイルエラー検出可能なはず…?
190
+
191
+ (これが実現可能&有用そう&既存の回避策がないならライブラリ作ってみようかしら)
192
+
193
+
194
+
185
195
  ### Kotlinの拡張関数つかうと行ける?
186
196
 
187
197
 
@@ -190,16 +200,6 @@
190
200
 
191
201
 
192
202
 
193
- の弱点改良版.
194
-
195
- `man_` `woman_` のprefixを外したコアテキスト( `button` )と種類( `drawable` ) を渡すと,よしなに `R.drawable.man_button` をコード生成してくれるとか.
196
-
197
- コード生成されればリフレクションと違って直接参照されるので,unused警告やリソースがない場合にコンパイルエラー検出可能なはず…?
198
-
199
- (これが実現可能&有用そう&既存の回避策がないならライブラリ作ってみようかしら)
200
-
201
-
202
-
203
203
  # 判断基準
204
204
 
205
205
 

4

リストの階層化を再修正

2017/06/15 04:38

投稿

tetsukay
tetsukay

スコア232

test CHANGED
File without changes
test CHANGED
@@ -82,7 +82,7 @@
82
82
 
83
83
  - 参照するリソースが unused でlintに引っかかる
84
84
 
85
- - リソースを整理したい時に,消していいリソースか判断に迷う
85
+ リソースを整理したい時に,消していいリソースか判断に迷う
86
86
 
87
87
 
88
88
 
@@ -206,13 +206,13 @@
206
206
 
207
207
  - リソースを使用する箇所はできるだけシンプルに記述できること
208
208
 
209
- - 使う箇所で条件分岐はしたくない
209
+ 使う箇所で条件分岐はしたくない
210
-
210
+
211
- - 使う箇所のステップ数を少なく
211
+ 使う箇所のステップ数を少なく
212
212
 
213
213
  - リソースを選択する側の仕組みも極力シンプルになるように
214
214
 
215
- - リソースを追加するたびに管理クラスに手を入れずに済む方法があればベスト
215
+ リソースを追加するたびに管理クラスに手を入れずに済む方法があればベスト
216
216
 
217
217
 
218
218
 

3

リストの階層化ができないようなので,インデントで対応

2017/06/15 02:39

投稿

tetsukay
tetsukay

スコア232

test CHANGED
File without changes
test CHANGED
@@ -82,7 +82,7 @@
82
82
 
83
83
  - 参照するリソースが unused でlintに引っかかる
84
84
 
85
- - リソースを整理したい時に,消していいリソースか判断に迷う
85
+ - リソースを整理したい時に,消していいリソースか判断に迷う
86
86
 
87
87
 
88
88
 
@@ -206,13 +206,13 @@
206
206
 
207
207
  - リソースを使用する箇所はできるだけシンプルに記述できること
208
208
 
209
- - 使う箇所で条件分岐はしたくない
209
+ - 使う箇所で条件分岐はしたくない
210
-
210
+
211
- - 使う箇所のステップ数を少なく
211
+ - 使う箇所のステップ数を少なく
212
212
 
213
213
  - リソースを選択する側の仕組みも極力シンプルになるように
214
214
 
215
- - リソースを追加するたびに管理クラスに手を入れずに済む方法があればベスト
215
+ - リソースを追加するたびに管理クラスに手を入れずに済む方法があればベスト
216
216
 
217
217
 
218
218
 

2

求める判断基準を追記

2017/06/15 02:38

投稿

tetsukay
tetsukay

スコア232

test CHANGED
File without changes
test CHANGED
@@ -182,6 +182,14 @@
182
182
 
183
183
 
184
184
 
185
+ ### Kotlinの拡張関数つかうと行ける?
186
+
187
+
188
+
189
+
190
+
191
+
192
+
185
193
  の弱点改良版.
186
194
 
187
195
  `man_` `woman_` のprefixを外したコアテキスト( `button` )と種類( `drawable` ) を渡すと,よしなに `R.drawable.man_button` をコード生成してくれるとか.
@@ -189,3 +197,39 @@
189
197
  コード生成されればリフレクションと違って直接参照されるので,unused警告やリソースがない場合にコンパイルエラー検出可能なはず…?
190
198
 
191
199
  (これが実現可能&有用そう&既存の回避策がないならライブラリ作ってみようかしら)
200
+
201
+
202
+
203
+ # 判断基準
204
+
205
+
206
+
207
+ - リソースを使用する箇所はできるだけシンプルに記述できること
208
+
209
+ - 使う箇所で条件分岐はしたくない
210
+
211
+ - 使う箇所のステップ数を少なく
212
+
213
+ - リソースを選択する側の仕組みも極力シンプルになるように
214
+
215
+ - リソースを追加するたびに管理クラスに手を入れずに済む方法があればベスト
216
+
217
+
218
+
219
+ これでもまだふわっとしてるのは重々承知ですが,
220
+
221
+
222
+
223
+ 1. リソースを使う箇所はシンプルに書きたい
224
+
225
+ 2. リソースが無いことをコンパイルエラーで検知したい
226
+
227
+ 3. unused resources なlintは出されたくない
228
+
229
+ 4. リソースを追加しても管理クラスに手を入れたくない
230
+
231
+
232
+
233
+ というのが要件でしょうか.
234
+
235
+ 1, 2, 3はMUST,4はSHULDですが,4もMUSTにできるならその方法が知りたい次第です.

1

微修正

2017/06/15 02:36

投稿

tetsukay
tetsukay

スコア232

test CHANGED
File without changes
test CHANGED
@@ -14,7 +14,7 @@
14
14
 
15
15
 
16
16
 
17
- ユーザが男性なら `R.drawable.man_button` 女性なら `R.drawable.woman_button` を選択したいとき,シンプルに書けば
17
+ ユーザが男性なら `R.drawable.man_button` 女性なら `R.drawable.woman_button` を選択したいとき,愚直に書けば
18
18
 
19
19
 
20
20
 
@@ -108,7 +108,7 @@
108
108
 
109
109
  public int getRes(Res res) {
110
110
 
111
- return user.gender == "man" ? res.man : res.woman;
111
+ return user.gender == Gender.MAN ? res.man : res.woman;
112
112
 
113
113
  }
114
114