A networking layer for iOS and tvOS.
🤖 Looking for the Android version? Check it out here.
Documentation is automatically generated from source code comments and rendered as a static website hosted via GitHub Pages at: https://yml-org.github.io/ynetwork-ios/
You will need to instantiate a NetworkManager either in your AppDelegate, SceneDelegate or other top-level application coordinator. You should then use Dependency Injection to pass it to the various service layers or view models that need it.
NetworkManager can be extensively configured via a NetworkManagerConfiguration object and/or by subclassing, but for basic functionality neither is required.
// Declare an instance of the network manager, so that it can be injected where needed.
private let networkManager = NetworkManager()Each network request you issue will be its own object (class or struct) that conforms to the NetworkRequest protocol. This protocol allows you to configure many things about your request (path, method, query parameters, body, timeout, headers, etc.) but it has sensible defaults so that the only mandatory property is path (which endpoint to hit).
struct GetUsersRequest { }
extension GetUsersRequest: NetworkRequest {
// which endpoint to hit
var path: PathRepresentable { "https://myendpoint.com/api/v1/users" }
}Then you would issue a request like so (where the request will either return an array of User objects or else throw an Error). The following example shows how to use the modern async / await approach, but there’s also a completion handler based override of submit.
func fetchUsers() async {
let request = GetUsersRequest()
do {
let users = try await networkManager.submit(request)
// handle success
} catch {
// handle failure
}
}NetworkRequest supports relative paths by having both basePath and path properties. path is treated as an absolute path when basePath is nil (the default), otherwise it is treated as a relative path when basePath has been specified. We recommend the use of enum's to list your applications base paths and paths.
enum MyApiBasePath: String, PathRepresentable {
case prod = "https://myendpoint.com/api/v1"
// In a real app you'd probably have additional development endpoints
// such as dev, qa, uat, sandbox, etc.
}
extension MyApiBasePath {
// convenience property to point to the current environment
static var current: MyApiBasePath = .prod
}
enum MyApiEndpoints: String, PathRepresentable {
case users
}You could then declare a new request protocol for each different api server that your app supports.
// You can declare a new protocol for each major endpoint your app supports
protocol MyApiRequest: NetworkRequest { }
extension MyApiRequest {
// All requests sharing the same base path
var basePath: PathRepresentable? { MyApiBasePath.current }
}Then each request can derive from the protocol specific to their api server.
struct GetUsersRequest { }
extension GetUsersRequest: MyApiRequest {
// which endpoint to hit
var path: PathRepresentable { MyApiEndpoints.users }
}Most api’s have some requests where the path contains a unique identifier. Adding associated values to your endpoints enum is a great way to handle these. It requires a slight reconfiguration in how our endpoint enum is declared.
enum MyApiEndpoints {
case users
case user(id: String)
}
extension MockApiEndpoints: PathRepresentable {
var pathValue: String {
switch self {
case .users:
return "users"
case .user(let id):
return "users/\(id)"
}
}
}Then you could declare a request for a specific user like so:
struct GetUserRequest {
/// Id of the user to fetch
let userId: String
}
extension GetUserRequest: MyApiRequest {
// which endpoint to hit
var path: PathRepresentable { MyApiEndpoints.user(id: userId) }
}You can add Y-Network to an Xcode project by adding it as a package dependency.
- From the File menu, select Add Packages...
- Enter "https://github.com/yml-org/ynetwork-ios" into the package repository URL text field
- Click Add Package
brew install swiftlint
sudo gem install jazzy
Clone the repo and open Package.swift in Xcode.
We utilize semantic versioning.
{major}.{minor}.{patch}
e.g.
1.0.5
We utilize a simplified branching strategy for our frameworks.
- main (and development) branch is
main - both feature (and bugfix) branches branch off of
main - feature (and bugfix) branches are merged back into
mainas they are completed and approved. maingets tagged with an updated version # for each release
feature/{ticket-number}-{short-description}
bugfix/{ticket-number}-{short-description}
e.g.
feature/CM-44-button
bugfix/CM-236-textview-color
Prior to submitting a pull request you should:
- Compile and ensure there are no warnings and no errors.
- Run all unit tests and confirm that everything passes.
- Check unit test coverage and confirm that all new / modified code is fully covered.
- Run
swiftlintfrom the command line and confirm that there are no violations. - Run
jazzyfrom the command line and confirm that you have 100% documentation coverage. - Consider using
git rebase -i HEAD~{commit-count}to squash your last {commit-count} commits together into functional chunks. - If HEAD of the parent branch (typically
main) has been updated since you created your branch, usegit rebase mainto rebase your branch.- Never merge the parent branch into your branch.
- Always rebase your branch off of the parent branch.
When submitting a pull request:
- Use the provided pull request template and populate the Introduction, Purpose, and Scope fields at a minimum.
- If you're submitting before and after screenshots, movies, or GIF's, enter them in a two-column table so that they can be viewed side-by-side.
When merging a pull request:
- Make sure the branch is rebased (not merged) off of the latest HEAD from the parent branch. This keeps our git history easy to read and understand.
- Make sure the branch is deleted upon merge (should be automatic).
- Tag the corresponding commit with the new version (e.g.
1.0.5) - Push the local tag to remote
You can generate your own local set of documentation directly from the source code using the following command from Terminal:
jazzy
This generates a set of documentation under /docs. The default configuration is set in the default config file .jazzy.yaml file.
To view additional documentation options type:
jazzy --help
A GitHub Action automatically runs each time a commit is pushed to main that runs Jazzy to generate the documentation for our GitHub page at: https://yml-org.github.io/ynetwork-ios/