feature - extend console to inside ios app

[johndpope-karhoo]

see this example -
https://github.com/burczyk/UIForLumberjack

[emaloney]

This would be a useful extension utility to have. Will definitely consider this for future inclusion.

[johndpope]

nice nice. if you're on a feature branch and need some feedback let me know.

[emaloney]

As of now, I'm building this as a stand-alone project, although the release of Xcode 8 is keeping me very busy right now. Will keep you posted.

[johndpope-karhoo]

let me know if I can help.

[emaloney]

The original implementation I started building has based on being able to read the Apple System Log. Now that the ASL is deprecated, I threw that away and restarted using a new concept. I've got it somewhat working locally on a branch, and will publish that branch in coming weeks to allow you to test & provide feedback. Stay tuned!

[emaloney]

There is work-in-progress available for testing, evaluation & feedback on the live-log-viewer branch.

[johndpope]

Thanks for update.

I switched to use Dotzu in last couple of days - https://github.com/remirobert/Dotzu
It has an onboard logger. Perhaps you could team up.
There's also https://github.com/zixun/GodEye but not stable enough for me.

[emaloney]

Thanks for the tip, John. Good luck, and let me know if I can be of help in the future.

[johndpope]

fyi - also came to my attention this morning - https://github.com/Cosmo/TinyConsole

[cfilipov]

FWIW I've been using a fairly stable log viewer implementation on my fork. It fixes a few issues I had with the upstream live-log-viewer branch and handles chatty logs fairly well (getting table views to animate smoothly with frequent updates is a pain). Looks like there have been updates to the live-log-viewer branch since I forked but that implementation is still sharing the buffer array from the recorder instance which leads to a race condition causing a UITableView assert.

I offered to help out and solicited feedback on what changes would be needed to make this PR-worthy but haven't heard back from @emaloney.

[emaloney]

Hi Cristian,

I haven't forgotten about you; it's just that I have to fit this work within the context of my larger workload, which can sometimes cause me to step away from things for a while.

Anyway, as you noticed, I have updated the branch since you forked, and I would love to include your fixes. The only reason I haven't fixed that myself is that you said you've already done it and were kind enough to offer those fixes back.

The changes I pushed to the branch since you forked are based largely on your feedback, so I hope you give it a try. Don't be shy about giving me more feedback!

Thanks,
E.

[emaloney]

@cfilipov it was implied, but may not have been clear in my minutes-ago post, that I will be happy to consider a pull request from you if you wouldn't mind basing it on the latest version of the live-log-viewer branch.

Frankly, the version you forked was only on GitHub so I'd have a copy of it somewhere other than my laptop. I wasn't really expecting anyone to find it, much less give it a spin & then fork it!

[cfilipov]

Completely understood. I didn't mean to imply you were ignoring my messages. I felt like I was spamming you a bit so I backed off for a while, the notifications from this thread reminded me to bring it up again. I most definitely don't want to maintain a fork if at all possible.

One concern I had with my changes was the number of areas I diverged from upstream. I feel like I had good justification for each of them but without knowing the original intent it's hard to say. It would be nice to have sign-off on some of these areas before I plunge in:

