Flatiron School Week 7 – Week in Review

Topics: APIs + Core Data, Authentication, Multithreading

Mistakes and Lessons

Symptom: API calls don’t tell you a lot when they don’t work. I wasn’t getting anything out of an internet request. Debugging API calls can feel like a text based adventure.

Mistake: Errors in strings are hard to debug. Apparently, when I had made the url, there was an extra “%”.

Lesson: Copy and paste urls that work from Postman, or use an encoder to convert strings to urls.

Symptom: When I changed the colors in my bocce game, the logic for choosing the next team to go broke.

Mistake: I had changed my colors away from the default colors (e.x. blueColor) to RGB values and had used == to compare the objects. The correct way to compare the objects is using an isEqual. Turns out that when you use [UIColor colorName] using == to compare is ok because they are at the same memory location.

Lesson: Use isEqual with objects and == with primitives.

Notes to Self

There are some times when I just have to slow down and plan out how something works. I was making a tableView that updated an API and a Core Data store. This very quickly got too complicated to keep in memory and I had to write down the interactions step by stem.

My partner and I decided to divide and conquer a lab. It became very hard for me to test along the way, because I was dependent on his piece to make mine work.

“If You Want To Go Fast, Go Alone. If You Want To Go Far, Go Together”

Flatiron School Week 5 – Questions to ask before choosing an API to work on

In the last post, I ended by saying that developer time is valuable and to be selective about which APIs to work with. This post is going to talk about how to choose an API.

Why are you using the API?

If you’re building something for educational purposes or for fun, then the last two questions matter less. The questions are more geared towards people who want to build something that will be a good business or a feature that you want the company to add to their app.

What would be fun to work on?

If I’m into restaurants, Yelp and Foursquare easily come to mind.

Does the API solve your problem?

API limit what functionality they provide, called endpoints. Let’s say that I want to look at photos for restaurants. Do the Yelp and Foursquare APIs give me photos? They both do.

If I was looking for check-in information, Foursquare would have the edge because they were built on the check-in functionality.

What are the rules around API usage?

In their documentation, API typically have rules around how they can be used.

Foursquare’s rules are pretty open and clear on exceptions. I’m not sure if I would be “recreat[ing] the functionality of Yelp’s own website or mobile apps,” with the photo idea, which they say not to do.

Both APIs require attribution.

Foursquare only allows 4 pictures or tips to be shown from any one business.

With Yelp’s API, no data can be stored, while Foursquare requires that you refresh the data.

How easy is it to use? How well is it documented?

Good documentation is super helpful when you’re first starting out. I like that Yelp shows an example of their business response. Clarity around rules is also a must because it reduces hesitation over ambiguity.

How does the company treat it’s developers?

Do they communicate changes early in advance? Who owns the app that you make?

Foursquare seems to remove functionality and gives a few months for developers to adjust.

What is the longevity of the platform?

Deprecation of API features does make you wonder what they will remove next. How long do you think you can continue to use the API? How long before something else comes along that’s more popular?

In my hypothetical example, I have seen that Yelp has better search results though. In the end, I would choose Foursquare because it seems like you are free to do more with it.

Flatiron School Week 5- What are APIs and why do they exist?

Application programming interfaces (APIs) allow you to talk to the API provider.

As iOS programmers, we have interface and implementation files for our objective-c classes. They allow other classes to communicate with our classes’ methods and properties. In fact, we use Apple’s API to build these programs. How does a tableViewController actually work? That’s in Apple’s implementation files. We only get to see the interface to be able to use it. This is the same with other companies’ APIs.

It seems like everyone has an API now, but why are they valuable?

An API provides easy access to data that takes years to build

Let’s take Yelp for example.

What value does the Yelp API have for an independent developer?

An API

provides an easy way to use the company’s location data, so that I don’t have to build my own location service.
states what the company allows you to do with their information, so that you don’t get in legal trouble with them.
gives you an opportunity to show your developer skills and interest in the company in case you want to work for them.

The more people that use a website or service, the better for the company

Since there’s no such thing as a free lunch, why are they allowing you access to their API?

Yelp wants you to use their service over Foursquare. If your app uses Yelp, then makes Yelp more popular.
If Yelp didn’t have a Windows Phone app, then you could built one for that new platform without hiring you to develop for them. If the Yelp app wasn’t as good as it is, then someone else can come in and build it better, but still drive the traffic to Yelp.
The company can see what new third party ideas are working well and adjust to what the market wants.
They can collect the data that you generate.
APIs are good for their internal developers too, so that developers can focus on their area and not have to learn how everything else works.
The reality is that you can set up a computer to access their information without an API. For example, aggregators like Mint can be a real pain to banks. Having the API, allows them to better monitor who is accessing their data.

APIs look like a win-win situation, but be choosy

APIs make possible crazy cool mashups. Just remember that the API owner wants you to work on their platform because they benefit too. As a developer, your time is valuable, so be selective and intentional about which APIs you work on.

Flatiron School Week 4 Mistakes and Lessons

Topics: Cocoapods, Core Data

Symptom: The search functionality works most of the time but in a small set of users, the search results are empty.

Mistake: Sending an API call in the prepareForSegue method.

Let’s say that we have a view controller that searches Foursquare for restaurants. If I press submit on my search view controller, I’m pushed to a table view controller with the results. I can put the API call to fetch the data from Foursquare in the prepareForSegue call.

99.5% of the the time, it works, but the other 0.5% of the time, the previous view controller can be removed before our API call has come back with the results and we’ll be left with a table view controller with no results.

This is called a race condition and it’s a very annoying problem to fix because it’s hard to detect and I would have to have millions of users like Facebook to have this problem.

With search view controllers, pass the query to the results view controller and send the API call from there.

Lesson: Avoid race conditions always.

Symptom: I was trying to test a tableViewController to make sure that it worked with Core Data by adding 3 test objects: @”Test”, @”Test Test”, and @”Test Test Test”. I was only seeing one of the three items repeated three times.

Mistake: Messing up basics when moving on to more advanced topics.

I wasted a couple hours last week when I messed up the cellForRowAtIndexRow by writing

cell.textlabel.text = self.store.pirates[[self.tableview indexPathForSelectedRow].row];

instead of

cell.textlabel.text = self.store.pirates[indexPath.row];

Lesson: Watch for simple mistakes, when something is not working as expected.