Please shed some light onto my ignorance of iOS development
December 19, 2013 5:57 AM Subscribe
I'm beginning development of first iOS app and I aim to know as much as I can about what I don't know about app development.
What're the dark arts, emerging soon-to-be-status-quo methods, lesser known best practices, etc. of iOS development? I'm particularly interested in BaaS (backend as a service) or similar. I'd rather deal with APIs than with implementing something myself. Any other tips/thoughts/musings/anecdotes would be fanstastic. Thanks, Jennifer
What're the dark arts, emerging soon-to-be-status-quo methods, lesser known best practices, etc. of iOS development? I'm particularly interested in BaaS (backend as a service) or similar. I'd rather deal with APIs than with implementing something myself. Any other tips/thoughts/musings/anecdotes would be fanstastic. Thanks, Jennifer
You don't need to use REST libraries or http wrappers. It turns out NSURLConnection works well and is way easier to debug than problems with libraries or frameworks.
posted by ignignokt at 8:24 AM on December 19, 2013
posted by ignignokt at 8:24 AM on December 19, 2013
Response by poster: To calibrate responses, what are your current knowledge levels in programming and app development in general?
My knowledge of anything low level is pretty much nonexistent. I don't know anything about Objective-C etc. I have a pretty good grasp of how everything fits together on. My goal is not to be caught of guard when a programmer comes to me with a question or to make preventable mistakes in designing the app.
posted by j3nn1f3r at 11:54 AM on December 19, 2013
My knowledge of anything low level is pretty much nonexistent. I don't know anything about Objective-C etc. I have a pretty good grasp of how everything fits together on. My goal is not to be caught of guard when a programmer comes to me with a question or to make preventable mistakes in designing the app.
posted by j3nn1f3r at 11:54 AM on December 19, 2013
Best answer: Aside from Objective-C and choice of specific APIs, which is an implementation-specific matter that will depend on what your application will do, you might step back and read about a few common software design patterns which come up over and over again in object-oriented OS X and iOS application code. These include the singleton, delegate and MVC patterns.
You should familiarize yourself with these three patterns, at least, before thinking about your application and how you organize data and connect application logic with the user interface.
The singleton pattern is used for the application controller — there is one controller, and it does a lot of the work of getting the application up and running. This pattern is also used in other contexts, for example, where you want to keep application state or other parameters in one place, and one (and only one) instance of a class to provide access to them.
The delegate pattern is used a lot with UI components. Let's say you embed a table view into a view controller, for example. Instead of setting up the table view directly with code for drawing the table view with specific data, you set the view controller as the table view's delegate or manager — you are instructing the view controller to manage table view settings, like how many rows are drawn for this or that section, or what header text to use for another section. In other words, the table view delegates responsibility for its settings to the view controller that contains it. This pattern of delegation comes up everywhere in iOS application development and you should get familiar with implementing it. Doing a sample table view app is a good way to learn this.
The MVC or model-view-controller pattern divides up responsibilities for classes that manage changes to application data (the "model"), drawing the user interface and handling user events (the "view") and classes that mediate changes to the model when the view changes (a user drags a slider widget, so the application's data state needs updating) and vice versa (some application data are pulled in from a web service, so the UI needs updating to show the data, like presenting a table view, etc.).
If you know those three patterns, IMO you'll know enough about iOS development to be about 90% along the way to designing your application. The remaining 10% is picking the right native and/or third-party APIs and doing the actual coding.
As for APIs with web services, a couple useful frameworks to learn about are Core Data and RestKit. Apple's Core Data is a way to manage your application's data that has a bit of a learning curve, but is very powerful. Third-party kits like RestKit aim to make integrating Core Data with web services a bit easier for new developers. You can roll your own with NSURLConnection, and you should probably use it to learn the basics of asynchronous requests and data handling, but if you're going to make a larger application, these kinds of kits are useful to look at down the road.
posted by Blazecock Pileon at 12:33 PM on December 19, 2013 [3 favorites]
You should familiarize yourself with these three patterns, at least, before thinking about your application and how you organize data and connect application logic with the user interface.
The singleton pattern is used for the application controller — there is one controller, and it does a lot of the work of getting the application up and running. This pattern is also used in other contexts, for example, where you want to keep application state or other parameters in one place, and one (and only one) instance of a class to provide access to them.
The delegate pattern is used a lot with UI components. Let's say you embed a table view into a view controller, for example. Instead of setting up the table view directly with code for drawing the table view with specific data, you set the view controller as the table view's delegate or manager — you are instructing the view controller to manage table view settings, like how many rows are drawn for this or that section, or what header text to use for another section. In other words, the table view delegates responsibility for its settings to the view controller that contains it. This pattern of delegation comes up everywhere in iOS application development and you should get familiar with implementing it. Doing a sample table view app is a good way to learn this.
The MVC or model-view-controller pattern divides up responsibilities for classes that manage changes to application data (the "model"), drawing the user interface and handling user events (the "view") and classes that mediate changes to the model when the view changes (a user drags a slider widget, so the application's data state needs updating) and vice versa (some application data are pulled in from a web service, so the UI needs updating to show the data, like presenting a table view, etc.).
If you know those three patterns, IMO you'll know enough about iOS development to be about 90% along the way to designing your application. The remaining 10% is picking the right native and/or third-party APIs and doing the actual coding.
As for APIs with web services, a couple useful frameworks to learn about are Core Data and RestKit. Apple's Core Data is a way to manage your application's data that has a bit of a learning curve, but is very powerful. Third-party kits like RestKit aim to make integrating Core Data with web services a bit easier for new developers. You can roll your own with NSURLConnection, and you should probably use it to learn the basics of asynchronous requests and data handling, but if you're going to make a larger application, these kinds of kits are useful to look at down the road.
posted by Blazecock Pileon at 12:33 PM on December 19, 2013 [3 favorites]
Best answer: From where you stand, I think you'd benefit more by going through these tutorials and getting a sense of how iOS development works and feels than by reading about any specific tips or gotchas right now.
Once you've put together a few trivial but working iOS apps, that's a better time to start evaluating specific APIs, third-party services, and frameworks.
When you do, though, please be careful about using abstractions you don't understand. If you look through the source and don't get what's going on, you're probably going to get burned by it later once your app gets sufficiently complex, even though you might benefit from "free" functionality early on.
posted by ignignokt at 1:43 PM on December 19, 2013 [2 favorites]
Once you've put together a few trivial but working iOS apps, that's a better time to start evaluating specific APIs, third-party services, and frameworks.
When you do, though, please be careful about using abstractions you don't understand. If you look through the source and don't get what's going on, you're probably going to get burned by it later once your app gets sufficiently complex, even though you might benefit from "free" functionality early on.
posted by ignignokt at 1:43 PM on December 19, 2013 [2 favorites]
The suggestions above are great ones. I'd add to the list that you should also at least get acquainted with the concepts of object-oriented programming. Objective C is just that: C with parts to allow OOP bolted on top of it, so understanding what a class is (also, inheritance), what instantiating an instance of the class does, and how those instances communicate with each other will give you a much better idea of what your code is actually doing. Apple has this doc, though it assumes a bit of C experience, so I'm sure there are better places to start from. Like ignignokt said, being able to read your source and understand it is crucial, especially when you start encountering behavior that isn't what you intended.
Down the line, learning more about C and how it manages memory (pointers!) may help, but that's the next level from where you are now.
posted by The Michael The at 7:22 PM on December 19, 2013
Down the line, learning more about C and how it manages memory (pointers!) may help, but that's the next level from where you are now.
posted by The Michael The at 7:22 PM on December 19, 2013
This thread is closed to new comments.
posted by The Michael The at 6:06 AM on December 19, 2013