4 Replies
      Latest reply on Dec 15, 2016 2:05 AM by eskimo
      bloemy7 Level 1 Level 1 (0 points)

        Hi guys,


        I have built an app that I've been working on for a little while. I basically started learning Objective-C while programming it so I have made some gross misconception errors, mainly in the whole web service part.


        Right now, I have about 10 views that all require data from a web service (an API that returns the data in jSON). The required data is slightly different from page to page. Currently, I call all the method straight from the views themselves -- this leads to a lot of code duplication, mainly in verifying if data is nil, and so on.


        I know that I need to centralize the whole web service part in classes, but I'm a bit lost at how I'm supposed to do this. Where should I start? What should the structure look like?

        Right now I use NSUrlConnection to make an asynchronous request. I then use NSJSONSerialization to parse my data, and I basically just store it in NSMutableArrays or an NSDictionnary.


        I'm pretty sure there are some tools out there that could even do this whole management for me? Any recommendations?


        I would really, really appreciate your help. Thanks a lot!

        • Re: Best practice for web services data management?
          eskimo Apple Staff Apple Staff (13,905 points)

          My general advice on this front is to separate your networking code from your view controllers by way of model objects.  That is:

          • Have your view controllers display a set of model objects, reacting to changes in the model objects as they occur.

          • Have your network code change those model objects as network requests complete.

          This has a bunch of advantages, the most important being that you can write and test your view controller code without actually doing any networking and vice versa.

          To make this idea more concrete, let’s imagine an app that needs to display a photo gallery fetched from the network.  When the user taps an a gallery you’d push the gallery view controller and, as part of that, give it a reference to some gallery model object.  That model object has a list of photos in the gallery, where each photo has a thumbnail.  Initially that list is empty, so the gallery view controller displays a loading screen.  The gallery view controller would also observe the gallery for changes, updating its UI as the gallery model object changes.

          At the same time you push the gallery view controller you also tell the networking code it’s time to update the gallery.  It would go off to the the network to download the gallery index.  Once it has that, it can update the list of photos in the gallery model object.  It can then start fetching photo thumbnails, which also get put into the corresponding model objects.  As these changes happen, they trigger anyone observing the gallery (like the gallery view controller discussed above) to update their UI.

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"