A software journeyman, Saul thrives on creating well crafted code on his continuous quest to become a Master Developer. Saul is an active member of the Cocoa developer community and contributes by blogging, producing NSBrief, a Cocoa developer podcast, contributing to open source projects, and helping to teach others about the wonders and methods of developing applications. Saul’s software development business, Magical Panda Software, seeks to create well crafted and productive applications for the Mac and iOS platforms. Saul is also an avid cyclist and has recently relocated to Denver.
Core Data is not an ORM. Core Data is NOT a Database, and Core Data is NOT easy. However, Core Data is highly flexible. Core Data is an Object Graph. Core Data is the swiss army knife of data persistence. It can be used in simple straight forward applications, or in highly complex scenarios. Core Data can also adjust dynamically to the needs of your application. In this session, we’ll cover some of more advanced uses and functionality Core Data provides such as importing data, threading, migrations, and creating custom persistant stores as well as things you may want to avoid in your own Core Data Adventures.
During the lifecycle of building an app, a developer will always sense that an app is "slow", or that it's using too much CPU, or network or more importantly in mobile devices, battery power. You may have also heard about issues like memory leaks. Instruments is a tool provided by Apple as part of their normal developer SDK, and is ideal for identifying these problem areas. Instruments helps to identify problem areas in your applications that you may not expect are problems by using tools to measure various aspects of your code while it's running. We'll go through some real work examples of how we've used instruments in our development cycle to find memory leaks, memory hogs, and other general performance issues. We'll also use Instruments to fine tune other aspects of our sample application such as the screen rendering time, improving table view performance, and improving fetches from and saves to a Core Data store.
Using as much common code as possible on a project is a goal for many developers, and it's especially true when you're developing for all platforms: Mac, iPhone and iPad. We'll go over some simple strategies to make your cross platform projects as simple and easy to manage as possible. Also, stick around for the surprise twist at the end!
Data is the heart of many of your apps. In general, your app needs to create it, view it, change it and delete it often. There are many ways to store, retrieve and manipulate data in Cocoa ranging from the NSCoding protocol to XML formatted PList files. While those are useful, there will be a time in your app where you want to move your data to the next level. In Cocoa, that is Core Data. We'll go over each piece of the Core Data "Stack", and how to use them in your apps. We'll also discuss the MagicalRecord library and how it help minimize the amount of code you need to write to get Core Data into your app.
Compilers don't care how readable code is, as long as it doesn't have a syntax problem, the compiler will handle code just fine. However, as developers, it's in our best interest to keep our code clean and readable. And all it takes a little bit of practice. We'll go over a few common places where code gets messy, and some techniques to keep these places clean.
Do you remember all those times when you wanted to swizzle your methods with these classic tunes?
How can we for get thes terrific melodies:
Hi, I'm Saul Mora, and you might know me from my previous appearances at CocoaConf, NSConf or 360idev and other popular conferences. In the next 45 minutes I'm going to re-introduce you to all the runtime fun for developers young and old, from noob to neck beards.
Building a quality iOS or Mac app takes a lot of time. And in these crazy days of mobile development, time is money. So, rather than debate on how to resolve an old problem, why not choose from an off the shelf solution that gets you at least half walk closer to your own custom solution. This is where design patterns nine. And, in Cocoa, we're surrounded by these patterns. Once you know where to look, you'll see them everywhere. Let's explore the design patterns available to you in Cocoa, and how you can take advantage of them in your apps to write less code with fewer crashes and more awesomeness
iOS applications are getting more and more complicated. They just do more. How can we as developers keep up with this break-neck pace and still keep our application manageable? That’s where application architecture comes in. We’ll go over some of the application design and architecture practices that I’ve found make for easy to understand application architectures and code.
Every new app you build is a chance to learn. To tinker with ideas and ways to make app building better and easier. I’ve been building a few apps recently with various features and goals. I’ll take you through a brief overview of some of the real life code that goes into my applications to show a number of good ideas I’ve found work for me to make my apps less buggy, and can work for you also. And yes, we’ll be talking about Objective C in this talk only because Swift isn’t completely ready for full time development.
Change is the only constant in the universe. When it comes to making iOS and mobile apps, change happens annually. This year, we’ve been given a bigger plate of change than usual from Apple. What does this change mean for developers now? What will it mean for developers in the future? Is this enough change, or too much?
Functional programming is finally a first class citizen in the Cocoa toolset! But, Swift is not necessarily a pure functional language. And in embracing the functional paradigm, do we need to throw out our knowledge and experience with Object Oriented programming? It turns out we can have our cake and eat it too!
The kids these days really like the Swift. Youngins don't see the point of headers, and messages and semicolons. But effectively Swifting isn't as easy as transposing your dad's Objective C code to the new hawtness. Let's go through some examples and see what effective swift might look like.
In an effort to promote some audience participation, I'd like to request your code samples to see how they might look in Swift. Send your Objective C or Swift code snippets you're uneasy about to email@example.com.
Building apps with third party or open source code is a fact of life in the software engineering industry. But despite the common practice and long history of building and reusing libraries, dependency management is still a big pain for iOS and OS X development. Our options are limited and have long term consequences to choosing them. Well go over some brief history of dependency management on other platforms as well as the state of dependency management for Xcode based projects. In addition to a shortened background, we'll open the floor for a forum to discuss the some possible solutions to improving the state of dependency management for our Xcode built apps.