March 16, 2018 Meeting

Continue working on project teams for:

  • Weather Wear Web Service in C#
  • Swift client to consume the Web service and display results

Data Model Classes so far:

  • Both of our projects already have Class definitions that we created to represent the results of the Web Service call to Weather Underground’s Web API for the forecast
  • To allow the automatic decoding of the response to map to our defined Classes, the Property names in these class definitions must match the exact names of the names in the JSON object coming from the Web API Response, including Case sensitivity
  • If a Property name conflicts with that of a reserved word in the language we are using (C# or Swift) the name must be “escaped” using a special character. An example is “in”, used for inches in the API Response
      • In C# precede the name with “@”, so use “@in”
      • In Swift enclose the name in back-ticks, ‵in‵

     

  • WeatherWear C#:
    • In the C# solution “WeatherWear”, the Class Library project “WWClassLib” has a Models folder to hold our Class definition(s) for the Web API data models.  These data model classes correspond exactly to the JSON object(s) returned in the API Response
    • Forecast.cs is the C Sharp file that defines the classes for the Forecast API response in a fairly complex nested class structure with multiple layers of classes within classes
    • The top-level class is named “RootObject” in our model
  • Weather Swift:
    • In the Swift solution “Weather”,  we also created a Models folder to hold our Class definitions for the Web API data models corresponding to the JSON
    • WeatherForecast.swift is the Swift file that defines the model classes, using the exact same nesting structure as in the Web API’s Response and in the WeatherWear C# solution
    • The top-level class is named “WeatherForecast” in our model

Should we use Object Inheritance to model the custom API Response?

  • The Web Service team is working on the engine to process the Response from the Weather Underground Forecast API and determine what to wear. This will then be used in our custom Web API to enhance the results from the original Response by adding one or more properties that contain the wardrobe advice
  • The Swift team will need to add a Web Service call to the custom API so the wardrobe advice can be displayed along with selected information from the forecast
  • Both teams already have the “base” Model classes defined, are able to map the “base” API response to the Model, and are displaying selected fields on the console or on the app’s screen
  • Should we agree on a new Model definition that “inherits” the original but adds the custom fields needed for Weather Wear? Both Swift and C# would use the same property names. Inheritance allows us to extend an existing Class, creating a new Class that contains all the same Properties of the base Class but adding new ones.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s