I’ve spent the last few weeks in the “basement” of my house developing my next project – Slync app. While the process was very interesting and challenging at the same time, it is always worth it. I should probably write about that experience in my next post.
During that time, I started diving into Core Data in greater detail. Specifically, keeping local store and the remote database in sync (which can be a bit tricky).
Let me start by saying that Core Data evolved greatly over the past few years. This year, at WWDC Apple engineers talked about great improvements to the Core Data and iCloud integration worth learning about (WWDC videos) and some other great improvements. Nevertheless, the whole boilerplate code to insert objects into the store or fetching them from the store into the memory is still a bit tedious. This makes me think of an episode from Friends where Joey took part in commercials advertising milk cartons openers. “There’s got to be a better way…” – he said after spilling milk by trying so to open a milk carton. That’s exactly what I thought when I started integrating Core Data into my project.
Continue reading “Thoughts on MagicalRecord Wrapper Library for CoreData”
CLLocationManager is a tricky business. It is easy to implement if you have only one controller interested in getting users location. It gets a bit trickier when users location needs to be shared between multiple controllers. One way of tackling this problem is to create an instance of the CLLocationManager in your AppDelegate and then share it between interested view controllers. This approach works OK, but at times can be hard to maintain.
There is a better way to accomplish this in my opinion. This approach takes advantage of singleton pattern. As you can see below, it is very simple to implement. It also offers 2 advantages:
- Less code.
- It’s much clearer where the instance is coming from which makes it so much easier to manage.
Continue reading “CLLocationManager Singleton”
Recently I had to write a simple app that read XML file located on the server and populate my model with information. As you probably know, on iOS parsing can be done using two kinds of parsers, a DOM parser or a SAX parser. A SAX parser is a sequential parser and returns data on a callback using a delegate. SAX parser works by giving you data as it becomes available (after downloading everything).
The advantage of using a DOM parser is its capability to access at random using XPath queries. There is also no delegation like in SAX model. It makes the code cleaner and easier to read. DOM parser is slower than SAX, but only if the size of the document is larger than 1 megabyte.
While you can use iOS SDK library for parsing XML, there are 3rd party libraries that make XML parsing easier. One of those libraries is GDataXML.
Continue reading “ARC Compliant GDataXML Library”