Housekeeping

This is actually the second post I have written this week.  I had intended on writing on a completely different topic this week, but after spending some time on it, I realized that it wasn't ready.  Maybe next week.

So this week I thought I would go over a few projects I have been working on.  Sorry, no code this week.

AngularJS - A few weeks ago I decide my next JavaScript framework to learn would be AngularJS.  So I spent some time gathering training resources and began my research into that topic this week.  It turns out it's not as daunting as I had expected.  I'm just in the infancy of my learning here but the concepts are comparable to other JavaScript frameworks I have worked with.

I guess, in my mind, I had put AngularJS up on a pedestal and I thought some great inspiration and productivity increase would come from spending time with it.  But to be honest I am having trouble finding the motivation since it looks so similar to other frameworks I have worked with.

Why I am I learning a JavaScript framework when, up till now, I have mostly talked about iOS development? The reality is, at my day job, I am currently responsible for a JavaScript based UI, so it is imperative that I keep my skill set in that area up to date.

The test app I am building to learn AngularJS is Bootstrap based.  Does anyone know of a good widget UI like jQueryUI is for jQuery?

View Playgrounds - I had on my training list a task to learn how to create and work with iOS views in a playground. I was specifically interested in designing custom views and poking around at the various nuances of UITableView.  I even walked through a tutorial on doing view animations in a playground and figured I could use that as a springboard into the areas I was most interested in.

I chose to look at UITableView first and I went as far as creating a playground that presented one.  From there I ran out of steam.  I'm not sure what I want to do with it now.  It's a lot easier to build a table view in a storyboard in a project than in code in a playground.  Yes, I'm I know I can pull a storyboard or a nib into a playground and use it there, but its unclear to me how that would result in the rapid prototyping that I want to do. Anyone ran across a good tutorial using UITableView in a playground?

Pain Logger New Features - I had a couple of requests for new features to my existing app, Pain Logger.  Essentially it was adding a new setting and adding CSV export for its internal data.  This app is built in Objective-C and, after working with Swift for the past few months, it felt awkward going back to Objective-C.  I made lots of typos but I got through it.

Upgrade XCode - I downloaded and installed the latest version of XCode 7, beta 4.  I decided that from now on I am only going to program in Swift 2 and above, so that meant I needed to convert my CloudKit test app to Swift 2.0.  I thought I could use XCode's conversion utility and it would go seamless.

I even reviewed all the changes that were going to be made prior to accepting them.  But it didn't work so well.  After the conversion, I ended up with 29 different errors from the ones I thought the conversion tool was going to do.

It seemed to make the changes it said it was going to make but because of these changes the new errors were then introduced. Most of the errors revolved around difficulties with callbacks that originally accepted optional NSError objects but now needed them to be explicitly unwrapped. Have others ran into these types of issues? Is it expected?

New App Progress - I made progress on my new app by adding CloudKit support to it.  This was a major milestone as before I was persisting nothing, and I was struggling with how the data should be stored locally before concentrating on cloud storage.

I made a strategic decision to invert that thinking by by-passing the local store cache and concentrating on the cloud storage first.  This turned out to be a really good idea. Now I can store my app's data in the cloud and I will be able to move forward.  I am a little nervous that I might have trouble when I get back to the local cache issue but for now any progress is better than nothing.

Meanwhile, I also read a compelling blog post by Soroush Khanlou titled "Cache Me If You Can" which pursued the idea that a lot of apps are using CoreData for local caching when they really don't need to.

I was leaning that way myself, but after reading Sorush's post I am even more compelled to believe my app won't use CoreData at all.  I think this will reduce the complexity of the persistence layer tremendously and allow me to make much needed progress.

It occurs to me now thinking about this, if you are already dealing with a REST api based web service, then if you interact with your local cache in the same way and assume the cloud store is always the source of ultimate truth then your API for both local and remote stores should look and act very similar and the complexity of the consuming app should be reduced.  I'll be interested in trying this concept out over the next several weeks.

Finally, after working on the updates to Pain Logger, I'm convinced that all my iOS projects from here on out will be strictly Swift based.  I'm even thinking I'll convert my existing apps to Swift as I add support for iOS 9.  Yes, that will be a huge undertaking.  But when I reach that goal I should have a good bit of reusable code between my two existing apps and the one I am working on now.

I think I'll stop here this week.  I hope to have something a little more interesting to talk about next week.  As always if you have any comments, suggestions or questions please don't hesitate to let me know.