Christian Peters

I began my app with a super simple view for the user's history. I used 1 huge label and just threw text at it. It didn't look pretty, but it got the data on to the screen. As I have been working with the app on a daily basis, it has become obvious to me that this is the biggest issue that needs to get addressed for the app to look more professional. Replacing this current view with something else will allow me to learn about the UITableViewController in iOS. As with everything I have learned so far, I seem to immediately expect iOS to have a similar control and functionality to .NET. I think that has probably done me a disservice by assuming something new will be similar to something I already know. Most of what I have learned to this point share aspects of what I know, but are almost never exact matches. UITableView I expected would likely work like either a listview or a repeater, and it has some similarities, but it also has some quirks that I find odd. At least based on t...

Coming back to my project with a failing test worked great. I was able to immediately run my tests, see which one was failing and then figure out where to go from there. So I figured out my date issues and now have that logic working as I want. Next up is to test out the functionality in the app. Running through the app I found some more issues here and there. Another good reminder that while Unit Tests will help prevent bugs and regressions, there is still a need for manual testing as well. If it makes sense to add more Unit Tests as you find issues from your manual tests, then add those in as well. I was able to fix up the issues I found from manual testing and moved on to getting the app on my actual phone. This ended up being pretty easy and straight forward. I needed to get a certificate from Apple to sign my app, but Xcode took care of most of that and I was able to publish the app to my phone pretty easy. I have my own little ToDo list that I have been working through and ...

Now that I have some basic UI elements working and some Data Objects defined and those Data Objects are persisted to a Database. Its time to start working on some logic, and before we do any logic, we want to have Tests in place. Red of the Red, Green, Refactor mantra. I want to keep track of every entry made throughout a day, and then when the day changes over, consolidate all of the previous day's records into 1 history record so that the user will be able to see how they have progressed over time. Date logic is always fun, so I am really glad to be starting out with a Test rather than assuming that my date comparisons will work as I expect them. In .NET you denote a Test Method by giving it an Attribute, and then treating it like any other method. Here in Xcode, you denote a Test Method, but having the method's name start with lowercase test, and then you add the test name after it. I've grown accustomed to naming my Test Methods very verbosely and descriptively to mak...

So I started trying to find a way to save data in my app. I have been watching this PluralSight course to help me along,  Core Data Fundamentals , by Brice Wilson. Having thoughts of EF Code first in my head I thought things were going to be fairly straight forward after setting up my Model objects and then a connection to the data store. However, after getting those pieces setup the course shows some simple object creation and data retrieval. This ended up being nothing like I expected. Every call to and from the data store used strings to find objects and set or get properties. Yikes! I envisioned defining an object and then being able to use intellisense for that object and all of its properties. There is more to the course so hopefully we will get to that point, but if that is the case, this seems like an awful way to introduce using Core Data. Continuing on with the course I find that the reason my original objects do not provide any intellisense is that they are NSManagedOb...