While at Empirical Development and then MartianCraft I had been distanced from all of the inventive solutions that other development teams have been coming up with for the past few years. I was living in a bubble of our development teams.
Now that I am working independently again, I am being exposed to a large number of interesting code bases.
It came as quite a surprise to me that view controllers are considered bad by many developers and that they have been coming up with some rather intersting solutions to make them more “manageable”.
To me, this is an indication that many developers have lost the perspective on what should and what should not be in a view controller. For some reason there is a misconception going around that everything belongs in the view controller.
Lets break it down.
It is time to move on to the next chapter.
What is Next?
Long term I have some ideas that will take a bit of time to put into place. In the short time I am eager to help as many teams as possible through short term contracting, consulting and workshops. I really do enjoy helping teams get the most out of their persistence and networking layers.
Effective immediately, I am available for short term and possibly long term contract work.
While I can assist with any form of iOS or OS X development, my area of expertise is in networking and persistence; specifically Core Data.
If you are not familiar with my experience, here are a few highlights:
- Wrote “The Book” on Core Data.
- Taught at universities around the United States
- Spoken at nearly every Apple related tech conference around the world
- Provided workshops on persistence, Core Data and Networking at many conferences and large corporations in and around the United States.
- Developed some of the most complex applications ever conceived for the iOS platform
What are the options?
I am looking for short term projects unless it is truly amazing, cutting edge, and never done before. I am looking to help your team provide a better experience for your users.
We can accomplish this either through a monthly, weekly, daily contract or through a workshop. The details of which we can discuss in detail. I am available to travel and can work on site for short periods of time.
Are you struggling with your persistence or networking layer?
Are you having performance issues that you are unable to isolate?
Would you like a fresh set of eyes on your project to get an idea of where things are?
Contact me; we can discuss the options.
Late last year I was contacted by the organizers of MCE Conf and was asked to speak. Since it fit within my schedule (which can be its own challenge these days) I accepted without thinking too much about it.
Shortly after my acceptance I had heard that there was some controversy surrounding the conference about a comment made by one of the organizers who had attended another conference. After reading up on the controversy I figured; “oh well, how bad can it be?”
The short answer? It was amazing. I absolutely loved every minute of the conference.
Whenever Apple releases a new version of Xcode one of the first things that I do is look at the default templates and see if there are any new or interesting things.
This year, with the release of Swift, there are some pretty radical changes. Yet the Core Data stack initialization code is still the same.
There is nothing wrong with the default template code but there isn’t really anything right about it either. It is far better than it once was but it is still overly verbose and hard to follow.
Therefore, I present my Swift Core Data stack code that I will be using as I grok this language.
I very rarely speak out against another blog post. I find the resulting argument back and forth draining. However, there are exceptions and one occurred over the weekend.
Brent Simmons has been blogging about his conversion of Vesper to a Core Data application. A recent post of his titled Core Data and Deleting Objects set my teeth on edge. Brent says:
“The best advice I’ve heard about deleting managed objects is to 1) not do it, or 2) do it only at startup, before any references to those to-be-deleted objects can be made.”
I do not know who is giving Brent advice but he must be playing tricks with him or just trying to wind him up. The advice was simple; don’t delete Core Data objects or if you are going to delete them, delete them at launch.
Will that work? Sure. Is it the right answer? Not even close.
Core Data has a number of features and abilities that are not commonly used. Chief among those are fetched properties. In discussing them with a number of developers, most have never heard of them and those who have heard of them couldn’t come up with a viable use case for them.
To be honest, I don’t have a lot of use cases for them myself. They are definitely not one of the core features of Core Data that I recommend people learning when they are initially getting comfortable with the framework.
In this article we will discuss one use case for fetched properties and the impacts.
## The Use Case
The use case for fetched properties that I have run across a few times comes into play when you have more than one persistent store file on disk. Imagine you are building a recipe application (one of my favorite examples). You decide to include a pre-built read-only database with existing recipes. However, your application has the ability to add notes and social comments to a recipe.
You want to keep the recipe database as read only (you have a separate one for new recipes) but you want the user to be able to add comments. Where do we put the data?
In this contrived situation, storing the comments (and other metadata) in another store makes sense. Unfortunately we can’t have relationships across physically separate stores.
Enter the Fetched Property.
## Fetched Property
A fetched property is a property added to a
NSManagedObject entity that instead of storing a value or a relationship, it stores a
NSFetchRequest. When the property is accessed for the first time the
NSFetchRequest is fired and the results are returned.
A fetched property always returns a
NSArray (well a subclass but that is a minor detail) and it can be configured to sort the results.
Unfortunately, the editor in Xcode does not permit adding sort criteria so the only way to add a sort to a fetched property is to create the fetched property in code. Hopefully that will be corrected in some future release of Xcode.
What does a fetched property look like? In the Core Data model editor, a fetched property is added just like an attribute or a relationship. Then in the Data Model inspector you can configure the
The Destination is the entity that will be returned by the fetched property. The predicate is a string representation of the
NSPredicate configured within the
Further, the predicate can use one of two variables to help configure it:
$FETCH_SOURCE gets replaced by a reference to the entity that owns the fetched property. By using this variable we can reference properties in the owning entity.
$FETCHED_PROPERTY gets replaced by a reference to the the property description of the fetched property. The property description includes key value pairs that are accessible from within the predicate. I have not run across a situation where I have used this variable.
## The sharp edges
There are unfortunately some concerns with fetched properties.
Unlike a relationship, there is no way to pre-fetch a fetched property. Therefore, if you are going to fetch a large number of entities and then desire to access the fetched property for those properties, they are going to be fetched individually. This will drastically impact performance.
Fetched Properties are only fetched once per context without a reset. This means that if you add other objects that would qualify for the fetched property after the property has been fetched then they won’t be included if you call the fetched property again. To *reset* the fetched property requires a call to
A fetched property always returns an array. While this is not a major issue if in fact you want more than one object returned. However, when that is not the case it is an additional method call that you need to make every time or add a convenience method. More code equals more bugs.
## To use or not to use
Fetched properties are not a main line piece of Core Data. It appears that even the Core Data team (or the Xcode team at least) agrees with that assessment based on how little effort is given to them in the model editor. Should you use them?
It depends. If you are joining two separate persistent stores and need a *soft* relationship between entities in those stores then yes, you can use them. They do work.
Be mindful of the edges, they are sharp.
Recently on [StackOverflow](http://stackoverflow.com) I have seen several questions regarding the desire for a parent Entity to be updated whenever an attribute within the child has changed.
There are several different ways to solve this problem. The easiest is to have the child ping the parent whenever it changes and then the parent can update any values it needs to as a result of that ping.
*Note: This is a re-print from the Mac Developer Network.*
One of the nice things about developing software for OS X is all the “freebies” we get out of Cocoa. For example, when we are building a UI with text input we get undo support for free! How cool is that?
Likewise, when we are working with Core Data, it also has undo support built right in. Every
NSManagedObjectContext has a NSUndoManager that we can use. However there are some situations where the default undo support is insufficient.
In this article we are going to walk through one such situation.
*Note: This is a re-print from the Mac Developer Network.*
I tend to frequent the StackOverflow website and watch for questions about Core Data. Generally if it is a question I can answer I will and if it is a question I can’t answer then I really dig in for a fun session of exploration and attempt to find the answer.
When: November 2-4, 2011
Where: Los Angeles, CA
[Schedule and Additional Information](http://www.mactech.com/conference/about)
The speaker line up for MacTech this year is amazing. I am quite honored to be sharing the stage with such a group of people.
## What is MacTech Conference? ##
MacTech Conference is a 3-day, immersive, technical conference specifically designed for Apple developers, IT Pros, and Enterprise. “The whole idea of MacTech Conference is to allow members of the Apple community to meet and exchange ideas,” said Edward Marczak, Conference Chair and Executive Editor of MacTech Magazine. “This will be spurred on by presentations from some of the best and well-known experts in the community.”
MacTech Conference will have two separate tracks: one focused on programming / development, and the other on IT/Enterprise. Sessions will focus on both desktop and mobile, with appropriate levels of attention paid to the Mac, iPhone, iPad and iPod.
When: September 11-14, 2011
Where: Denver, Colorado
[Schedule and Additional Information](http://360idev.com/)
I am very pleased to announce that I will be speaking at this year’s 360 iDev conference in Denver, Colorado. Previously it was a foregone conclusion that I would be attending this conference since it was so close to my home. However, now that I am living in California, that is no longer the case.
However, I am happy to say that I will be attending this year despite a change in my home address. The speaker line up at 360 iDev keeps getting better each year and I am happy to be a part of this [great lineup](http://360idev.com/speakers).
If you are on the fence about going to this conference then please take my advice; GO.
Not only is the speaker line up great but Denver has a great walking downtown and the after session events should be just as entertaining as the speakers themselves.
I look forward to seeing you there.
When: September 5-7, 2011
Where: Brighton, UK
[Schedule and Additional Information](http://updateconf.com/)
I am very pleased to announce that I will be speaking in Brighton at the Update conference starting on September 5, 2011. The Update conference is a bit different than the normal “developer” conference that I attend and speak at. Instead of just or primarily focusing on the developer; a great deal of focus is put upon the user and the user experience. If you have been in attendance for any of Aral Balkan’s talks then you know very well what his focus is.
In addition to speaking at the conference I will be giving **two** one day workshops on Core Data. The first workshop will be an introduction to Core Data. I hesitate to call this a beginner workshop because *you*, the attendees, will be directing the workshop. If everyone wants to start at step one then we will. However throughout the day you will be setting the pace of what we learn and discuss. This format has worked very well in the past and the last time we did a workshop like this the day ended with some pretty advanced discussions.
The second session is labelled advanced and will be starting off with the assuming that we all know and understand the principals behind Core Data. In this session we will deep dive into some of the more complex areas of Core Data. Again, I have a list of topics but you, the attendees, drive the session. Therefore it is intentionally open ended so that you can come with your questions and problems and we can discuss them together. I plan on wrapping up the second workshop with some real world examples of edge cases and situations I have run into and how they were solved.
I invite you to join me in Brighton this September to attend Update 2011. I expect it to be a great time.
This is a post that has been sitting in the back of my mind for many months now. I originally conceived of writing this back in February of 2011 but decided that the time was not right for it and waited. Had I written it back then I suspect the text would have been quite a bit different.
I was part of the original development team that wrote “The Daily” for News Corp.
When “The Daily” was released, we expected some issues with it. Every developer should expect issues with a 1.0 release. We knew that it was written under a tight deadline and that there were most certainly sharp edges that we had not identified. The application was about as well received as we could expect from the user base. Some people do not like Rupert Murdoch. Some people do not like his teams slant on the news. That was expected. He is good at polarizing his readership.
The response we got from the developer community was a complete surprise.
## Back In The Day ##
One of the things that originally attracted me to being a Mac/Cocoa developer was the community. I remember, fondly, watching two direct competitors sitting across a table from one another trading code solutions. Both knew that the other person was going to add it to their code base and they shared that information anyway. Both developers knew that it was the other developer that was driving them to make a better product. There can be no first place without a second place. Having a close competitor helps drive us forward.
Likewise, going to a CocoaHeads meeting you would see senior developers, developers who have been doing this for decades, sitting next to developers who are just now wrapping their heads around retain/release. They weren’t pained but instead looking upon the younger developer with the fondness of remembering what it was like when they started. Perhaps a bit of envy of all the exciting things this new young developer is about to learn.
## Introducing The iPhone ##
When the iPhone was introduced we were all very excited to start working with it. Cocoa on a mobile platform! We could not wait to get our hands on it. The community embraced it immediately.
At first you had to hack your phone to write code for it but we quickly got an SDK. The community consumed that SDK with a hunger. The forums were active, the boards were active, the blogs were hot. Everyone wanted to share the new cool thing they learned or share the pain they just went through so that, hopefully, no one else had to go through that pain. The community was alive and prosperous.
I do remember many conversations about what would happen to the community with this sudden influx of developers. Many conversations started over what to do about these developers invading our platform. When I was involved in those discussions my response was always the same; we would welcome them to the community and teach them how we work. We would show them how great it is over here and that we share our toys. We would welcome them knowing that they would become part of us; not the other way around.
For the most part that is what happened. A large portion of these developers joined us. They shared; many new blogs started up, new books were written and our NSCoder nights and CocoaHeads meetings grew. The community became stronger with this influx of new developers.
## A Disturbing Trend ##
More recently, perhaps within the last year, there has been a disturbing trend in the community. Surprisingly, sadly, this trend has not come from the new developers but from some of the older grey beards. There has been a trend to “piss on” things written by other developers. A new app comes out, good or bad, and the claws come out. People are quick to blast it; the more press it gets, the more it gets blasted.
A new photo sharing idea that got a lot of VC money? *Blast it!*
A new game concept? *Kill it!*
An old idea rehashed in a new way? *Destroy it! Burn them!*
He got more press than me? *He must die in a fire!*
I would almost expect this from new developers who just joined the community. However it is not the new members of this community that are all aflame. Most likely they are looking at these ideas and seeing how they can apply them or if there is anything to learn from them.
Sadly though, it is the older, established, members of the community that are turning so hostile. Gone is the sharing and the live/let live attitude that once made this community so great. Quite a few members are just full of piss and vinegar.
You can say what you want about me. I do not hold myself above others and know that my code sucks more often than not. I tend to share that opinion of my code often. I do not share what I have learned to gain glory but to just enjoy the act of sharing. Sharing makes me feel good.
What saddens me is this new desire to attack things that are either new or just in the media. Does the application suck? Maybe. But to curse the developers who wrote it? Not cool.
We as developer must remember that we are **not** the target for 99% of the software that is written. We are not the final judge on what will or will not work. If anything, we are the last people that should have an opinion on what is good or bad. We should be the ones that step back and watch what the “normals” do with it. **They** determine the success or failure; not *us*.
## Some Thoughts From The Trenches ##
Not everyone who reads this blog is an independent developer. Not everyone who reads this blog writes code to fit someone else’s goals so I would like to share a few points from someone who is an independent developer and writes code to meet the expectations from others.
### Deadlines are a bitch ###
Rarely do I have the opportunity to set my own deadlines. Companies who hire development shops almost always have a deadline in mind before the first line of code is ever written. More often than not, they have a deadline in mind before they have all of the requirements defined.
We, as developers, do not get to move those deadlines without massive and dire consequences. Usually our only opportunity to move them is at the beginning and then by saying “No, Thank You” to the project. Moving a deadline mid project usually has financial consequences.
### Non-Developers Think This Is Easy ###
Non-developers see that one new feature as trivial. They see that crash as obvious and do not understand what the hell is taking so long. Business people are non-developers. The people who sign checks are business people.
To go along with my point about deadlines, getting paid involves meeting the requirements of the project within the deadline. These are almost always at odds with each other. The requirements are far greater than can be fit within the deadline. The response from the business team is “add more people, make it happen”. We as developers know that adding more people will actually slow things down.
### The First 90% Is Easy ###
Developers frequently look at a problem and in their first blush say “oh I see how that works, that is *simple*”. That is a trap my friends. Everything looks easy at first. My favorite recent example is the carousel of The Daily. It is trivial right? No, there are a huge number of dependencies and features and bells and whistle and edge cases that all work their way into that piece of the application. The core of moving images around on the screen is trivial. Anyone can do it in a couple of hours. However to complete all of the requirements? Months of work. Personally I am still not completely happy with it. Maybe with 6 more months of polish it will get to where I would like to see it.
Never underestimate the requirements that go into a piece of functionality. Don’t assume that the developers are incompetent if it doesn’t work or perform the way you expect it to. Chances are that there are requirements that you as a user are unaware of.
### Software Development Is Not The Only Cost ###
This is my one hostile point in this post. Whoever thought the iOS developers got paid $30 Million on “The Daily” is a moron.
“The Daily” is a **lot** bigger than just writing iOS code. There is a huge editorial staff, there is a server team, there is office space, hardware, travel, the list goes on and on. The actual iOS code was a small fraction of the huge effort that was put into creating a digital only daily newspaper; the first of its kind by the way.
### Doing Something First Sucks ###
Unless you are trying to get into some record book, the person who does something first is rarely remembered. He who does it best is often remembered fondly. When you are the first to do something you rarely are the best at it. This is just a simple fact of life. When you are the first to do something you are making shit up as you go along. You are guessing. You have no clue what is going to happen when you release. The first MP3 player? Shit. First Tablet? Horrible.
Being first means that you are going to be superseded. Either by improving on your design or by being replaced by another team that took your idea and ran with it. The iPod blew away the first MP3 player. The iPad blew away the first Tablet. I look forward to seeing who becomes the greatest digital only daily newspaper on a tablet. Maybe that will be The Daily via iteration or maybe it will be someone else.
## Conclusion ##
“Be excellent to each other” — Bill & Ted’s Excellent Adventure
This should be the guiding principal of the Cocoa Developer Community in my not-so-humble opinion. It is one of the things that make it great. New people are welcomed and the older members are honored.
There is no reason to hate other development efforts. It does not matter if that developer is better or worse than you. It does not matter what that developer wrote. There is plenty of room for all of us.
Be excited by his or her success. His or her spotlight does not put you in darkness.
I look forward to seeing each of you next week in San Francisco. If you see me please feel free to say hi.
WWDC is once again upon us; be excellent to each other.
This is a short introductory article to welcome a new application to Zarra Studios.
We are involved in a lot of contract work and frequently our clients will give us video files. These files can be demos, mock ups, advertisements, etc.
As a developer on the move, I like to keep these with me and on my iPad so that I can review them whenever I want.
Of course, Client A does not want Client B to be able to accidentally see their files. Lawsuits happen that way.
To make this even more fun, everyone wants to borrow your iPad. Everyone wants to touch it and play with it. This increases the risk of the videos getting into the wrong hands.
From this, SecurVid was born.
## Features ##
SecurVid is designed to put videos behind a password lock. The videos are kept encrypted on disk and are not backed up to your computer that you sync your iPad with. This means that it is not designed to be a storage system for your videos but a protection for videos you need access to but don’t want everyone who borrows your iPad to see.
SecurVid has a lossy way to reset its password in case you forget it. Enter the wrong password three times and it will offer to reset for you. However that reset comes at a price; it will first delete all of your videos before offering to reset the password.
Once you are into SecurVid you can watch the videos you have already loaded naturally. You can also add more videos via iTunes as well as from any other application that is configured with file sharing. Therefore if a client emails you a video you can tap and press on the video file in mail on your iPad and load it into SecurVid.
Likewise you can export videos from SecurVid either for emailing or for loading into another application. You can even mark a video as “unprotected” and allow iTunes to see it next time you plug in your iPad.
## The Future ##
This is the 1.0 release of SecurVid and has the core features that I/we needed in the application. However it is just the beginning for this application. As the application matures we will be adding additional features and continuing to release updates.
## Cost ##
Because the 1.0 has only the core set of features we are offering it at an introductory price of $4.99. That price will remain until the next set of features are added. When that occurs we will increase the price up to the next appropriate level. However if you bought the 1.0 you will get these upgrades for free.
**This article is reprinted from the MDN**
The documentation on Core Data for the iPhone has lead to some confusion about how best to use Core Data on a Cocoa Touch device. One particular section seems to be the most confusing, specifically:
> A view controller typically shouldn’t retrieve the context from a global object such as the application delegate. This tends to make the application architecture rigid. Neither should a view controller typically create a context for its own use. This may mean that operations performed using the controller’s context aren’t registered with other contexts, so different view controllers will have different perspectives on the data.
> When you create a view controller, you pass it a context. You pass an existing context, or (in a situation where you want the new controller to manage a discrete set of edits) a new context that you create for it. It’s typically the responsibility of the application delegate to create a context to pass to the first view controller that’s displayed.
The idea behind this section is the issue of rigidity. Ideally, each view controller should be an island on its own. It should not rely on its parent, nor should it rely on the Application Delegate. Once a view controller is pushed onto the screen it should ideally be its own master.
## Why Rigidity is bad
It is fairly common when designing a Cocoa Touch application to “hard code” everything. Take the following navigation controller design:
![Navigation Controller Design](http://www.cimgf.com/wp-content/uploads/2011/01/Image1.png “Standard Navigation Controller Design”)
When this design, it is common to code each view controller and make it “aware” of its parent. In that design, it would be common to see view controller B call methods or call back (to its delegate) view controller A. While there is nothing technically wrong with this design, it is very rigid. It is nearly impossible to either move view controller B to another location in the stack or to reuse view controller B somewhere else. This is the trap that the documentation is trying to help new developers avoid.
## Solution One
Again using a standard/normal navigation controller design, it is expected that the detail flows from left to right. The left most (or root) view controller contains the most vague information and the right most (or deepest) view controller contains the greatest detail.
In this case then the best solution is to use a
UIFetchedResultsController. This controller can be considered a thin layer between the view controllers and the Core Data bits. The advantage is that the
UIFetchedResultsController is designed to work with tables. The other advantage is that your least detailed view (the root most likely) can listen as the delegate of the
UIFetchedResultsController for changes and update itself.
In this design, however, instead of passing around a context, you would hand off just the entity that the child view controller needs to know about. The Core Data Recipes example provided by Apple illustrates this design quite well.
How does this break rigidity? Each view controller, from the root on down, only knows what is passed into it. The root gets the
UIFetchedResultsController passed into it. The child views only get the items it cares about passed into it. None of them care what their parent view controller is. There is no call back to a parent.
## Solution two
What happens when we don’t have a typical navigation controller design? Perhaps a child view can pop up a modal view that displays different information. Perhaps a child view, for whatever reason needs to access information that cannot be directly passed into it every time.
In these cases there are a few different options.
### View already has a
Following our example above, lets say that view controller C needs to create a new object. Perhaps it is a detail view of a recipe and the user wants to add a new recipe type (perhaps she is a vegan and just discovered there is no vegan type in the list). In this case we have passed in an entity (the recipe) but not a reference to the
NSManagedObjectContext. Fortunately this solution is easy to fix. The
NSManagedObject retains a reference to its
NSManagedObjectContext internally and we can access it. Therefore we can easily retrieve the
NSManagedObjectContext from the
NSManagedObject and create the new Type entity and pass it to the modal child or whatever our design calls for.
This again avoids rigidity because the view controller that represents the entity does not need to call up to a parent object or the
UIApplication delegate. It is self contained and only manages view controllers that are down stream from it.
### View does not have a
In this situation things are *slightly* more complicated. In this case we want to create a
@property for the
NSManagedObjectContext and require that our creator set the property.
@interface MyViewController : ViewController
@property (nonatomic, retain) NSManagedObjectContext *moc;
Again, the view controller is an island of its own because it does not care where that
NSManagedObjectContext came from. All it knows is that it is required for the view to function. It does not care of it is a new
NSManagedObjectContext specifically created for its use (perhaps for a cancelable edit tree) or if it is the same
NSManagedObjectContext that has been passed around since the launch of the application. All it knows is that it has the elements it needs to perform its function.
By making the
NSManagedObjectContext a settable property we can also transplant the view easily. If, at some point in the project lifecycle, we decide that it makes more sense to have the following design:
![Modal View Controller](http://www.cimgf.com/wp-content/uploads/2011/01/Image3.png “Modal View Controller”)
Taking from Apple’s Recipes Application, perhaps we decide that moving from the table view directly to the image of the recipe is more pleasing to the users and that when they want to see how to make it they can “flip” the image over and see the detail.
Making this change with each view controller being an island is quite simple. We just rearrange the views without having to worry too much about breaking the application.
## Solution three
Up until now we have been looking at just a navigation controller design. But what about tab bars? In the situation of a tab bar we again want to avoid rigidity because it is even more common that tabs will get moved around.
The solution to this is to again use a
@property for the
NSManagedObjectContext and require that the creator set this property before the view is displayed on screen. If you are creating the tabs in code this is trivial because you are already calling init on the view controller and you can add one more line of code after the init to set the property.
If the user interface is being developed mostly in Interface Builder it is slightly more tricky. Personally I am not a fan of creating navigation controllers or tab bar controllers in Interface Builder. However if that is the design then I would recommend referencing the view controllers as properties and passing along the context upon initialization of the application. It may be possible to do this entirely in Interface Builder but I am not comfortable enough to recommend that as a solution.
The overall idea behind this article is to keep each view controller separate from anything up stream or in a different silo. This will make the design far more flexible in the long run. Any time that you feel the “need” to pass in a parent view controller to a child view controller, reconsider the design. Consider using a
@protocol delegate design or NSNotification calls instead. Keep each view controller as its own private island.