【问题标题】:Cache invalidation in ReactiveCocoaReactiveCocoa 中的缓存失效
【发布时间】:2013-11-06 11:58:01
【问题描述】:

总的来说,我仍在研究 RAC 和 FRP - 目前正在努力弄清楚如何实现我通常不得不在其他地方使用的模式。

假设我正在制作一个抽认卡应用程序,主屏幕是我的卡片组列表。这个应用程序使用网络服务器的状态作为事实来源。我不想在每次显示屏幕时都从服务器重新获取此卡组列表 - 太好了,我可以在带有重播主题的多播信号中使用延迟网络请求来有效地记忆该列表。

我有两种方法可以通过从服务器重新获取来刷新此列表,这对我来说很复杂。当应用程序中发生任何数量的事情时,我希望能够使这个“缓存”列表无效(例如,用户导航到其他屏幕并执行会使主屏幕上的牌组列表过时的操作,或者应用程序刚刚被重新唤醒,所以我们可以猜测它可能已经过时了),这样当用户下次返回这个主屏幕时,它一开始不会显示任何东西(而不是显示旧列表,因为它知道它是由于用户的操作而过期)并将重新获取列表,并在下载后显示它。我怎样才能最优雅地处理这种“无效”状态(希望没有实际状态)?

我还希望能够在超时时使“缓存”列表过期 - 基本上,甲板列表信号会给出缓存列表,直到足够的时间过去,此时它会在提供之前懒惰地发出网络请求数据。

我对如何实现这两件事有一些想法,但它们似乎有点令人费解。很想得到一些指导或被指出一些示例项目的方向。

我可以看到处理此问题的一种简单方法是拥有一个命令式服务层,命令式处理缓存和缓存失效,并使用广播事件使缓存失效,并从缓存返回或产生网络请求以填充反应层尝试访问数据时的缓存。如果不先了解这样做的反应方式,我宁愿不遵从这种方法。

谢谢!

【问题讨论】:

标签: objective-c design-patterns caching frp reactive-cocoa


【解决方案1】:

从 GitHub 复制的答案

答案可能有很多种,设置并没有提供太多限制。既然如此,我会提出一些建议来开始对话。

首先,看看+merge:,它允许您通过将信号的值“汇集”成单个信号来组合信号集合。

RACSignal *deckInvalidated = [[RACSignal merge:@[
    userDidSomethingSignal,
    appReawokenSignal,
    // etc
]];

有了这个,我们需要将该信号转换为每当发生失效事件时从服务器获取套牌的信号。

在我们这样做之前,让我们看看信号请求是什么样的。假设您有一个 RACified API 客户端。

RACSignal *fetchDecks = [[APIClient fetchDecks] startWith:nil];

此时使用-startWith: 有点前瞻性。计划是使用RAC 宏形成一个将“绑定”到属性的信号,并且通过使用startWith:nil,每当新请求开始时,该属性将设置为nil。这是为了满足您的要求:

一开始什么也不显示(而不是显示旧列表,因为它知道由于用户的操作它已经过时了)并且会重新获取列表

现在我们可以将失效事件映射到网络请求中,它看起来很简单,但它缺少一些东西。

RAC(self, decks) = [[deckInvalidated mapReplace:fetchDecks] switchToLatest];

这缺少任何到期刷新。为了做到这一点,让我们在前面的请求完成后,在适当的-delay 之后发出-repeats 的请求信号:

RACSignal *delay = [[RACSignal empty] delay:AEDeckRefreshTimeout];

RACSignal *repeatingFetchDecks = [[fetchDecks concat:delay] repeat];

现在,重新审视RAC的赋值,只需要稍微修改一下:

RAC(self, decks) = [[deckInvalidated mapReplace:repeatingFetchDecks] switchToLatest];

这仍然存在一个问题,失效事件可能会导致对服务器的并发请求。您没有提到这是一个问题,因此不确定这对于您的应用的用例是否必要/重要,但需要考虑。

为了获得完整的概述,代码可以在单个信号组合中完成:

RAC(self, decks) = [[[RACSignal
    merge:@[
        userDidSomethingSignal,
        appReawokenSignal,
    ]]
    mapReplace:[[[[APIClient
        fetchDecks]
        startWith:nil]
        concat:[[RACSignal
            empty]
            delay:AEDeckRefreshTimeout]]
        repeat]]
    switchToLatest];

【讨论】:

  • 太棒了!这增加了很多清晰度,谢谢。不过,首先要考虑两件事:我希望牌组的获取是懒惰的,而不是在它失效后立即进行。它应该只在需要时出现(用于向用户展示等),如果我理解正确,RAC(self,decks)会急切地使用它。
  • 如果这变得懒惰,那么问题应该会消失,因为同一资源同时启动了多个请求。否则这将是一个问题,因为 API 调用不一定便宜。
  • 我也对围绕 RAC 的最佳实践感到有些困惑,或者更确切地说,副作用实际上应该发生在哪里。如果不需要属性,最好避免使用它们,而是使用回放主题吗?或者播放主题​​是否与属性一样“糟糕”,因为它只是另一种形式的状态。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2018-12-28
  • 2015-04-29
  • 2011-01-13
  • 1970-01-01
  • 1970-01-01
  • 2015-07-21
  • 2017-09-08
相关资源
最近更新 更多