search

PhilipsHue / PhilipsHueSDK-iOS-OSX

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

Lumberjack is not optional #40

Open ethansinjin opened 10 years ago

ethansinjin commented 10 years ago

Currently, versions of your SDK > 1.0 use Cocoa Lumberjack for logging. While this may be useful within your department, developers not employed by Philips do not get much use out of this, because your framework is closed source.

Please either make Cocoa Lumberjack an optional dependency (preferred), or provide options to disable the console output.

Just a clarification: I'm working on a Cydia tweak, and Lumberjack cannot be included. For others, this may simply be a minor annoyance.

jhvdb87 commented 10 years ago

We will consider to make Lubmerjack optional. The logging is useful for debugging, since it shows all requests (and responses) to the bridge. Logging can easily be disabled with the enableLogging method in the PHHueSDK class.

steffex commented 10 years ago

@jhvdb87 perhaps use cocoapods to add lumberjack instead of using a hard copy.

lightbow commented 10 years ago

Yeah, CocoaPods would be great.

lightbow commented 10 years ago

At the very least, please update to a more modern lumberjack. You are using 1.1, and with 2.0 out soon, it will complicate projects that have dependencies on the new one if the Philips SDK is still using the old one. https://github.com/CocoaLumberjack/CocoaLumberjack

williampower commented 10 years ago

:+1: on CocoaPods to add CocoaLumberjack. https://github.com/PhilipsHue/PhilipsHueSDK-iOS-OSX/pull/76/files

:+1: on optional CocoaLumberjack. Maybe you can engineer a solution that allows opt-in?

lightbow commented 9 years ago

I feel like this is going to grow into a bigger problem with the introduction of tvOS.

heyigor commented 8 years ago

+1 on this, please provide a way to NOT use CocoaLumberjack. CocoaLumberjack is fine, but its pretty heavy and the HUE library requires linking with it. Please provide a way to optionally use it.

ethansinjin commented 8 years ago

Just checking in, over two years after posting this issue. This has still not been addressed. I have built multiple iOS lighting apps since 2014 and have only supported Hue bridges through third-party API wrappers, in large part due to this issue.

As a longtime Hue owner and developer (since 2013!), this is extremely frustrating.

lightbow commented 8 years ago

Amen.

audiocommander commented 7 years ago

Hi there, just wanted to add my +1: Regarding the fact that there are now over 30 compilation warnings, mainly deprecation markings in the Lumberjack files, I can only second that it is a weird choice to have this logging framework as required sources. Additionally, this adds an overhead for Swift-only projects (adding a bridging header and Obj-C compiler settings). I think I might rather go with a third-party swift framework (although I obviously appreciate this project and its openness!)