Add os_log support on iOS 10+
ateliercw opened this issue · 7 comments
Hey just want to have an open discussion about emoji logging, seems like the right space.
So i think they should be color coordinated rather than image coordinated. I vote we go towards something that is a little more coordinated towards color.
Currently:
1.) Hearts:
💔 = error 💛 = warn 💙 = info 💚 = debug 💜 = verbose
2.) Random colored emojis:
❗️ = error
3.) Something else I can't think of.
Also we might want to add custom formatting option. Currently there is a line break which is difficult to read if you want to see where something is different. I'd suggest having a format string in there that has a "default" and the developer can override to their needs.
Just a thought and I can add these as issues if it seems more appropriate there.
The other question along these lines is: should we just have a preferred logging library / configuration rather than trying to get all of the details right rolling or own?
Totally valid concern and I'd be willing to concede to that if there is one that isn't too bloated. Cocoalumberjack did too much and I was really not liking it by the end because it didn't use stdout and seemed like a large dependency.
But if you have some options in mind for what we could use that isn't too large i'd be totally down to check them out.
This looks most similar to ours and has all the bells and whistles. I might pull it in and try it out
https://github.com/delba/Log
That logger looks really good @dostrander -- there are a few others out there but they all seem overly complex. It would be nice if Log was a bit more configurable though. In particular, it's nice to be able to integrate loggers with InstaBug, os_log, and a rolling file logger (implemented externally to the Log package). I think a small change to Log could implement this, but I'm not sure how receptive they'll be to it.
@KingOfBrian I'd open up a PR and see what they say. If it's just adding a closure somewhere i don't see them being too off put by it
I scanned through it, and I think if the Log object held [(Formatter, (String) -> Void)] instead of just 1 formatter and a direct print call, it would open things up considerably. The tuple might want to get upgraded to a struct, but it should be isolated to initialization and one method.