Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MapSwift - lesson 6

leveton
May 22, 2017
31

MapSwift - lesson 6

leveton

May 22, 2017
Tweet

Transcript

  1. Parsing JSON Now that we have an Objective-C friendly model

    of our data in the form of an Dictionary, we grab an array from the dictionary and enumerate through the array. Finally we use a custom selector to convert the ‘object’ in Javascript Object Notation into an MSLocation.
  2. Annotating our map Notice at the end we can add

    a location object as an annotation on our map? In the MSLocation header file we’ve added <MKAnnotation> Next to our interface declaration.
  3. Annotating our map This means that MSLocation conforms to the

    MKAnnotaion protocol. So as long as MSLocation follows certain rules (in this case setting a coordinate struct). The map will drop pins based on the coordinates that we set, and, if you tap on the pin, display the title string that we set.
  4. Use setLocation to build a detail view Now our goal

    is to populate the table in MSLocationsViewController. We also need to allow our users to tap on any cell and get a detail view of that location. At the end of populateMap, we get a reference to our MSLocationsViewController by grabbing it from the tab bar that handles the navigation for our app. We set its datasource with the new data, reloading the table in the setter’s implementation.
  5. Use setLocation to build a detail view In MSLocationsViewController, we

    give MSLocationDetailViewController a single location object so that it can build a full location for the user. Typically setting up the detail is begun in our didSelectRowAt IndexPath delegate method:
  6. Understanding dequeue table view cell Backing up a little we

    need to review cellForRowAt IndexPath. One of the most used and important methods in iOS. Let’s change our numberOfRowsInSection to 1000 and implement our cellForRow delegate method like this:
  7. Understanding dequeue table view cell If you run the app

    now and go to locations, you’ll see ‘new cell’ logged out 9 times on an iPhone 4 and 15 times on an iPhone 6-plus. And then ‘old cell’ logged out as soon as you scroll up. ‘old cell’ is logged until you reach the 1000th cell.
  8. Understanding dequeue table view cell What’s happening is that the

    visible cells are created as new cells. When the cells are no longer visible (after scrolling) they are reused by the table. This spares the system from having to create a thousand new objects. Why 9 on the smaller iPhone and 15 on the larger phone? Because the larger phone has more visible cells!
  9. Understanding reuse identifier Looking again at our implementation. We pass

    the dequeueReusableCell instance method an identifier. The identifier tells the table view that we want the same type of cell to always be reused. A “cellid” cell in this case. If you had more than one TYPE of cell on your table, something besides a cell id’d as “cellid”, you would have to create another UITableViewCell object and give it a different identifier.
  10. Understanding reuse identifier The vast majority of the time, you’ll

    only use one type of cell and therefore one identifier for your table.
  11. presenting a modal Back to didSelectRow AtIndexPath, We give MSLocationDetailViewController

    a single location object so that it can build a full location for the user. Upon tap, we call present(:, : , :) on our current view controller which will cause the detail view to present itself from the bottom of the device. (Make sure ‘animated’ is set to true).
  12. Presenting a modal is one of the two main ways

    of presenting new views onto existing views in iOS. We’ll go over the other (popping a view) later.