【问题标题】:Retrofit post using Firebase使用 Firebase 改造帖子
【发布时间】:2016-06-13 20:29:15
【问题描述】:

请任何人帮忙。这是我的 API 方法

@POST("/user/new.json")
Call createUser(@Body User user);

这是我在MainActivity的电话

 Retrofit retrofit=new Retrofit.Builder().baseUrl("https://XXXXXX.firebaseio.com").addConverterFactory(GsonConverterFactory.create()).build();

    Api api=retrofit.create(Api.class);

    User user=new User(1,"Sam");

    Call<User> call=api.createUser(user);
    call.enqueue(new Callback<User>() {
        @Override
        public void onResponse(Call<User> call, Response<User> response) {
            Log.d("sam","run");
        }

        @Override
        public void onFailure(Call<User> call, Throwable t) {
            Log.d("sam","error");
        }
    });

这是User.java

public class User {

        int id;

        String name;

        public User(int id, String name) {
            this.id = id;
            this.name = name;
        }
    }

输出是这样的:-

"user" : {"new" : {"-KBgcQTomo8xGpnv5raM" : {"id" : 1,"name" : "Sam"}}}

但我想要这样的输出:-

"user" : {"new" : {"id" : 1,"name" : "Sam"}}

这是Retrofit + Firebase的教程

请帮忙........

【问题讨论】:

  • 请修改您的 API。无论您收到什么 API 发送。此外,没有一个 JSON 看起来有效。缺少}
  • @Rohit 你能帮我改变一下吗.....
  • 公共接口 Api { @POST("/user/new.json") Call createUser(@Body User user); }
  • 到底 }} 我忘了..
  • 由于你使用的是firebase,所以最好使用他们的Android库而不是使用Retrofit。在此处查看更多信息:firebase.com/docs/android/guide

标签: java android firebase retrofit2


【解决方案1】:

正如@sushildlh 所说,在这种情况下使用改造并不值得(如果我们正在考虑请求发送/响应计时器),但这是一个很好的 android 编程实践。而且我相信你仍然应该使用改造。

但这不是重点。您的问题出在 Firebase 上的 API 中。创建您自己的 json 文件,其中包含您想要获取的响应并将其上传到 firebase。

干杯

【讨论】:

    【解决方案2】:

    在 firebase 中,当您 POST 尝试推送到存储在 POST 的 URL 下的 list of data 时。因此,不可能 POST 到 /user/new.json 并且不将数据存储在新的 firebase 生成的密钥下,例如 /user/new 下的“-KBgcQTomo8xGpnv5raM”。

    如果您想完全控制数据的放置位置,您必须使用PUT。但是,将您的新条目直接作为 /user/new 是没有意义的。后续条目会去哪里?

    如果您不接受服务器端密钥分配,那么通常的解决方案是使用您将强制唯一性的条目的某些部分。例如,名称或数字 id 可以是新用户的键,以便可以添加多个用户。

    基于改造 API 并使用名称作为唯一键,这样:

    @POST("/user/new.json")
    Call createUser(@Body User user);
    

    会变成:

    @PUT("/user/new/{name}.json")
    Call createUser(@Path("name") String name, @Body User user);
    

    和:

    Call<User> call=api.createUser(user);
    

    然后是:

    Call<User> call=api.createUser(user.name, user);
    

    现在的布局是:

    "user" : {"new" : {"Sam": {"id" : 1,"name" : "Sam"}}}
    

    所以未来的用户只要不被命名为 Sam,就可以添加。

    【讨论】:

    • 你在@Path("name") String name 中得到这个名字的方式是-KBgcQTomo8xGpnv5raM。很难识别那个匿名的名字。我已经完成了 PUT,DELETE,GET 但我只有 POST 的问题。
    • @sushildlh ,如果您使用 POST,无论您创建什么都会在这种随机性的路径中获得新的叶子。如果你使用 PUT,你可以控制你放置的 url 中的整个路径,但是如果你想支持多个东西,你需要在改造中使用路径操作。
    • @sushildlh ,如果您希望避免随机密钥 ID,那么您正在尝试 PUT。发布的全部意义在于它会生成这些内容,因此您可以向父母发布并获得一个新的非冲突孩子,次数不限。您可以使用 put 完全按照您的需要制作自己的路径/键,或者使用 post 接受随机 id..
    【解决方案3】:

    我认为您不必使用Retrofit 来发布数据。

    Firebase 中有 Way to Saving 数据。您是否知道 Firebase 在后台管理所有事情。

    我不知道您为什么要使用 Retrofit 发布数据。

    片段自动发送和更新。

    public class User {
        private int birthYear;
        private String fullName;
    
        public User() {}
    
        public User(String fullName, int birthYear) {
            this.fullName = fullName;
            this.birthYear = birthYear;
        }
    
        public long getBirthYear() {
            return birthYear;
        }
    
        public String getFullName() {
            return fullName;
        }
    }
    
    Firebase alanRef = ref.child("users").child("alanisawesome");
    
    User alan = new User("Alan Turing", 1912);
    
    alanRef.setValue(alan);
    

    您还可以将数据直接保存到数据库位置:

    //在其父节点上使用 .child() 引用子节点 alansRef.child("fullName").setValue("艾伦·图灵"); alansRef.child("birthYear").setValue(1912);

    它会随心所欲地保存:

    {
      "users": {
        "alanisawesome": {
          "birthYear": "1912",
          "fullName": "Alan Turing"
        }
      }
    }
    

    请关注文档:Saving Data in Firebase

    谢谢。

    【讨论】:

    • 我使用改造 bcoz 改造的响应时间与 firebase 相比是好的......无论如何,谢谢响应
    • 亲爱的,你将如何使用 Retrofit 和 Firebase。
    • 欢迎您,如果您能做到这一点,请告诉我。正如我想学习的那样。继续努力吧。继续#RetroFiring。 :)
    • 1) 答案应该按照 OP 的要求提供 Firebase + Retrofit 案例的解决方案,而不是建议使用 Firebase SDK。 2) 最好的做法是实现将来可以更改的 REST API,而不是使用在完全重写之前需要坚持使用的专有 SDK...
    猜你喜欢
    • 2017-12-29
    • 2014-06-11
    • 1970-01-01
    • 2020-01-24
    • 1970-01-01
    • 1970-01-01
    • 2011-11-09
    • 2022-12-10
    • 1970-01-01
    相关资源
    最近更新 更多