I started writing a custom control for iOS since about a week ago. The initial idea was that it’s going to be part of a bigger application that I will be working on and it’s going to be a versatile and reusable component that could potentially save countless number of hours for other developers as well.
I decided to write it from scratch because there aren’t quite anything out there could do the job, although the task it serves is quite a common one: select multiple items from a long list – a generic selector/picker control. I found this, this and this, however they are rather outdated and written for a specific purpose of selecting people (phone or email).
So as I was writing it, it gets more and more complicated with several configuration options that I need in my project. That’s why it also became clearer and clearer to me that there is a need for such generic UI control. I can already imagine it being used in many app ideas that I have in my mind.
Closer to completion, I am very certain that I’m going to sell this component for a small fee, at least compensate for the time I’ve spent. Plus I’ve already written a commercial component that is doing not too badly.
The last bits of the package was the documentation, licensing and pricing. As I did some research to pick the correct license and some calculations to get the pricing, it suddenly struck me that the process of developing custom controls has instilled an idea: to commercialize every UI components that I will develop. Not a good way to think about iOS development.
Fast forward to an hour later, I found myself rewriting the About page and pushing the code to a public Github repo. So damn it, I’ll just opensource and just let people take the code, improve it and probably pay whatever amount they think it deserves.
Here is the component and here’s the commit if you are curious. Check it out let me know what you think in the comment below. Would it have been a good-selling component if I were to sell? How much would you pay then?
For the past few weeks, I have been checking out a website called Binpress. Which is the commercial alternative to CocoaControls. The site is still new but it already has several components in it and not limited to just iOS stuff. They still have a lot of kinks in the publishing process, however, I find that the quality of components here are slightly better than those in CocoaControls, perhaps because the authors spent more time to polish up a paid package. However, I have to say this only applies to Obj-C components, the other languages are still behind CodeCanyon. Their commission is fixed at 30% though, much better than CodeCanyon which takes frickin 50%-70% of the sales!!!
So I also decided to try writing a commercial component that could be huge time-saver for iOS beginners. Given that there are a lot of companies in which the web developers now have to take up iOS programming to serve the changing need, I can see that there are a lot of developers struggling with getting a quick ready-to-use application template to start with. A template which they can just open up and instantly have Facebook connect and WYSIWYG welcome pages.
For a beginner, it is a daunting task having to know how to build and import libraries needed. With this application you don’t have to worry about those and just get your app running right away. This application is meant to help you get started your iPhone app quickly with Facebook login handling built right in and more importantly having an onboarding/welcome UI that you can modify easily with Interface Builder.
This post is a guest post written for Inspired Magazine on the same topic of understanding user experience.
What is UX?
UX stands for User eXperience. A little more comprehensive would be: the entire interaction that starts even before your user uses your product until long after.
I don’t remember when I began to hear the term UX, but definitely not when Windows eXPerience was introduced. I’m pretty sure all the hype about having great UX just started within the last two years. Before that, everything I knew about making websites emphasized mostly on good UI. But now, it’s simply not enough. What ever you do, it has to have great UX.
What I think UX really is
To me, every little details make up the entire experience and not just what you see. Putting that into a website/app context it would mean tons of things: how your users got to know about your site? is it easy to download your app or get to your site? is it a simple series of actions to start using your service? do you have a way to guide and help the user in the beginning? are your buttons at where the users expect it should be? do the buttons have the glow effect when you touch them? What if their network has problem, how do you tell them? How many clicks before they would get to do what they want to do? What if the user need to contact you? do you have support service? etc… the list is endless.
UX is about the entire experience, UX is about satisfying the needs of your users, make them feel comfortable using your service. While UI is simply the visuals.
I recently attended a seminar by Ben Hamey from Bonono and in his slides, the exact words are “User experience is anthropology, psychology, usability, research, behaviour, graphic design”. I couldn’t agree more.
UX ≠ UI
Great UI does not mean great UX
Bad UI does not mean bad UX
The full-flash hotel sites or wedding planner sites are usually designed by actual artists, and that’s why they are very cachy, interesting. But what puts me off most of the time is the slow loading time, frequent crashes and because the navigations are so unconventional that I don’t even know where to click to get information. It’s easier to give up and find another site than to spend time figuring out.
On the other hand, sites like Craiglists, HackerNews have very poor text-based UI, but they have excellent UX because they do exactly what the users expect them to do, fast!.
Craiglist is simply a place to find and sell used things, as long as I can post my old TV or buy a used bike, I’m happy with it. I don’t care if it is a pure text action link or a fancy button. I just want to get over it quickly.
Some might strongly disagree with me that a site with bad UI can’t have great UX. Well, a few millions users per day couldn’t be wrong. People just love getting things done easily and quickly. You might want to do that in style, but it’s just you, not the other millions.
When I first got my iPhone 3G, it was simply wow at first sight of the UI. However, only until a few months later I started to realize the passion to make great software and stop making crappy websites. There wasn’t much resources on the Internet about UX back then and even I didn’t quite fully understand the term itself like I defined in this post.
So I tried and failed, at the beginning it was mostly the desire to create nice UI, but that wasn’t enough, there was always something missing in the works I’ve created. I was too focused on a single page at a time and didn’t see the big picture. I downloaded tons of apps on the phone. Some good, and a lot of bad apps. I started to pay attentions to extremely small details on the screen.
Then one day, I spent 15 minutes just to examine transition of the header when “Back” button is pressed and that’s when everything kicked in. I started to see that it’s not about any single element of the design or the whole design, it’s about how things are connected together and those tiny invisible links matter more than the entire UI.
From that day, whenever I hear about a new app, I search for it, look at the website, then the copywriting and design/navigation of the website, then download the app, try to make it fail, try to stop the registration process half way and resume, try to break the best case scenarios or closing the app while it’s doing some heavy processing, etc… I began to spot a very distinct pattern between a great app and a normal or bad app. The best apps handle all those disruptions extremely well and I can always pick up from whatever I did (wrong).
The truth is that it takes a lot of effort to create such a seamless experience and it’s not something developers especially the beginners want to be doing. Implementing great custom UI is hard enough, creating a seamless transition between actions requires solid but flexible architecture.
To sum it up, if you want to learn how to create great UX, begin downloading apps and inspect them with a microscope today!
If you like my stuff, do checkout the iOS custom UI components that I wrote by checking the links on the right side bar. Perhaps that would save you some time when developing your killer app.
For a long time, since beginning of iPhone programming, the modal view has not had any major innovation. A quick search on cocoacontrol for “modal” returns 3 types of modal view:
- Fullscreen cover-up modal view
- Centered-popup type
- Date selector modal
The context problem
Out of the 3 types, the date selector is the only type that keeps the user aware of the current context that he is in (date for which field). By contrast, the other types of modal view practically cover up the entire screen and none or little context is visible. These implementations have been sufficient so far and sometimes the developers just have to include some context within the modal itself by setting the view’s title or include some kind of static labels.
But what if we could do better by adopting the same interaction by the date selector component? What if we need to somehow keep most of the context visible while presenting user with supplementary controls for adjusting behaviors of the context?
The Park Guides app by National Geography
The beautiful Park Guides app (iTunes link) launched just recently in Apr 2012 did an excellent job in solving the context problem.
So instead of the usual fullscreen modal view/popup view/UIActionSheet, the app shows a semi-modal view on top of the current view similar to the date selector component. However, the most interesting feature of this app is the way the current context is kept visible using a nice subtle animation. Instead of simply dim the view in the background like UIActionSheet, the entire view is scale down to about 80% and pushed back like a stack, creating a unique wow effect and at the same time, more of the background view is visible to the user. This is a great new way to interact with iPhone components.
It’s best to view the effect in a video clip here (1.3MB, .mov)
When it works, when it wouldn’t
Arguably this fancy implementation may not work in all cases. If you have a long Settings modal view in your app, it is not suitable. Or if you have a modal screen with text input, it wouldn’t work at all.
Nevertheless in many of the use cases it will be excellent addition to your app. Say for example you have a long Settings screen and different Tabs in your app, you might want to consider breaking down all the settings into different places where they are being used there and then.
Another use case showed in Park Guides app is providing extra content to the current view with a modal image (2nd screenshot above), adding more context while facilitate information-hiding.
In an attempt to learn CATranforms3D for the first time and replicate the same experience, I’ve created a custom Category add-on for UIViewController that makes presenting such a custom view easy.
UIViewController+KNSemiModal is an effort to make a replica of semi-modal view with pushed-back stacked animation found in the beautiful Park Guides by National Geographic app. You can see this original semi-modal view below.
The pictures don’t really describe enough the cool factor of the implementation. You can download a short video I recorded to see the effect : demo video (1.3MB, .mov)
Why I do this?
Please read my discussion in a separate blog post. I highlighted some issues with the current implementations of the modal view and how I think it can be better
This library (ARC) is designed as a Category to UIViewController so you don’t have to subclass and you can simply drop in any project and it will just work!
Copy 2 category files UIViewController+KNSemiModal to your project and add this import line at the top of your current ViewController file
You can prepare your UIView * myView with all the controls and subviews that you need before presenting it with
Another convenient method is presenting a separate ViewController class by calling
I started using Apple products since 2007, when I started college. I used all my savings to order a custom 15″ Macbook Pro mid 2007 model with glossy screen (back then it was default to matte). And I then adopted iPhone trend beginning with iPhone 3G. Before that I had been a long time Windows user, starting all the way from 3.1 til XP. On the mobile side, I tried all kinds of smartphones including S40,S60,WM6.0,WM6.5,WinCE, even Linux phone.
For a very long time before the Mac and iPhone, I have never had the feeling of “this is it” for any laptop or phone that I owned. But once I embraced Apple product, it just felt right. And I always find it’s hard to explain or convince someone with simply “just right” reasoning.
A few weeks ago, I came across a post on Engadget and that really helped me to put all the pieces together and explain this phenomenon. The video in the article shows a vast difference in the user experience between a 100ms and 1ms lag time. That sparked everything else in my mind for this post.
Windows vs Mac OSX, the keys
Coming from a long history with Windows, I was very surprised to see how fast OSX was. Not in term of very demanding task but in term of extremely simple and common daily tasks such as opening a folder, file, copy, moving stuff around the screen. My very first impression was that the interface never freezes on Mac. Compare that with the infamous ‘cloned dialogs‘ bug on Windows.
So I did a bit of research, trying to understand why. Turned out the problem is much deeper than I thought: Fundamentally, Windows is meant to run on as many combinations of hardware as possible, while Mac was only meant for Apple hardware. I’m not an OS-engineer but my guess is that the number of abstraction layers in Windows has to be a lot more than in Mac. Because of that the overhead is a lot more for simple tasks like user input. And so that could have lead to more processing cycles.
Until today, having to switch daily between Win and Mac on the same machine running SSD, I still feel the lags of immediate responses in Windows UI. I’m a power user, doing stuff mainly with shortcuts and seldom with mouse. Many of the times the OS couldn’t keep up with quick window switching, key presses and sometimes typing ‘stucked’ for a few seconds and then the letters just spit out all at once. It doesn’t mean these don’t happen in OSX, they do, but much less frequent and the ‘freezes’ are much shorter. That brings me to the next point.
I do think that this is extremely important because on Windows, I always have that feeling “what I typed did not seem to be registered” and makes the whole OS seems to be unreliable although it is not. However, on OSX, I don’t have this same feeling of uncertainty, instead, I have a great feeling that no matter how fast I typed or used the shortcuts, they are always executed correctly. This is partly why I always felt ‘just right’ working on Mac.
iOS vs Android, the touches
iOS was built with all the principles of OSX and back in 2007 when the original iPhone was launch it created such a long-lasting wow impression for any one coming in touch with it. While Android was introduced not really long after but the initial impression was not as successful.
There are many reasons to that but personally I would love to credit that success to how responsive the UI on the device was compare to others at its time. As I mentioned, I was early adopter for many mobile platforms and the common (bad) trait of all of them was the huge delay of the interface, from the time you touch the screen to the time something happens.
Despite being a now-dead-slow device, the original iPhone has two extremely important features that are still very fast compare to today’s standards: touch response and responsive scrolling. The device immediately shows something, either a change of color or a glow effect when you touch the screen; and continuous dragging on the screen maintains the same pixel position relative to the finger. Both of these were poorly implemented in other mobile platforms and I would say in the early Android 1.x platforms as well.
That’s why I think Apple nailed it and started the mobile device revolution that are easy to use and great to the touch.
My UX principle: show something, anything
Among many UX principles that I derived from years of using Apple products, there is one that is directly related to this post and it’s not very hard to do: Show something, anything!
What that means is for any user interaction event, on web or mobile or desktop app, you need to show a change in interface. Anything. As long as it gives the instant feedback to the user that their action has been acknowledged and the system is processing the request.
This is even more essential in mobile app or handling network requests because they are always slow. Changing button color, showing an animated indicator, faking partial result list, … are all interface tricks that gives the impression of a fast application.
In one of my applications (Denso), I did use a lot of these tweaks to make the app feels a lot more snappier. Being an internet app, it has to make many network requests to different servers, no matter how fast the device could get, network latency is always a tough issue to handle.
Windows 8 could be something
I’m not bias against Windows or any OSes, I’m just stating my observations as a power user.
In fact, the Microsoft prototype video above was very impressive, not only that, just a day before this post, another Microsoft video became trending : Microsoft explains why Windows 8 touchscreens will be better. It is definitely a great showcase and I think Microsoft, with Windows 8 coming soon, is getting somewhere this time.
Also, Windows Phone 7 is a big step up for Microsoft’s mobile platform. I was very impressed with the responses of UI on the Lumia 800. I have not been using WP device extensively but I think finally MS got it right to the touches.
The big question: How much does an iPhone app cost?
This is a very common question that I’m asked by a lot of my business-oriented friends and non-tech savvy clients. Without fail, every single time I gave my initial estimation before even locking down the specs, I received that shocked expression because of the unexpected (high) quotation.
Yet, none of my quotations has even came close to the range being discussed in this StackOverflow thread, in which the development cost of Twitterific app is discussed. Despite the fact that the original question was asked in 2008 and the best answer (by one of the Twitterific developers) was in 2010, it is still accurate today in Jan 2012 and I can foresee that it will still be true atleast until the end of 2012.
So, with the hype of businesses wanting to have an iOS app continues into 2012, I thought it would make a good post trying to explain why the cost is high by breaking down the steps and variables involved. I hope it will benefit both the non-iOS developers and business people who need to make decisions or just want to understand the process. The ideas in this post are not restricted to just iOS, they are also applicable to other mobile platforms (Android, Windows Mobile, maybe Blackberry) to a large extent.
Checklist: Getting ready for the iPhone app
The process is not a simple one and I usually guide/educate the client through all the considerations using the following steps:
FIRST: One of the most shocking discovery I have after speaking to several clients is that they have no idea about the big infrastructure picture needed for an iPhone application. Because of that they always assume iPhone app is only an app, they expect me to quote them the price for making everything possible within an app without regard to issues such as: do they have a supporting server that the iPhone speaks to, where do they store users’ data (I’m using layman terms here). The first time I met such a client I was furious, however, later on I came to a realization that because the client-server network concept has boiled in my blood since I started programming, I took it for granted that everyone knows. But I was wrong, business-type person doesn’t care and they might not have the technical common-sense you expect.
So to non-tech savvy readers: You need to have a server to store your data if you are looking to do an app that has some kind of authentication/login, or some kind of customization that you want to change it yourself at any time, or even involving simplest form of receiving information from the user (again, i’m using very simple language here).
SECOND: Because of the fact that you need a server, you need to have a way for the iPhone to communicate with the server, sending data to and receiving data from this server. There is no standard way, there is no plug-and-play way to do it, everything has to be customized. This is analogous to creating your own set of language: you don’t want others to understand what you are speaking with your server but two ends need to understand one another.
This is called creating a set of API endpoints (or simply APIs) for your application. These APIs must be in existence before you can proceed to make the iPhone app. Why? Because you need to define the language, before you can communicate! That brings me to the next step, how to create these APIs.
THIRD: Do not take this step lightly, APIs should be viewed as important as 50% of the entire solution. Making APIs is almost like making a full website. You need to first define your data models, the business rules, what are the input parameters of your business logics, how do the data models interact with each other when an event happens. To put it very simply, the outcome is a fully functional website but the pages do not show graphical results, they show only text: an example successful authentication page only contains a single word YES.
The iPhone then makes requests to these pre-determined endpoints (login page) with the pre-determined format of inputs (user+password) then interprets the result that these pages return (YES/NO). The app doesn’t magically register and login the user by itself.
There are *a lot* of variables to be considered in this phrase such as how to pick the server, how to select the language that will be written in, where to host your data to minimise communication delays, etc. I won’t get into details because if you don’t know, you should ask your tech-cofounder or let the developer decide.
FOURTH: Either you need to have this set of APIs ready, well documented by your in-house team to give to your iPhone developer or prepare to pay more than just for the iPhone app. Depends on the developer that you engage, he might or might not have the skills needed to do what you need. If he does, I suggest you to let him do both because then he knows exactly what APIs to call and what is needed to be done to make the app works.
In the case that you already have APIs, you should expect to let the iPhone developer speak freely with your back-end team beside giving him the documentations; because most of the time, he will need to request more work (more APIs) to be done to support the mobile application.
Now, the iPhone part
Phew, that’s a lot just to get ready for your iOS app but now you can start thinking about the iPhone app itself. In general, everything about iOS is very restrictive. You almost have to define 100% of the scope and lock in the design before the developer can start to code, unlike making websites, developing an iOS app under contract has extremely little leeway for changes:
Design the interface: Whether you will use all standard interface components or customized components that will have to be decided right from the start. Because the architecture of the entire application itself depends on how you want your interface be, how the users should use the app. An example is the standard Tab Bar at the bottom, if you want colors icons instead of the blueish tint, the change in code is substantial!
Tightly integrated code: With websites, you can simply add one more page, then create a link to that page when you needed. However, you can’t do that with iOS app, everything has to be set in the beginning, any changes might result in significant other changes that you might not be able to understand why. The way iOS codes are structured is like a breadboard, everything is hard-wired, you still can change a few things here and there, but if you change the wrong wire, the whole board might stop working. Even extremely well structured code does not increase the flexibility by a lot. Adding an additional email button to ‘About’ screen might only be worth a few more lines of code, but adding a Facebook Like button on the same page is a different story, don’t expect that to be done in a few hours.
Converting an iPhone app to iPhone/iPad universal app: This is the worst ‘additional feature’ found in iPhone development contracts. Because an iPad app is not a frikin’ additional feature. The iPad app is always more complex than iPhone app, and most of the time requires entirely different interface and interaction mechanism. It’s like making an electric bicycle and then convert it to a fuel-powered motorcyle! They are very similar at what they do, but under the hood, the difference is immense.
Take the popular Facebook app (in 2012) as an example, the iPad and iPhone app look similar yet they are very different, the way in which a user interacts with stories is substantially different.
Not only that – the API requirements could also be different underneath: The Denso app, an app that I worked on (which is why I know), has some features exclusive only to the iPad that require additional data from server. Additionally, the iPhone and iPad have very distinct user experiences.
So are you ready to begin?
I hope after reading this, you can get a sense of what is needed for you or your company to develop a mobile app. Unless you are making an offline app (like a Calculator app!) that does not collect any data from users, you are not going to get the app made on the cheap side. After considering all the variables above, if you can’t justify contracting development, then the only other option is hiring full time developers to work in-house for the entire length of the project.
On the other hand, if you decide to go ahead and outsource, then I have one more thing to say: The red tape. If you work in a large corporation or regulated environment, your job is essential in helping the developer avoid the red tape along the way, maybe bend the rules a little. I have spoken to a few large clients and they were very skeptical when I asked to look at their APIs. Either they were not willing to open up as it would violate their policies, can’t blame them; or they have yet a properly defined policy for external data access; or even as bad as the brand guideline requires the app to have company logo on every single screen(!!!). In the end I didn’t work with those clients because I cannot imagine how long it would drag and how much trouble I will get into when I need to ask for additional API support.
MVC in web programming
I also assume that you know enough about MVC, or atleast understand separation of concerns in code structure. For Rails or CakePHP developers, this concept is already at the back of your mind.
So here’s my own simplified definitions of MVC: Model : Data object classes, entities in your system/app, containing attributes. Eg: BlogPost class Controller : The ‘director’ of Models, tell them how to move around and interact with others. Eg: A class that updates a BlogPost View : The result of the interactions. What you see. Doesn’t really matter if you can’t see. The interaction happened anyway. Eg: A class that displays updated message.
M-VC in iOS apps
In iOS app development, Models are still Models, they are still data objects on their own. What’s different is that View and Controller are usually together, in a single class. The reason is that most of the time, the interaction that modifies your data object (by controller) usually followed by a change in UI *immediately*. An even simpler way to put it is that a single function call has to delete a BlogPost object and remove the table row at the same time.
The difference became much more apparent to me after months of learning how to craft great user experience, especially in the case of handling asynchronous remote data. These are the very essential steps of handling remote network connection:
Start a network connection
Update UI to show ‘waiting’ state
… nothing happens, wait
Connection finishes, parse and store data
Update UI with data
Besides, you also need to consider what to do when connection fails:
Why it failed? Should retry or abort?
Should update UI to show retrying state or show an error message
Can the user re-initiate the connect on UI
There are a lot of steps, the ones in italic are the responsible of a View, while others are handled by Controller.
In web development, you make a request, the Controller decides what to do with Models, then passes result to the View to display the state or changes. It’s not the same in iOS app. The changes to a View happens immediately when properties of Models changed. That is why in iOS app, the ViewController exists. In a broad sense, the lines of codes that should belong to View and the lines of codes that should belong to Controller are intertwine and inseparable.
To put the concept in real life. An application that fetches a number of blog posts from server and display them in a table would likely to have following 4 files
So this post introduced the ViewController way of thinking in iOS app. Take your time to apply the concept, look at some of the examples and try to guess which lines do the job of a View, which lines do the work of a Controller. It will serve as a solid foundation for organising your code.
While this is a good concept to understand. I remember that I did not really bother about it, instead, I wonder why the heck there is (UI)View when there is (UI)ViewController. And then there are stuff created inside a .xib with Interface Builder. As a beginner in a difficult programming language, I’m sure you are more drawn to use IB to create your controls. But then you are left with questions like:
- How to not use .xib?
- How to link a class with .xib you created after, what’s the real connection between them?
- Why some developers are against it, why some use it all the time?
In the next post, I will attempt to introduce the fundamental differences between UIView, UIViewController and how they are related to .xib files, Why Interface Build is good in some case, why it is not in some other.
Thanks for reading. You can now subscribe to my blog via email using the form on the right hand side.
Since I began my iOS beginner blog series, I have been receiving tremendous feedback and appreciation from readers all over the world and lots of encouragement for me to continue with the series.
I started realizing that there are so many more developers out there who are struggling with iOS than I originally thought. So allow me to make my point very clear that this blog series is meant for beginners, sometimes certain statements might not be technically correct, but I intentionally wrote them in a certain way so as to simplify the thought process for new readers. Those ‘mistakes’ will not do any harm, as long as you keep progressing, the more advanced concepts will help you redefine those yourselves. In this post, I will make some of those in the process of explaining the concepts. This post is a highly simplified and short explanation for absolute begineer who have not touched any compiled language before iOS development.
The big question, unanswered
Just like you, I stumbled right at the first step of understanding iOS source code. With no background in compiled languages, I can’t really tell what are the purposes of different files. Java programmer would have no problem understanding all the declarations like @interface, @protocol, @implementation. (Don’t worry, my next post will talk about these in more details). PHP programmers, well, everything ends with .php
Unfortunately, the question “What are .h and .m files?” that I seeked is too fundamental that seasoned developers don’t really bother answering. I found some really short answers for this question here and here but they didn’t really help me much.
There are many many more questions like this along my journey of learning iOS. Until now I’m still puzzled why there aren’t many people that could help guiding beginners in the transition from web languages to compiled Objective-C language like this. StackOverflow is an excellent repository of even weirdest questions, but there ain’t many basic concepts explained well. Having to gone through the pain, now I am hoping to demystify some of these concepts for the absolute noobs like I was.
So what are .h and .m files?
.h file is header file, .m file contains the implementation
Each class in Objective C, usually made up by one .h file and one .m file.
The .h files are header files. It is called header file because it only contains the ‘head’ or a class, in other words, all the properties and functions that any other outside class should know about, the ‘public face’ of a class. It does not contain implementation logics at all.
On the other hand, .m file contains all the implementation details of all the functions declared in .h and more. It also contains declaration and implementation of private functions that outside classes cannot use, or should not care about.
How to ‘use’ these files, a simplified perspective
You got yourself a pair of .h and .m files, downloaded from Internet or someone send it to you and tell you to figure it out by yourself, either way you only have the files and no documentation. So you wonder where to start to get a big picture of what it does. This happens more often than you think. As a more seasoned developer now, I still find myself downloading open source projects and look at how some of the classes are implemented all the time, mostly from cocoacontrols.
First, you need to tell the names and parameters of functions. This is where my previous post came in very handy.
Secondly, you should start to *only* look at the .h file. Because this file contains the public interfaces of a class that the writer wants others to know. There are a lot of things inside a .h file but most important are the functions. They look like these:
// Convenience constructor+(id)requestWithURL:(NSURL*)newURL;
+(id)requestWithURL:(NSURL*)newURL usingCache:(id <ASICacheDelegate>)cache;
+(id)requestWithURL:(NSURL*)newURL usingCache:(id <ASICacheDelegate>)cache andCachePolicy:(ASICachePolicy)policy;
// Run a request synchronously, and return control when the request completes or fails-(void)startSynchronous;
// Run request in the background-(void)startAsynchronous;
// Clears all delegates and blocks, then cancels the request-(void)clearDelegatesAndCancel;
This is taken direct from ASIHTTPRequest network library that I used for my latest projects.
And as you can probably tell, the snippet describes how to create a connect, start it and then stop it. It is pretty much all the basics that you need to make use of the class. Luckily a lot of library developers out there do include one-line comments like this in their public interface, they are really useful.
You only need to look at .m files if you want to understand or copy the implementation of the classes.
The import statements
At the beginning of all the files, you will need to import the .h files that you are working with. This is because Object-C is a compiled language, you need to tell the compiler what are the objects that you will be working with, more importantly the compiler need to know the exact interfaces available in those files in order to compile them in your current class. If you manage to compile successfully code that contains a call to a mis-spelt function name, your app will crash! (There are ways to do this).
At this point, you only need to know that whenever you need to call external classes, you need to import their .h files.
So now you can walk to your nearest iOS noob friend and pretend that you know everything about the class that he is working on just by looking at the .h file and quoting some function names. What’s cooler is that you can even ask why not declare them slightly different… that is before he shoots you down with questions you don’t even understand.
You can now subscribe to my blog using the form on the right column. Thanks for reading, do share it with your fellow iOS coder too.