Firebase的一些小坑

当你再也没有什么可以失去的时候，就是你开始得到的时候。

当前我们公司开发的应用用到了google的firebase。在使用中发现了一些坑，在此做一个记录

1号坑----Firebase字段重命名

日常开发server返回的字段名可能会修改，比如server_res字段改成serverRes。这种修改对客户端往往影响巨大，客户端为了将这种修改后的影响降低到最小，往往会使用SerializedName注解。比如下面的一段代码。

@Data
public class ServerRes {
    @SerializedName("big_icon")//server返回的字段是big_icon
    public String bigIcon;
}

我们使用了lombok注解避免重复的get/set方法，同时用SerializedName注解将server真正返回的big_icon字段重命名为bigIcon，这样带来的的好处是如果server在后续版本迭代中将big_icon重命名为big_ic,客户端只用修改成@SerializedName(“big_ic”)即可，其余的逻辑不用改动，保证了最小改动。

在使用firebase的过程中，我也尝试遵循上述原则，但发现每次解析firebase的字段都返回空。多次失败后才发现是我用SerializedName注解导致的，查询文档后发现firebase提供跟@SerializedName类似的@PropertyName(“xxx”)注解方法，但如果要配合lombok的@Data注解还是不工作。
具体原因在下面这个link里有说明：

https://stackoverflow.com/questions/45306168/firebase-serialization-names

如果要考虑到兼顾字段变更，那么可以如下修改：

public class ServerRes {
    @PropertyName("big_icon")
    public String bigIcon;

    @PropertyName("big_icon")
    public String getBigIcon() {
        return bigIcon;
    }
}

2号坑----Firebase配置Map类型的数据结构

Firebase也可以配置Map结构的数据，如下图：

我们想定一个key为1，value包含的big/small属性的对象。但最终出来的数据格式却如下图：

key为1直接不见了，反而多了一个null，Firebase将其按照数组来解析了，并不是我们想要的，这个问题折腾了我好久才找到原因。这个的解决办法是key不要定义成纯数字，比如我们定义key为“_1”:

就可以最终解析成了我们想要的

总体来讲firebase还是挺好用的，如果你的应用面向国外用户，推荐集成它。