2017-08-09 1 views
0

ユーザーが自分のバッグにアイテムを追加します。アイテムがバッグに追加されるとすぐに、アイテムがまだ利用可能であることを確認するためにネットワークコールを行います。ネットワークコールはバックグラウンドで完了するまでに数秒かかります。トップVCまたはビジブルVCを取得し、特定のVCがスタックに含まれているかどうかを確認します。

アイテムがカートに追加されると、そのアイテムは、アプリ内のどこからでもアクセスできるシングルトンに保存されます。このように:

static let shared = Cart()  
var products = [Product]() 

ネットワークコールが戻って製品が利用できない場合は、シングルトンから削除します。テーブルビューを再読み込みする必要があるため、カートコールがネットワーク通話中に開かれた場合、この問題が発生します。そのため、表示されているVCがカートVCであるかどうかを確認し、テーブルビューをリロードする必要があります。また、CartVCがメモリ内にあるかどうかを確認して、テーブルビューをリロードしたいと思います。カートVCがメモリ内にあり、別のVCの下にある場合、それはまた悪いデータを持ち、ユーザがVCを一番上に閉じると、不良データが表示されるためです。どうすればいい?

これが重複としてマークされる前に、私は他の投稿をチェックしましたが、どれもうまく動作しませんでした。これを行う方法はたくさんあります。私は迅速に3つが最良であるかどうかを知りたいと思います。

答えて

0

カートが積み重なっている場合は、viewWillAppearを使用してテーブルをリロードしてください。そうすれば、必要以上にテーブルをリロードすることはありません。 (カートがスタックにあり、4つの異なるネットワークコールが戻ってきた場合は、表が表示される前に、表が表示される前にリロードされます。カートが画面に表示されている場合については

製品が戻って使用できないように来て、カートが viewWillAppearにその通知を登録すると viewWillDisappear(または viewDidDisappear)で登録を解除することができたときに通知を送信することができ、あなたのシングルトン。この通知は、データの完全なリロードを引き起こすか、または使用できない製品を含めることができ、ユーザーに何が起こったのかを知らせることができます(説明なしで突然カートから消失するものではありません)。

このようにして、シングルトンはカートビューコントローラについて何も知る必要がなくなり、再利用可能になります。

+0

なぜ通知を登録解除する必要がありますか?これはうまくいきましたが、アプリのどの時点でも通知を登録解除しません。それは本当に悪いですか?すべての通知は、VCにテーブルビューをリロードするように指示しています –

+0

それほど悪くはありません。目に見えるVCでないときに通知の登録を解除することにより、テーブルビューが不必要に再ロードされなくなります。あなたがVCの生活のために登録されたままなら、あなたは 'viewWillAppear'でテーブルをリロードする必要はありませんが、同時に多くのアイテムが利用できなくなった場合には、ビューが何度も再ロードされています。また、通知からのreload呼び出しがメインスレッドで起こっているか、または奇妙なことが起こることを確認してください。 – theMikeSwan

+0

パーフェクト。ありがとう。私たちは見直しをしていましたが、とにかくその問題は問題ではないように見えます。私はそれを認識していない。私たちは、視界の崩壊時に通知をどのように登録取消しますか? –

1

あなたは通知を使ってそれを行うことができます。アイテムがもう使用できなくなってVCが開いている場合を想像してください。

1 - 「ItemNotAvailableNotification」のような通知を購読します。

2 - ネットワークコールが返されました。アイテムはもう使用できません。

3 - 通知 "ItemNotAvailableNotification"を送信します。

4 - VCで通知を処理します。

また、この方法では、「CartVC」の「不良データ」と、そのアイテムが利用可能であったと思われる「PreviousVC」を処理できます。

関連する問題