Explore Composite UI Components, Local Database and User Notifications on iOS

A third party resource is anything you use in your project that is not created by you (or your organization) or the platform your are developing for - by Apple, in our case.

The shared work, typically, comes in form of a library (or a framework). At times simple source code is shared that you can incorporate in your project.

Pros

Taking advantage of functionality developed by others can definitely benefit your project facilitating faster implementation of suitable solutions. Or, at times, even providing solutions you are, at the moment, not able to implement yourself. On top of the speed and convenience, using others' work presents a great learning opportunity.

There's also a hopeful expectation that the original development team will continue maintaining the code improving it further and adapting it to changed of the platform, so that you can focus on the same for your personal implementation of a project.

Cons

Those libraries are also called dependencies in your project. As they make your code dependent on someone else's work.

It can be bad to use dependencies, here are some of the examples:

• A library is no longer maintained for current iOS SDK, which would prevent you from upgrading your code.

• You require some functionality related to the integrated library, but it's not provided within it, and, at the same time, you already have too much of your application dependent on what's implemented using that library making it unreasonable to split functionality.

• (Ab)using libraries - integrating a library for its non-core purposes. Such as if a library is developed to perform 'XYZ' and you are using it to perform only a tiny 'z'. In this case, maintenance of the dependencies requires more effort than the value provided by a library. 

To depend or not to depend?

Each project is unique and the decision regarding each library needs to be made by considering the full scope of the applicable benefits and limitations. Some points to consider:

• Who's the developer? Does the project have enough funding to keep going? - Even established companies with sufficient resources may abandon a project. When it's not a guarantee, sufficient funding is a good sign of longevity of a library.

• Is it an open source project? Who are the contributors? What's the development history. Consistent improvements by core contributors and active collaboration are considered a good sign.

• Popularity and other developers feedback. Popularity and good feedback from other developers using a library is a good indicator of quality of the implementation. The downside of it (mostly applicable to visual elements) - the more teams use it - the more apps share the same looks - or, simply, look the same.   

• What's your vision for the app? Check with Apple requirements for using various features that may affect your apps positioning or the transfer of rights to a different organization. This may especially affect you in the case you are using a library for X and the library is using another, restricting framework or components to perform Y, which may not be obvious to you as you are not needing Y in your project. 

Even if you discover some red flags at the time of making a decision whether to use a library or not, there are still circumstances to decide for it instead of against it:

• You are short on time and using some external functionality as a quick fix that you know you can revise in the near future

• You are prototyping and running quick tests

• For learning purposes 

Using your own libraries

It's not unusual to create your own library (or a library developed by other teams in your organization) which makes sense to incorporate it in different projects.

Those are dependencies as well - relative to the project you are incorporating them in. This is good and bad news at the same time.

It's good because you (or another team) are in power to improve and maintain it.

It's bad because you (or another team) are responsible to improve and maintain it.

There are a couple of ways to integrate 3d party resources in your project:

• Using dependency management tools

• Manually importing a library

• Simply including source code in your project (if available)

Each of the methods has its pros and cons. Using dependency management tools is the most automated way to import and maintain libraries in your project.

In relation to iOS projects, Cocoapods used to be the king. With Swift coming along Carthage has now taken over.

What's in it for Amazing?

We are still to incorporate some analytical tools for the user to analyze their emotions over time. Let's remind ourselves of how it could look like:

In order to implement that, we'll need an ability to build diagrams. Surely, Apple's SDK has all the necessary capabilities to implement those.

After looking around however, we may discover that someone's already done an excellent job on that by creating Charts!

Discover Charts

Charts is a framework created by Daniel Gindi. Positioned as - Beautiful charts for iOS/tvOS/OSX! Can be found on GitHub.

Each library distribution is supplied with a README.md file in a repository that presets lots of useful information about the project:

• It's purpose, history, inspiration

• Screenshots and demos

• Potential restrictions

• Latest updates and backward compatibility, breaking warnings

• Instructions on how to install and use it

So, let's proceed with the installation !

We are going to add the library as an embedded framework into our project.

Download the project from Charts repository:

Unpack downloaded .zip file.

Next, drag the Charts.xcodeproj to your Amazing project :

Add the new framework to the list of frameworks of the Amazing project:

This is what you get as a result:

Switch to AnalyticsViewController.swift and import the new library:

import Charts

Let's compile it Command + Bto make sure we didn't break anything...

Well, that's it! In the next chapter we'll get to implement the functionality!

• Third party resources are libraries developed by an external organization or individual.

• External libraries become dependencies in the project that incorporates them and require maintenance efforts.

• External libraries should be used if:

  • Essential to the project

  • Nice to have and appears as a proven library 

  • For temporary implementation 

• Adding a library to the project may be done:

  • Using dependency management tools, such as CocoaPods or Carthage.

  • Manually embedding library into a project

  • By adding source code to the project (if available)