I was setting up a project with one submodule on my working iMac and was wondering how to do this most quickly. After tweeting the approach I had found, there where quickly some very smart people responding on how to do that better. I found this kind of crowd-sourced incremental improvement exhilarating, so I’m sharing it with you.
While giving many designers a headache the Twitter app still serves as template on how to solve a variety of UX riddles. One of which is the situation where one might want to have sections in a tableview that possess the ability to expand from one row to several and collapse vice versa.
The eye of the experienced developer sees two challenges contained therein: 1) grafting a mechanism for collapsing and expanding onto UITableView in a reusable way 2) making custom accessory views that look like a rotated version of the disclosure indicator, pointing upwards or downwards and also changing color when highlighted.
In this article I present my solution to this UX riddle. At the same time I will demonstrate how NSMutableIndexSet can be used to our advantage. In contrast to the pull-to-reload method previously discussed, this does not contain anything remotely patentable.
Update March 12th, 2013: Cleaned up version of the custom-colored accessory is now available via DTFoundation, the example project is now part of our Examples collection on GitHub. Please note that if you use this code you have to attribute it to us or buy a Non-Attribution License.
Previously when integrating existing library code with new projects I would have simply copied the necessary groups from from Xcode project to another. Then I would choose to copy the files to the new project to be sure that they got included in the source tree. Otherwise the project would not build for other people accessing the same source control management (SCM) server.
Now with Xcode 4 this technique no longer works. You simply cannot drag groups between workspaces. The question that interests us today is how we can add an existing GitHub project to our own.
Let’s see if we can figure out a simple and duplicatable method to achieving this. It would make our lives much easier to not having to duplicate component code for each new project.
Similar to the previous article on decoding HTML colors we also need to decode HTML entities like ". So I found an authoritative list on the web, courtesy of Wikipedia and in this article I will demonstrate how to use quickly hacked up command line tool to convert it into Objective-C.
This shall serve as an example as to how quickly you can leverage your objC knowledge to build a useful tool for such a one-off operation. If you know how to reuse your skills from iOS development on command line tools then you can always quickly whip up a one-off tool to do some work that otherwise you would have needed to do manually with a text editor.
In my article on CoreText I mentioned that Apple left out some very useful methods from NSAttributedString, namely the ones that would allow you to create an attributed string from HTML. Now you would probably not want to create attributed strings from complex HTML documents, but use that for simple tasks like displaying one word in a different color or bold.
My first thought was that maybe I should make it a sellable component, but I dismissed this idea for two reasons:
- there is a certain likelyhood that Apple will implement the missing functions in the next major SDK refresh
- if I would get help from people who are more experienced in dealing with HTML parsing then this would benefit everybody involved
So I posted the question on Twitter as to where to put the shared code. The response was a resounding GitHub (one mention of Mercurial and Assembla each). So far I had put off dealing with GitHub, because – in contrast with many other iOS developers – I happen to very much like Subversion integration in Xcode.
Read on to learn how to get started.
I am building a category for NSAttributedString that will allow me to make attributed strings from HTML code. For coloring the text there are two methods in HTML, via the deprecated font tag and via style. Both use color names or hex to describe the color.
The W3C knows 147 color names, clearly too many to type in manually. So I used a bit of shell script magic to hammer this into Objective-C. Then I also needed an elegant method to make regular UIColor objects from a hex string.
Both I am sharing in this article. These methods are invaluable if you are dealing with web people who are used to specifying colors this way. Also it might be more intuitive if you can specify colors in hex format yourself. That is, if you are a geek who is used to thinking in the hexadecimal system.
Before the iPad was released you had basically two ways how to get text on screen. Either you would stick with UILabel or UITextView provided by UIKit or if you felt hard-core you would draw the text yourself on the Quartz level incurring all the headaches induced by having to mentally switch between Objective-C and C API functions.
As of iOS 3.2 we gained a third alternative in Core Text promising full control over styles, thread safety and performance. However for most of my apps I did not want to break 3.x compatibility and so I procrastinated looking at this powerful new API. Apps running only on iPads could have made use of Core Text from day 1, but to me it made more sense supporting iPad via hybrid apps where the iPhone part would still be backwards compatible.
Now as the year has turned the adoption of 4.x on all iOS platforms is ever more accelerating. Many new iPads where found under the Christmas tree and by now even the most stubborn people (read needing 3.x for jailbreaking and sim-unlocking) have little reason to stick with 3.x. Thus we have almost no incentive left to stick with 3.x compatibility. Yay!
In the latest version of iWoman– which I’ve been working on the past few weeks – I had a situation where I am sliding up a date picker when the user taps on a date cell. Sliding it out when the user taps on other cell was easy, you can do that in the other cells’ didSelectRowAtIndexPath. But if you have that in a grouped tableview then there are several areas outside of cells that also could become the targets of a user’s taps.
Generally a user would also assume to be able to dismiss the picker by tapping there, in headers or empty areas where you see the background shine through. In this blog post I’m showing you a technique on how this is done most efficiently and also backwards compatible.
I tried out several approaches before settling on this solution. You might be able to use a gesture recognizer, but that would rule out 3.1 compatibility. You could override the touch methods of the table view and do some fancy detective work there. But I found – as I did so often before – that by far the most convient way is to override hitTest.
Have you ever wondered what is going on when all those apps on your iPhone communicate with websites and web services? In this article I will explain a technique to employ your Mac as a spy to be able to inspect all the traffic that goes on between the public Internet and your iPhone.
This is wonderful for learning what POST requests need to be made of if you do screen scraping. It’s also quite useful if you are planning to reverse engineer some API that is not public yet. Finally you can use it to look for potential security concerns to report to the makers of your favorite apps.
You require a Mac that has a wired internet connection as well as built-in WiFi. We’ll use the Mac as the “Man in the Middle” and route all Internet traffic from our iPhone over it so that we can inspect the HTTP/HTTPS.
A year ago I touched upon the question as to how you can prevent NSURLConnection from aborting a HTTPS GET if the certificate is invalid. At that time it seemed like the only method available was a forbidden one: allowsAnyHTTPSCertificateForHost. It’s undocumented, works, but gets your app rejected if Apple finds it when scanning your symbols.
But what should people do who don’t want to shell out hundreds of dollars for a trusted HTTPS certificate just so that they can reap the benefit of encrypting their web traffic and possibly hide user login data from prying eyes? The alternative to those commercial certificates is to produce a Self-Signed one and install it on your web server.
In this article I will demonstrate how to properly and officially deal with self-signed certificates via NSUrlConnection. It just so happens that I have a *.cocoanetics.com on my website, primarily used for protecting SVN communication. If you go to https://www.cocoanetics.com you will see it in this dialog:
Since a Self-Signed certificate does not have a trusted root the standard is to ask the user if he wants to trust the web site temporarily, permanently or not at all. The reason being that encryption only makes sense if you know that the recipient is who he says he is. Any other site can also produce a *.cocoanetics.com certificate for their IP address. Root Certification Authorities (CA) provide security that only a certain IP address can be the holder of a domain name. This is why you see the trust of the certificate be dependent on the trust in the certificate of the CA.
But if you are calling web services of your own you can forego this mechanism. In this article I am documenting how.