小编Cat*_*ita的帖子

假设您有一个显示项目列表的简单屏幕。我可以像这样定义屏幕的 3 种可能状态：

 sealed class State() {
        data class Success(val items: List<Item> = listOf()): State()
        object Loading: State()
        data class Error(val error: String? = null): State()
    }

在我的 Compose UI 中，我相应地处理状态：

when(state) {
    is State.Success -> {
        LazyColumn(...) {...}
    }
    is State.Error -> {
        Text(state.error ?: "")
    }
    is State.Loading -> {
        LoadingBar()
    }
}

第一个状态是State.Loading()我将发起网络请求来获取项目。当物品到达时，状态变为State.Success()。

但是，如果之后用户按下一个应该触发另一个网络请求的按钮怎么办？在现有内容之上，我需要State.Loading在新的网络请求完成时再次推送该类以显示加载指示器。

然而，此状态不知道之前的项目内容，因此 UI 只会显示加载指示器，并且不会渲染之前的内容State.Success()。

我可以通过引入一个名为：的新状态来解决这个问题，State.LoadingActionWhileSuccess但这是不可扩展的。

你会如何对待这种情况？添加其他 State 类可能会起作用，但在某些时候它会变得难以管理。

我对这种方法最大的担忧是，当屏幕复杂性增加时，可能状态的组合会失控。

我可以保持状态为常规状态data class并对其进行变异，但我发现这种方法可能会为并发变异引入非法状态。

要清楚,我的代码完美无缺.我担心的问题是我不确定我的数组分配类型.

我的任务很简单:我需要在动态分配的数组中执行一些操作.

然而,值已经在数组中给出.所以我需要在其中添加这些值.

为了保持我的矢量动态分配并避免以下情况:

float *p;
 p = malloc(9 * sizeof(float));
* p=2;
* (p+1)=60;
* (p+2)=-23;
.
.
.
* (p+8)=9;

我试过这样做:

float *p;
p = malloc(9 * sizeof(float));
memcpy (p, (float[]) {2 ,60 ,-23, 55, 7, 9, -2.55, -66.9, 9}, 9 * sizeof(float));

现在我不确定因为memcpy将一个静态分配的数组复制到我的p.我的问题是:我的阵列仍然是动态分配的？

编辑:我的问题是指第二个代码.

使用以下有效负载语法，我试图实现彩色通知：

const payload = {
  notification : {
    title : "App title",
    body : "You have new messages",
    icon : "not_icon_white2",
    color : "#2a6d57",
    sound : "default",
    click_action : "do something"
  }
};

状态栏中的图标显示正确（为白色），但在通知抽屉中我的通知行为如下：

标题颜色正确，但通知图标仍为白色，导致视觉体验不佳。

我正在使用（如您在上面看到的）color负载中的属性，该属性也应该更改图标的颜色。

官方文档：

color 可选，字符串 通知的图标颜色，以#rrggbb 格式表示。

为什么通知图标颜色没有更改为我在负载中指定的颜色？

图标可绘制（带有透明部分的白色图标）可能是这里的原因吗？

注意：这个问题是关于 FCM通知有效载荷而不是数据。此外，问题是关于发送内容的背景情况，而不是前景。

我们有官方文档展示了 Compose 中向后写入的示例：

@Composable
fun BadComposable() {
   var count by remember { mutableStateOf(0) }

   // Causes recomposition on click
    Button(onClick = { count++ }, Modifier.wrapContentSize()) {
        Text("Recompose")
   }
   Text("$count")
   count++ // Backwards write, writing to state after it has been read
}

我很清楚，更新State可组合对象内的对象会导致向后写入。这种向后写入的规定效果是我们最终会得到无限的重组循环。

然而，有趣的是，count++可组合项底部的增量操作不会触发无限循环的重组。基本上，在 的第一个组合中，一切看起来都很好，因为即使我们在 的主体末尾BadComposable进行了更新，也没有额外的重新组合。countBadComposable

但是，如果您随后按下Button，则回调count++内的增量操作onClick将触发无限的重组循环。

为什么我们必须按下 来Button触发无限循环的重组？ 我期望读取一个值并在可组合项的主体中更新它以获得这样的效果就足够了。

Jorge Castillo（感谢您的帮助）暗示这可能是因为状态对象的第一次更新发生在注册 count初始重组范围之前。这个想法的来源。BadComposable

有人可以解释一下为什么以下代码的结果是9？我真的很困惑..

#include <stdio.h>

int main (void)
{ 
   int a = 3, rez;
   rez = a-- + (-3) * (-2);

   return 0;
}