当你再也没有什么可以失去的时候,就是你开始得到的时候。
当前我们公司开发的应用用到了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还是挺好用的,如果你的应用面向国外用户,推荐集成它。