java - Best design pattern for data model in restrofit rest android app which json data -

i have learned https://www.youtube.com/watch?v=xhxn3kg2iqe best approach flow in application (use service, content provider etc) don't know best practice (design pattern) work data retried , data received. data in json.

so want develop simple app. app make request server login. in response token , json describe voting. after have sent complex json base on user input. kind of form fill up. voting system.

{   "data" : {    "name": "name of kind of voitng",    "general_data" : [ {"name": "n1", "value":1}, {"name": "n1", "value":1}],    "voits": [{"name": "n1", "value":1}, {"name": "n1", "value":1}], }  } 

so have classes mapped json. need represent these data on activity. have 2 classes.

    class generaldataelementjson {  string name;  int value; }     class generaldataelementmodel {  string name;  int value;  boolean isvoited = false; }     class generaldataelementview extends view {} 

now in approach map retrieved data instances of *json classes after convert instances of *json classes instances of *model classes. instances of *view classes adapter instances of *model display.

after user input convert instances of *model classes instances of *json classes , instances of *json classes (using retrofit) converted json , sent server.

so complicated. think there should better approach that. how?

this retrofit. use jsonschema2pojo generate pojo's (model classes). have getters , setters , serialized data use , manipulate wish.

let's you're retrieving data objects. when retrieve data retrofit, throw them list<data>. following code:

public interface dataservice{   @get("/{user}/data")   list<data> listdata(@path("user") string user); }  restadapter restadapter = new restadapter.builder() .setendpoint("https://your.url.com") .build();  dataservice service = restadapter.create(dataservice.class);      list<data> datas = service.listdata("your_parameter"); 

from design standpoint, find elegant way because pojos should change api changes (that is, infrequently). such, it's ok auto-generate code , have black-box reference. best code code don't have write. careful not over-architect.