search

PhilipsHue / PhilipsHueSDK-iOS-OSX

The Software Development Kit for Philips Hue on iOS and OS X (beta)
579 stars 168 forks source link

Cocoapod support #39

Open objectiveSee opened 10 years ago

objectiveSee commented 10 years ago

Will there (is there) a Cocoapod for the core of this Application? Would be a great way to stay up to date with the code provided by philips. Thx!

sebromero commented 10 years ago

+1

twam commented 10 years ago

+1 (preferably without all the sample stuff)

lightbow commented 10 years ago

+1

lightbow commented 10 years ago

This would also make the Lumberjack situation easier

objectiveSee commented 10 years ago

anyone want to work together to tackle this issue ourselves? The hard part is just figuring out which files will be included in the Podspec

objectiveSee commented 10 years ago

I am working on this now. Stuck on getting framework search paths to find the Hue headers https://gist.github.com/objectiveSee/10403016

objectiveSee commented 10 years ago

I have a preliminary version of the Podspec created and it works in my local environment. Can someone test from their env as well?

pod 'PhilipsHueiOS', :git => "git@github.com:objectiveSee/PhilipsHueSDK-iOS-OSX.git"

Include the headers in your project with:

#import <HueSDK_iOS/HueSDK.h>
objectiveSee commented 10 years ago

Has anyone tried to test this?

jjochen commented 10 years ago

Using this in a swift project via a bridge-header seams not to work.

Edit: actually now it somehow works :-)

tychop commented 10 years ago

Awesome. Works !!

What would it take to get 1.3beta in there?

williampower commented 10 years ago

Thanks to @objectiveSee for this, but :+1: for full pod support, please. We shouldn't be manually copying CocoaLumberjack files from a clone of this repo. (https://github.com/PhilipsHue/PhilipsHueSDK-iOS-OSX/pull/76)

ryangittings commented 9 years ago

+1

lightbow commented 9 years ago

Looks like you guy also embed AsyncUdpSocket, which can hopefully be left out of your framework in favor of a simple CocoaPods dependency.

lightbow commented 8 years ago

It has been over a year since my last comment, so I'll just hit this thread again in case anyone at Philips is listening. The code you have compiled into your framework from external sources is not consistent with industry best practices. You have many developers complaining about old versions of things like CocoaAsyncSocket and Lumberjack compiled into the Philips hue framework rather than simple CocoaPods dependencies. Not only does this make development more difficult for us, but you're missing out on bug and security fixes for these projects that could hurt your end users as well. It's in everyone's best interest to either address some of the longstanding gripes on this project, or release the sources so we can fix them for you. With recent Apple requirements/plans around App Transport Security, IPv6, Swift, Bitcode, and new platforms, there will come a time when issues like this transcend from mere inconvenience to linker errors, runtime issues, App Store rejections, and more.

gorkemg commented 8 years ago

Yeah official Cocoapod please

samuelclay commented 8 years ago

Just FYI to anybody else still watching this repo. I gave up with this library and ported my code over to SwiftyHue. It supports all of the endpoints I was using and took only a single day to port all of my PhillipsHueSDK-iOS-OSX code over. The maintainer is responsive and integrated my PR when I needed more data back from the scenes API.

https://github.com/Spriter/SwiftyHue

cliffspencer commented 8 years ago

I have been trying to use SwiftyHue but it seems to be incomplete at this point. Also it lacks enough documentation to really use it. For example how does one end push link so you don't have to redo it each time the app starts? Another example is the apparent lack of any interface as of yet for setting the lights. Is there anyway to contact the maintainer other than via a PR?

Sent from my iPad

On Nov 25, 2016, at 1:54 PM, Samuel Clay notifications@github.com wrote:

Just FYI to anybody else still watching this repo. I gave up with this library and ported my code over to SwiftyHue/SwiftyHue. It supports all of the endpoints I was using and took only a single day to port all of my PhillipsHueSDK-iOS-OSX code over. The maintainer is responsive and integrated my PR when I needed more data back from the scenes API.

https://github.com/Spriter/SwiftyHue

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

samuelclay commented 8 years ago

how does one end push link so you don't have to redo it each time the app starts

You have to save the username you get back from a successful push link bridge authentication. You can then use that username in your requests' urls.

cliffspencer commented 8 years ago

Thanks, Samuel. Cliff

On Nov 29, 2016, at 2:15 PM, Samuel Clay notifications@github.com wrote:

how does one end push link so you don't have to redo it each time the app starts

You have to save the username you get back from a successful push link bridge authentication. You can then use that username in your requests' urls.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PhilipsHue/PhilipsHueSDK-iOS-OSX/issues/39#issuecomment-263668644, or mute the thread https://github.com/notifications/unsubscribe-auth/AB9AQHEeYlKSDMlvbvKffP910a8IAi_tks5rDHnMgaJpZM4BW6LU.