Making Rootobject in model class while consuming WEB APIs through HTTPClient or RESTSHARP

Why is there a Rootobject method in the following code. I got it from the xamarin form samples HTTPClient project. WHen do we have to make it? DO we need it for a User model class?

public class Earthquake
    {
        public string eqid { get; set; }
        public float magnitude { get; set; }
        public float lng { get; set; }
        public string src { get; set; }
        public string datetime { get; set; }
        public float depth { get; set; }
        public float lat { get; set; }

        public string Summary {
            get{ return String.Format ("Date: {0}, Magnitude: {1}", datetime.Substring(0, 10), magnitude); }
        }

        public override string ToString ()
        {
            return String.Format ("{0}, {1}, {2}, {3}", lat, lng, magnitude, depth);
        }
    }

    public class Rootobject
    {
        public Earthquake[] earthquakes { get; set; }
    }

Best Answer

Answers

  • JSCote.7213JSCote.7213 USMember

    I don't think it has anything to do with HTTP Client or RestSharp but rather with how the application is structured and what is used for bindings. I can imagine that there is a list view somewhere in that app that binds to the earthquakes property of the RootObject. The earthquake object can then be used to show the different properties of the earthquake itself. It is probably also used if there is a form showing the details of an earthquake.

    Will you need it if you build a User Model? Are you going to support multiple users in the same application? Are you going to show a list of the users? If so, you most likely need a View Model (and not a model) that has a list of users, similar to the RootObject. In that case, it would probably be not called RootObject, but maybe something like UserList(ViewModel).

  • boomboomboomboom USMember
    edited April 2015

    @JSCote.7213 , yes I am going to support multiple user through my application. It is for an online shopping store, where users can login. I have a RESTFUL Web api and use it for Xamarin.Form project. I wont be showing any list of user or anything else, it is just for the consumer side, not admin. What kind of method should i make for a LogIn in the WebServices class?

  • JSCote.7213JSCote.7213 USMember

    Your question is become more of a architecture and design level. Are you sure you are going to support multiple users in the client app? I think you probably mean you will have multiple users connecting to the server. On the client app, do you want multiple users to use the application, on the same device?

    I suggest you get yourself acquainted with MVVM principles (if you aren't already). As far as authentication, or login, there are tons of ways to do this. On the client side, you may want to keep the user/password combination saved in SQLite (encrypted of course) and have a model representing your user, with a login method on it. When a user is starting your and is not logged in already, you can then popup a modal dialog to ask for user/password, validate against your model and move forward on successful login. If you require to do login on the server side, instead of storing the info in SQLite, you can make a call to the web service from your login method.

    I feel I'm just surfacing the problem and a more in-depth discussion would be required.

  • boomboomboomboom USMember

    @JSCote.7213 do you have any sample projects using restsharp or anything for xamarin forms?

  • JSCote.7213JSCote.7213 USMember

    Unfortunately, not at the moment

  • boomboomboomboom USMember

    @JSCote.7213 any ideas about sessions in Xamarin.forms?

  • JSCote.7213JSCote.7213 USMember

    I would maintain the information about the "session" in an object you keep as a static reference in you Application.

  • SKallSKall USMember ✭✭✭✭

    If you write your own REST services (with C#) then there is no need to generate the classes as you would define them in your shared code and reuse on the client.

Sign In or Register to comment.