1. I didn't understand the need for supporting reverse chronological in BufferedLogRecorder. It just makes the logic for indexing into the buffer much more complicated for no apparent gain. Removing that functionality greatly simplified numerous aspects of the viewer implementation. It seems this recorder is mainly for use with the log viewer, so if there is a need for this functionality outside the log viewer I would suggest having a non-reversible recorder specifically for the log viewer to keep logic very simple.
2. Putting logic, data source property, recorder etc.. into a fat UIView (LiveLogInspectorView).
   • This resulted in doing some non-standard stuff like relying on didMoveToWindow to do things that would have been more appropriately done as part of a view controller's lifecycle.
   • Lots of code to setup and handle the header view and buttons. Using the system navigation bar and toolbar resulted in much less code and makes it easier to customize (I admit I have a thing for using system controls whenever possible, making it look as vanilla-ios as possible).
   • I removed LiveLogInspectorView completely. Instead, LiveLogInspectorViewController is just a nav controller that sets up a vanilla UITableViewController, adds some bar button items and sets an instance of LiveLogInspectorDataSource as the data source.
     • The majority of LiveLogInspectorViewController is generated by paint code to draw an icon so users of the library won't have to deal with adding assets manually.
     • To go even further with the dependency injection theme, there is really no reason to actually subclass UINavigationController for LiveLogInspectorViewController, you could just have a function that takes takes a withNavigation: Bool arg and builds a UITableViewController with all the necessary bar button items and stuff.
     • If someone wants to customize the log viewer they can add their own bar button items or remove the default ones.
     • The log viewer data source is useful on its own, you can just attach that to your own custom tableview.
     • Why would anyone want/need to use the data source directly?
       • One example: when I start a new app or when I'm writing a quick and dirty app to test/isolate something specific, my root view controller is a UITableViewController whose data source is the live log data source. I have various controls in a toolbar/nav bar for what I'm testing ( and I don't need/want the filter/sort buttons).

I'm mainly trying to avoid getting into a situation where I spend a lot of time preparing a PR only to find out that our directions are strongly incompatible. Ideally, I would like to get you a PR that makes you happy, but still allows me to configure the live log viewer to suite my needs (specific preference for what is displayed, the colors etc..). I think it's possible, your latest changes are much closer to what I have than before.

Frankly, the version you forked was only on GitHub so I'd have a copy of it somewhere other than my laptop. I wasn't really expecting anyone to find it, much less give it a spin & then fork it!

I didn't expect to yak-shave, but I looked at lots of logger implementations, really liked this one, and I really needed a log viewer asap.

[emaloney]

Cristian,

I'll address each point in turn:

1. I didn't understand the need for supporting reverse chronological in BufferedLogRecorder.

I would be fine with simplifying this implementation.

2. Putting logic, data source property, recorder etc.. into a fat UIView (LiveLogInspectorView).

I don't mind splitting up LiveLogInspectorView further, but we have a use case where it is useful to be able to use the view itself without needing the view controller. This was the rationale for putting some of the things often found in a view controller implementation (table delegate and data source, for example) into the view itself.

• Lots of code to setup and handle the header view and buttons. Using the system navigation bar and toolbar resulted in much less code and makes it easier to customize (I admit I have a thing for using system controls whenever possible, making it look as vanilla-ios as possible).

Using a standard UIToolbar for these controls is fine with me. However, I'm not sure I want to require the view controller to be contained in a UINavigationController in order to have the controls placed onscreen. I would still like to be able to handle the use-case where the view itself is placed onscreen without being in a view controller and still be able to use the controls.

Perhaps this is an argument for creating "building block" views that would allow you to just what you want/need, for example:

• A "simple log view" just contains the table with the log content, nothing else
• A "control view" can be associated with a "simple log view" and displays the controls. Each control should be able to be individually hidden/shown
• An "advanced log view" which wraps the "simple log view" and "control view" in a single entity, so a user can place that view in the hierarchy somewhere and have a full-on console with controls

• I removed LiveLogInspectorView completely. Instead, LiveLogInspectorViewController is just a nav controller that sets up a vanilla UITableViewController, adds some bar button items and sets an instance of LiveLogInspectorDataSource as the data source.

Splitting out the data source into a public entity of some sort is OK with me. The rationale you expressed later in your write-up makes sense to me.

As mentioned above, I'd like to retain the ability to use a single view without the view controller. I'd also like the ability to use the view controller with full controls without requiring that it be contained in a navigation controller. (At the same time, if it is put in a navigation controller and is presented modally, that it should provide some sort of dismissal button; eg., "Close").

• The majority of LiveLogInspectorViewController is generated by paint code to draw an icon so users of the library won't have to deal with adding assets manually.

I don't have a problem with that, although because the assets are contained in a Framework, users of CleanroomLogger shouldn't need to manually add assets to their projects; it should happen automatically by virtue of relying on the Framework mechanism.

• To go even further with the dependency injection theme, there is really no reason to actually subclass UINavigationController for LiveLogInspectorViewController, you could just have a function that takes takes a withNavigation: Bool arg and builds a UITableViewController with all the necessary bar button items and stuff.

Having some sort of utility function to return the log view controller wrapped in a navigation controller is acceptable to me.

• One example: when I start a new app or when I'm writing a quick and dirty app to test/isolate something specific, my root view controller is a UITableViewController whose data source is the live log data source.

This reminds me, one of the things I'm planning for including is a container UIViewController that can be used as the rootViewController where the container would have a log pane that can be hidden/collapsed while the "main pane" shows the content of the application. This would allow you to pop open the console pane anywhere are you're developing/debugging.