There were a couple of glitches in the code I had originally posted in “iPad: resize view to account for keyboard” especially when dealing with a scroll view within a split-view controller, etc.
Originally, I was using the “setContentOffset” method on the UIScrollView:
This was problematic depending on the orientation and so forth. Frankly, I could never get it to behave the way I wanted. After much debugging I looked at some other methods and found: scrollRectToVisible. Well … that sounds like just what I need and no longer have to worry about calculating the perfect position for the scroll point. Here was the updated line:
[scrollView scrollRectToVisible:activeField.frame animated:YES];
There. Much better! See the original post for the rest of the tutorial.
[SNLog Project Page Link]
A simple task that every developer runs into when creating software is proper logging and tracing. What I have found is the simplest solution for logging is always the best.
Requirements are almost always the same:
- Need to log to the console when debugging
- Need to write to a file/database for runtime tracing and diagnostics
There are lots of frameworks for just about every platform out there but logging on the iPhone seemed to be lacking so I decided to create my own as an exercise. Something that would be applicable to my current projects as well as to help out anyone else that might need something like this.
NSLog is the de-facto standard for logging during debugging in Xcode but is primarily temporary scaffolding in your code that needs removed prior to deploying the application. I wanted something as simple to use as NSLog that could be configured to log somewhere more persistent than the console.
The plan of attack on this was straightforward:
- Minimize the files that need included in the project (just two, the .h and .m)
- Make use of it as easy as NSLog
- Re-define NSLog to use the framework instead of the built-in function
- Use a strategy pattern to allow multiple logging mechanisms (console and file built-in)
In addition, I ran into the following additions while I was working on it:
- Don’t let the file logging grow unbounded (especially on a mobile device)
- Capturing the log level/importance can allow different mechanisms to capture the level that is required
So that’s it … in two simple files I was able to create a simple logging mechanism that is a drop-in replacement for NSLog. I can keep all those frivolous NSLog statements in my code and choose where to redirect the log.
Check out the Project Page for more details and the download.
For as many times as I have set up BizTalk you would think I have seen it all. But the sad truth is that I run into a unique problem each and every time.
This time, I had some initial issues getting even the SSO up-and-running but I had forgotten some of the basics (disabling shared memory, etc.). Then I had some spelling mistakes in the group names (sloppy on my part) and then I forgot to add myself to one of the groups (again, sloppy). Finally, I had most of these housekeeping items taken care of and then get the SSO up.
Next, when I tried to set up the Group feature I kept getting a “logon failed” for the BizTalkRuleEngineDB. But … there was no BizTalkRuleEngineDb … and I was a sysadmin on SQL. WTF?!?
Well … as it turns out the very first time I had attempted to configure BizTalk the Rules Engine configuration had actually succeeded. However, I went in and deleted the existing databases when I was trying to get the SSO up-an-running. BizTalk thought there should have been a rules engine database and was failing trying to “log in” to it.
To fix it, I unconfigured the Rules Engine feature and everything went smoothly going forward. Would have been nice to get a “database ain’t there” error message!