February 9, 2018 Meeting

This week we will continue working in our smaller teams developing the Web Service and the iOS app.

Web Service Team:

Last week the team completed the tutorial Create a Web API with ASP.Net Core MVC and Visual Studio for Mac or the equivalent version for Windows Create a Web API with ASP.Net Core MVC and Visual Studio for Windows

The team successfully completed the parts of the tutorial that got a Web Service running locally and allowed users to exercise GET requests

This week, we can use that foundation to add a new controller to the project to handle the GET request for our custom Weather Wear service that will return a JSON Response. The team can talk through design approaches and algorithms to decide what exactly the service should do and what additional components are needed. For example:

Should there be a Class library that will handle :
- Sending a Request to the Wunderground API to get the weather?
- Parsing the JSON results? How much of this is this needed here? Should the client of our API do some of this?
- Logic to determine what our custom Response should add to the Response of the Weather Service
- Define a Class that is a Model for our custom objects?
For the Controller for our Web API:
- What parameters (if any?) should our GET Request(s) take?
- Do we want more than one form of GET Request? Request by Zip Code? Request by City/State? Any others?? Decide on one for the initial iteration.
- What Route name would we use? Attribute Routing in Web API
Take a look at Robin’s prototype code that includes a Web Service, a Class Library, and a Console App as Client

iOS Swift Team:

Last week, the team successfully completed the Hello World tutorial in the first chapter of the book Coding iPhone Apps for Kids The link is to the book on Amazon where you can download the first Chapter as part of the free Sample. Following the tutorial, we were able to run the Hello World app on our iPhones/iPads attached via USB to the Macs running XCode. However, we did run into one problem with “provisioning” where an Apple ID used to sign the code was not getting successfully recognized as provisioned. Apple requires all Apps to be signed with a valid id in order to run on any attached device. It may just have been a slow lag time in having the credentials go through. We will take another look at it if still an issue. This is a forum that explains a bit about dealing with the issue: Forum discussion on iOS signing and provisioning issue

This week the team can work on developing the User Interface for the App using the Storyboard in XCode to add “views” to the screen. In XCode a View is an object on the screen (a more generic description would be a widget) . Some are controllers with which the user can interact (buttons, switches, text input boxes, etc.) and some are display only, such as labels. Design the view for the app, determining what is appropriate for input and display.

What will the Web Service need for us to send the Request? Will it be Zip Code, City/State? Check with the Web Service team to find out their specifications for the Request. Provide the appropriate user experience for inputting the required information. Think about restricting the input to valid values. If a Zip Code is required, what can we do to make sure the user only enters digits and that it is in proper format? If we need a State is there a way to only allow selection of a valid state abbreviation?
When you get the results back from the Web Service API Request, how should it be displayed? What information do you want to display?
Do you want more than 1 screen? One for Request and one for Response? Or some other design
Add the appropriate views (widgets) for entering the Request and displaying the Response
We will take an initial look at how to hook up code to our UI:
- Look at the ViewController.Swift class that is created automatically by the project
- Add code in the ViewController that connects our “views” on the StoryBoard to the code; we will do this by control-dragging from the view to the code
  - @IBOutlet: Each outlet becomes a property in our ViewController class that is connected to a View (widget) on our screen. This allows us to use code to get or set the value as appropriate
  - @IBAction: This becomes a method of our ViewController class that is connected to an Action such as a Button is pressed, the screen is swiped, a gesture is made, text is entered, etc. We set up the connection here, and then write code in the method to say what should happen when the action occurs