Skip to content

Latest commit

 

History

History
85 lines (48 loc) · 4.6 KB

README.md

File metadata and controls

85 lines (48 loc) · 4.6 KB

CocoaUPnP

Build Status codecov Pod Version

CocoaUPnP is a logical progression of upnpx - designed to be easy, modern and block-based. It is written in Objective-C and is currently available iOS. Mac OS X compatibility is currently unknown, but we don't see a major reason why this wouldn't work.

Why not Swift?

There are a few reasons why we didn't opt for Swift for the first version of this library. Firstly, the app we are using this in is entirely Objective-C. We need it written fast, so Objective-C was the way to go. Additionally, the app targets iOS 7, so we are unable to use dynamic libraries generated by CocoaPods. Additionally, there was some initial friction with early Swift versions that required a lot of maintenance.

It is highly likely that the library will be ported to Swift at some point, but I am unable to give a specific timeline. If you want a UPnP library for your Swift project, I can recommend UPnAtom.

Project timeline

Initially, this project will focus on the Audio/Video Device Control Protocols. Once these protocols have been properly implemented and tested, then the rest of the protocols may be added at a later stage.

Dependencies

We have tried to limit the number of dependencies within the library to only use well tested, used-and-approved libraries. As a result there are only 5 dependencies within CocoaUPnP itself:

  • CocoaAsyncSocket - for connecting to the SSDP protocol.
  • CocoaSSDP - this library has been heavily modified and rigorously tested for use in CocoaUPnP.
  • Ono - for faster and easier XML parsing.
  • AFNetworking - to leverage use of response and request serialising.
  • GCDWebServer - provides most of the socket based functionality of the UPnP event server.

Additionally, the test target uses 4 testing libraries:

Testing

CocoaUPnP is as test-driven as much as possible to ensure confidence that the library works as intended. When submitting a Pull Request, you should run the suite of unit tests to ensure your patch does not break existing functionality. Please ensure you add a test for the new feature you have added. You can look at the existing tests to get an idea of how to do this.

Writing tests

When creating a new class, create a test class at the same time. Tests are written with Specta, with accompanying Expecta matchers.

Both the Specta and Expecta imports are declared in the ExampleTests-Prefix.pch file, so no need to import them in each spec.

Contributing

Pull requests are always welcome. If you feel like getting stuck into the project, there are several ways you can help out.

  • Update documentation (spelling & grammar, etc)
  • Design a neat icon for the library
  • Tackle one of the project's issues
  • Submit a new issue or feature request

Submitting a Pull Request

New features should always be added in a seperate topic branch on your fork. Tests are run through xcpretty, so be sure to install that first.

Fork, then clone the repo:

git clone git@github.com:your-username/CocoaUPnP.git

Change your directory to your CocoaUPnP folder:

cd CocoaUPnP

Install Pods:

pod install

Run the tests to make sure nothing is broken, and your test environment is setup:

make tests

Create and checkout a feature branch:

git checkout -b awesomeNewFeature

Make your changes, then re-run the tests:

make tests

Commit and push to your fork then submit a Pull Request.