回答編集履歴
4
修正
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
List の選択から起動された時は newInstance を使ってフラグメントを生成しているのに対し、直接起動(?)時は new で生成しているようです。
|
|
2
|
-
new で生成した場合は setArgument されていないので、 getArgument は null を返すでしょう。
|
|
2
|
+
new で生成した場合は setArguments されていないので、 getArguments は null を返すでしょう。
|
|
3
3
|
|
|
4
|
-
このように生成の仕方が異なるのは混乱の元ですので統一したほうが良いと思いますが…それはともかくとしまして、直接の時は newInstance の時の各パラメータは不要であれば、
|
|
4
|
+
このように生成の仕方が異なるのは混乱の元ですので統一したほうが良いと思いますが…それはともかくとしまして、直接の時は newInstance の時の各パラメータは不要であれば、 getArguments して null だったら getString 等しないというようにすれば良いのではないでしょうか。
|
3
全変更
test
CHANGED
|
@@ -1,12 +1,4 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
(AddBudgetTracker.java の 78行目等)
|
|
1
|
+
List の選択から起動された時は newInstance を使ってフラグメントを生成しているのに対し、直接起動(?)時は new で生成しているようです。
|
|
2
|
+
new で生成した場合は setArgument されていないので、 getArgument は null を返すでしょう。
|
|
4
3
|
|
|
5
|
-
な
|
|
6
|
-
|
|
7
|
-
どの画面がいつどのように呼ばれどのように処理をしてどことどのように連携するのかは、作者自身が設計しているのであれば作者自身が理解していなければなりません。
|
|
8
|
-
teratail に限らずあらゆる情報はサンプルであり、言葉通りの"全て"に適応できるものではありません。
|
|
9
|
-
多くのオブジェクトが多くのオブジェクトと関係を持つと、本件のように「あの時はああなってこの時はこうなって、その時はそうなって・・・」があちこちで絡まって混沌として行き、訳が分からなくなります。
|
|
10
|
-
なので、それぞれのオブジェクトへの指示の仕方、結果の受け取り方を極力1本化し、あるフラグメントは newInstance メソッドのみで生成することにし(従って必要なデータは newInstance メソッドのパラメータにして setArgument/getArgument を使う)、結果は親 FragmentManager への FragmentResult で行う(従って親側はフラグメント生成の時に FragmentManager に FragmentResultListener を登録しておくこと) と決めたりするわけです。
|
|
11
|
-
そう決めたにも関わらず、生成に newInstance を使わないとか、ある時は結果は不要だから Result しないでアクティビティを直接 finish したりとかが混じってしまっては、混沌に逆戻りです。
|
|
12
|
-
もちろん、処理に決め事が合わなくなってくることは良くあります。そうなったら決め事を修正していくことになりますが、それは混沌化を防ぎつつ行わなければなりません。
|
|
4
|
+
このように生成の仕方が異なるのは混乱の元ですので統一したほうが良いと思いますが…それはともかくとしまして、直接の時は newInstance の時の各パラメータは不要であれば、単に getArgument しない、もしくは getArgment して null だったら getString 等しないというようにすれば良いのではないでしょうか。
|
2
追加
test
CHANGED
|
@@ -3,3 +3,10 @@
|
|
|
3
3
|
(AddBudgetTracker.java の 78行目等)
|
|
4
4
|
|
|
5
5
|
なお、AddSpendingFragment に対する requestKey は FragmentResult のパラメータとして親 FragmentManager の FragmentReaultListener での待ち合わせの為ですので、 insert/delete は関係ありません。
|
|
6
|
+
|
|
7
|
+
どの画面がいつどのように呼ばれどのように処理をしてどことどのように連携するのかは、作者自身が設計しているのであれば作者自身が理解していなければなりません。
|
|
8
|
+
teratail に限らずあらゆる情報はサンプルであり、言葉通りの"全て"に適応できるものではありません。
|
|
9
|
+
多くのオブジェクトが多くのオブジェクトと関係を持つと、本件のように「あの時はああなってこの時はこうなって、その時はそうなって・・・」があちこちで絡まって混沌として行き、訳が分からなくなります。
|
|
10
|
+
なので、それぞれのオブジェクトへの指示の仕方、結果の受け取り方を極力1本化し、あるフラグメントは newInstance メソッドのみで生成することにし(従って必要なデータは newInstance メソッドのパラメータにして setArgument/getArgument を使う)、結果は親 FragmentManager への FragmentResult で行う(従って親側はフラグメント生成の時に FragmentManager に FragmentResultListener を登録しておくこと) と決めたりするわけです。
|
|
11
|
+
そう決めたにも関わらず、生成に newInstance を使わないとか、ある時は結果は不要だから Result しないでアクティビティを直接 finish したりとかが混じってしまっては、混沌に逆戻りです。
|
|
12
|
+
もちろん、処理に決め事が合わなくなってくることは良くあります。そうなったら決め事を修正していくことになりますが、それは混沌化を防ぎつつ行わなければなりません。
|
1
修正
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
フラグメントに newInstance メソッドを作るのは、そのフラグメントの生成に際して必ずパラメータが必要だからです。
|
|
1
|
+
フラグメントに newInstance メソッドを作るのは、そのフラグメントの生成に際して必ずパラメータが必要だからです。これは何か java としてとか android として決まっていることでは無く、普通にクラスを設計する際にコンストラクタにパラメータが必要かを決めたりするのと同じことです。ただフラグメントはコンストラクタでパラメータを指定することが出来ない(これは android での"ある種"の決りです)特殊なモノで特殊な方法を使わないといけないので、その処理は newInstance というメソッド(この名前は何ならなんでも良いのです)ですることにしようということです。
|
|
2
2
|
従って、そのフラグメントを生成する個所は全て new でフラグメントオブジェクトを作るのでは無く、newInstance メソッドを使って(引数を指定して)生成してください。
|
|
3
3
|
(AddBudgetTracker.java の 78行目等)
|
|
4
4
|
|