Lumberjack is not optional

[ethansinjin]

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]

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]

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

[lightbow]

Yeah, CocoaPods would be great.

[lightbow]

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]

:+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]

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

[heyigor]

+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]

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]

Amen.

[audiocommander]

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!)