objc_msgSendfunction underlies everything we do in Objective-C. Gwynne Raskind, reader and occasional Friday Q&A guest contributor, suggested that I talk about how
objc_msgSendworks on the inside. What better way to understand how something works than to build it from scratch? Let's build
So yesterday I started coding our Hacker News app for iOS, which I decided to call “Hackerful”. Yesterday after drawing the sketches, I created the project in Xcode and added a few of our libraries which I will be using for this app:
I started putting these building blocks together and in a few minutes I had view controller which could show the HN front page (albeit, missing a lot of important information).
Pretty cool for a few minutes, isn’t it? Next step was making the screen more comfortable to look at. Black on white is not bad, but it might get tiresome if you’re reading for a long time. Let’s make the text #383838, the background #F0F0F0 and add a small #FFF shadow to the text.
These simple changes make reading easier on the eyes, while still keeping enough contrast between the text and the background. Now that we have the basics of the cell ready, let’s add the missing information and a bit of eye candy.
One thing that bothers me about the HN layout is there are no images for the stories, so that’s something I really wanted to fix in this app. We already have a web service in place which returns a suitable thumbnail for any URL (either by finding an image or by rendering the page in WebKit), so using this service as well as our ImageStoreKit library I was able to add story thumbnails with less twenty lines of code (18 to be exact!).
Things are starting to look better now, aren’t they? Let’s add some more data to the cell.
As you can see, I used the “Apple blue” as the color for the submission time, which is normally used as the secondary text color. For the username I went for 50% gray because I didn’t want it to stand out too much (you probably don’t mind who submitted the story). Finally, I used orange for the score, as a reference to HN.
Now this view is almost finished. If you take a look at the sketches from yesterday, I drew a comments button at the right of cell, so the user can either open the story by tapping on the cell or open the comments by tapping on the button. Let’s add it:
Rather than making an image on Photoshop, I decided to draw the lines on the left of button using CoreGraphics. Also, the comments button is painted at runtime, using the image only as a mask. This way we don’t need multiple images for the selected/unselected states. Even if we later decide to implement color themes, we can still use just one image per screen scale.
As the last steep for today, I added support for viewing the linked story. Since RCWebViewController implemented almost everything I needed, I just subclassed it to add a property with the story as well as an additional button for opening the comments.
And, as you can see, I got readability support “for free”.
That was all for today! As you saw, reusing lots of libraries makes writing apps really fast. This was only what I was able to write on the first day, and that makes me really excited because I think that the app is going to be pretty good by the end of the seven days.
Stay tuned for tomorrow’s post, where I’ll start working on rendering the comments, including cursive, monospace, etc… as well as clickable links using CoreText.
P.S: I’m still looking for a designer to make the icon for this app. If you’re interested, drop us a line to firstname.lastname@example.org (if you can also include an approximate quote and a link to your portfolio in the email, that will be great!).
If you’d like to be notified when we release this app, don’t forget to subscribe to our mailing list:
I was pleased to find out today that a very nice Mac app, Viewfinder — a desktop utility for searching and downloading photos from Flickr — has been resurrected, and taken over by SweeterRhythm.
This was apparently due to some secret negotions between people named Fraser!
I'm glad to see that the app has been given a new lease on life. Some new features are already apparent in this new 1.2 version; I look forward to seeing what Fraser Hess takes it now that Fraser Spiers has changed careers.
(Hey, the Viewfinder website looks suspiciously like it was built in Sandvox!)
I’m not one of those heavy users of Hacker News, but I skim over the front page multiple times a day, whenever a have a few free minutes. Since HN uses a text-heavy and table based layout with very small clickable elements, browsing it on a phone (which is the device I have on me most of those times) is not very pleasant.
I know there are several iOS apps for HN, but after trying most of them and not finding any of my liking, I decided it was time to build one at Rainy Cape, in the hacker way. What does this mean? I will be writing this app as a one man project, without any help from a designer, except from the app icon.
Over the next seven days, I will be working full time on this app and making a blog post every day, as detailed as possible, showing what I was able to build each day and the difficulties I found on the way.
You’re probably thinking there’s no way to build a decent app for HN from scratch in a week, and I have to fully agree. However, here at Rainy Cape we have written a lot of reusable libraries for doing the most tedious tasks which let us build complete apps really fast. It won’t be the first time we’ve had a version 1.0 ready in a week.
These are the features that I’d like to have for v1.0:
Since I want to have this ready in a week, I might end up having to remove some features, but I don’t think that’s gonna happen (in fact, I think I will have time to add some more features). Initially, the app will only support iPhone, but if I have time for more features iPad support will surely be added before 1.0.
So, let’s get some work done! As the first steps on any app, I usually start with some good old pen and paper mock ups, to get a better idea of how the app will look like. In this case, I drew these four screens.
As you can see, I will be using the “sliding” view controller layout for the main view. The web view and the comments view will both use a toolbar to display their available actions (since the space is so small in the iPhone’s navigation bar. The cells will display a thumbnail for every story next to the story title, the submitter and the up votes. Each cell will also contain a button for viewing the comments. This way, the user will be able to tap on the story, to read the linked article, or tap on the comments button, to view the comments on HN.
As I mentioned earlier, the only part of this app that won’t be done by me will be the icon. I’d really like if a designer from the HN community made this icon for us, so if you’re a designer and you’d like to make this icon, get in touch with us at email@example.com (if you can also include an approximate quote and a link to your portfolio in the email, that will be great!).
And that’s all for today. Now it’s time to start coding!
If you’d like to be notified when we release this app, don’t forget to subscribe to our mailing list:
After shipping MarsEdit 3.5.7 earlier today I discovered a major, crashing bug that affected only certain customers with non-US keyboard layouts including Spanish, French, and Swedish. I made changes affecting the handling of different keyboard layouts in 3.5.7, and neglected to test those changes with an extensive enough variety of keyboard layouts.
It always feels terrible to ship a serious, crashing bug. It’s even worse in the context of the Mac App Store where developers have no direct control over the approval and release of new versions of the software. After waiting 14 days for 3.5.7 to be approved, I was excited to release it as soon as it was ready. But once you approve an app for release in the Mac App Store, there’s no going back. I can’t “wind back the clock” to make 3.5.6 available again.
I decided to remove MarsEdit from sale on the App Store until Apple approves 3.5.8. Of course this means I will not be able to make any new sales until that time, but it also means I will avoid causing unnecessary grief for afflicted customers. When you remove an app from sale it also removes any updates that may be available, withholding them from existing customers. In this case, that is exactly what I want, or at least it’s as close to what I want as is possible.
Here’s hoping I didn’t screw anything else up today.
Update: After submitting the bug fix version to Apple earlier today and requesting an expedited review, I received a notice from Apple that they would try to expedite it to review within 1 or 2 business days. Luckily they ended up putting it into review and approving it tonight, so “everything is back to normal again. Phew.
A few days ago, my friend Colin and his wife Sara released a new iPhone app ("Selene — The ovulation-tracking tool for serious women"). As a new application, it's going to start needing some attention from the press, from bloggers, etc. in order to make it a success.
And then yesterday, I was listening to the latest podcast episode of iDeveloper Live, in which Scotty and John interviewed Erica and Steve from TUAW about their new eBook, Pitch Perfect [iBooks/Amazon]. Naturally, I thought about the challenge that my friends — and other new developers — have in getting their new apps noticed.
If you are a developer (either kind —
Country or Western Mac OS or iOS) you should give this episode a listen. Or, if you tend to do better reading than listening, get the book. (I did!)
Colin and Sara had no problem getting me to mention the app — seriously, it looks pretty cool even though I'm not exactly the target market for it — but hopefully for the bigger blogs, Colin and Sara will be able to take advantage of Erica's and Steve's advice and express their enthusiasm for their app that is equal to the level of enthusiasm and dedication that it took them to build their app.
(I should point out my old "Mac Indie Marketing Blog" here. I put it aside a while ago, before the Mac App Store became a reality, but I think that most of the ideas that I had gleaned and shared in that blog are still relevant, even in a post-Mac-App-Store world.)
Photo credit: Tyler Ball
Update: Unfortunately a major crashing bug required an urgent fix and release of MarsEdit 3.5.8.
This update includes long-awaited support for recognizing and setting the post statues “Private” and “Pending” on a WordPress blog. This is especially important because previous to 3.5.7, edits by MarsEdit to a private or pending post would cause WordPress to assume that the post should be changed to “Published” status, potentially revealing private information.
Apart from that there are a number of minor improvements and bug fixes including performance fixes for WordPress that should cause publishing and refreshing to be somewhat faster. Folks who use keyboard layouts with non-Roman characters will appreciate a fix to a bug that caused keyboard shortcuts to stop working when switched to e.g. a Thai or Greek layout.
Complete change list below:
And now for another blog post in the aftermath of the huge event last week which made a lot of people sad and put a huge drain on our economy. No, I'm not talking about the Presidential Election! I'm talking (again) about Hurricane Sandy.
TUAW recently wrote about the importance of off-site backup. I wanted to chime in with my personal story.
Many years ago, there was a large firestorm that destroyed thousands of houses and apartments. And I was living within the evacuation zone. And in my home office was the only copy of some program code I had spent years working on.
I was actually quite religious about backing up my work! (In those days, we didn't have Apple's Time Machine. I backed up onto 44-Megabyte Syquest cartridges.) The problem was that both the main computer and the backup were sitting on my desk.
"No worries," you may say. "Just grab the disks on the way out the door — problem solved!" Except that I was actually away that day, so by the time the area was closed off, I couldn't get back to my house to grab anything precious.
That was the day that I became aware of the importance of off-site backups.
Fortunately, the fire was contained and I got lucky. But I still shudder to think of how much work would have been lost.
The moral of the story is that you, dear reader, really ought to get something set up for offsite backup. You probably have a whole lot of stuff that, if lost due to earthquake, house fire, hurricane, flood, robbery or other unfortunate event, would really bum you out.
The aforementioned TUAW article was big on CrashPlan. I've actually tried that but I wasn't impressed. It seemed like a non-Mac app trying to masquerade as a Mac app. It was just klunky. Maybe it has improved, but I didn't like it back then.
The Internet-based service that I use and enjoy is BackBlaze. It's inexpensive ($50/year), and it's well-integrated into Mac OS X. Once it's going, I usually don't have to think about it.
I highly recommend setting this up! Think of it as insurance. (However, if you are working with a lot of data, like video work, and you don't have a ultra-fast Internet connection, you may want to start out your backup by filling up a spare hard drive with your data and leaving it in the care of an out-of-town friend. It might take weeks or months to get your data finshed uploading to a remote backup service! It would be better if you were secured from the get-go.)
BackBlaze has saved my proverbial butt more than once, though not due to anything as dramatic as fire or flood. A few months ago, a hard drive failed on my main Mac. I wasn't worried about my data, because I use Time Machine for local backup. (Also important!) I was ready to just restore from my Time Machine drive, when I discovered that the backup had somehow gotten deactivated a while back. My Time Machine backup was way, way out of date.
But my Backblaze backup was current! I ordered a hard drive filled with my data to be shipped to me, and I was completely back in business.
So don't say I didn't warn you. Get your data backed up, offsite!
(Photo credit: Randy Le'Moine Photography)
Saul Mora, the host of NSBrief, was recently in town and visited FM's world headquarters where he interviewed me for a podcast. I had a good time recording this- it's nice being in the same room as someone else when making a podcast. I think it adds something to it that you just don't get when recording over the net (and as soon as teleportation is invented, this won't be a problem anymore).
We talk about a whole bunch of things, VoodooPad, FlySketch, FMDB, how certain parts of Acorn are implemented, and lots of other things: NSBrief #71: Gus Mueller.
As you probably know, Hurricane Sandy has left thousands in New York and nearby without power. Because of this, people there have been improvising when it comes to getting their cell phones charged.
(Photo Credit: Dan Nguyen)
I grew up in a small town where we lost electricity fairly often, but usually we still could use the phone if the power went out! That's because land-line phones run on their own (DC) power supply. So when AC power was out, the phone system still worked just fine.
These days, it's different. So many people have given up on having a land-line, in favor of going cellular only. And I'm willing to bet that most people's land-line phones won't even work without AC power! (I checked — we still have a phone extension that doesn't require AC, though our main cordless phone does.)
(Photo Credit: edenpictures)
It's really a shame in our society that when we raise our technology higher and higher, we throw away the scaffolding that got us there. And that can be bad news in a disaster, when the high-tech utilities we have come to rely upon are out of commission, even if temporarily.
Telephony is just one of the utilities that we are losing our scaffolding for. Another essential technology that we're coming to rely on more and more is GPS. It's been called "the invisible utility." I recently watched this fascinating TED talk about GPS; I learned that it could be disrupted or spoofed pretty easily. It's not a big deal if GPS goes out in your iPhone and prevents you from finding the nearest Wal-Bucks, but it is pretty scary if it goes out when, say, a ship is trying to navigate into a harbor on a foggy night. The problem is that the older technology (e.g. lighthouses, radar) is being phased out in favor of GPS.
Back to New York: I've seen pictures of corner markets staying open, albiet dark, while the power has been out. Small shopkeepers can probably keep things running pretty well, though maybe they have to resort to some manual techniques for handling cash and giving out change. It's probably hard to handle credit cards if they are used to AC power for doing so. So certainly, as a resident, having some low-tech greenbacks on-hand is a good idea just in case the high-tech alternative is unusable.
What I wonder about, though, is how to the big stores — supermarkets, especially — handle a disaster where there are hundreds of hungry or panicked residents, and no way for employees to take their money? The employees are probably not even trained for low-tech contingency plans. It's sad to think about — those worried customers are probably going to turn into a rioting mob if the store they are at is unable or unwilling to sell them what's on their shelves.
What are the other technologies where we are unwisely removing their lower-tech alternatives?
Listening to the latest iDeveloper Live podcast in super-fast mode (QuickTime Player 7 FTW!), John Fox brought up the idea of thanking people. Perhaps this came up because it's now November, month where Thanksgiving happens, but I thought that would be a great idea. So in this post, I'm going to thank a few people who have helped me in my professional life. It is impossible, and it would be boring, to try to go through everybody in the world, so I've just picked out a few people that I thought of — mostly people from my earlier Cocoa days. (Maybe I'll do another round later.)
Thanks Ken Dyke, a co-worker of mine at Electronic Arts back in the mid-nineties. When Apple bought out Next, I was perplexed — but Ken's over-the-top enthusiasm about the event sparked my interest and insatiable appetite in learning OpenStep (the predecessor of Cocoa). Without that spark, it might have been years before I started learning that technology.
Thanks Bertrand Mansion, who created the mailing list archives now called CocoaBuilder. Nowadays I'm just as likely to find a technical answer via a Google or DuckDuckGo or StackOverflow search, but back in the day, Bertrand's archives were the place to find just about anything related to Cocoa.
Thanks Dave Shea, creator of CSS Zen Garden, who showed me that it's possible to style in an infiite number of ways using CSS. This was, in many ways, the inspiration for Sandvox.
Thanks Robert MacKimmie, and the rest of the leaders of BaNG, the Bay Area Next Group, which met regularly in the late nineties and early ohsies. I was new to all of this technology, and because of these meetings, I met a lot of Ex-NeXTers who inspired me to continue playing around with Apple's inchoate operating system. Incidentally, Robert was my first introduction to the then-astonishing idea of urban beekeeping, something I now practice myself.
Thanks Lowell Schneider, who helped me with some Cocoa mentoring during the days I was unemployed and writing Watson. I would camp out in his nearby Schema Research office once or twice a week. I remember being blown away by some of his Interface Builder palettes (now, alas, something no longer possible in Xcode) that essentially made data binding possible before it became supported officially by Apple.
OK, that's all for now — no point in getting maudlin. :-)
Who do you have to thank for where you are now?
I'm relieved that we have finally been able to release Sandvox 2.7 today!
Behind the scenes, this has been a long time coming, thanks to what I like to call a "Perfect Storm" that Apple laid in our path. (The recent destruction by Hurricane Sandvox is just a coincidence, really!)
Apple had a very busy summer, throwing down several gauntlets for us:
So while we would have liked to to work on some new features independent of what Apple was doing, we found that these events from Apple were, well, opportunities for us to address.
MobileMe ending was the first challenge we tackled; we were able to create an iWeb site extractor and submit that to Apple as part of version 2.6, before the Sandboxing deadline. (We wanted to give iWeb users plenty of time to migrate their iWeb sites over to Sandvox before the MobileMe lights went dark.)
But then after June 1, we were only able to submit bug fixes to the App Store until we could get Sandvox working in the Sandbox. (And yes, imagine how often I mistype "sandbox".)
Getting our application Sandboxed was a bit of a challenge. So while we had the other responses to Apple's actions implemented pretty quickly — Retina application graphics, new Mountain Lion features — it took weeks and weeks of refinement, submissions, rejections, and so forth — until our new sandboxed version 2.7 was finally approved yesterday.
I don't mind responding to Apple's developments, but four at a time was a bit much, thank you very much.
Now that we are past that, maybe we can start working on some new features that have nothing to do with what Apple is doing!
Smashing Magazine today published a blog post Better Password Masking For Sign-Up Forms. It suggests that a masked password (where the letters are replaced with ••••••) isn't such a great idea for making an account because you can't see what you have typed. Even if you are asked to enter a new password a second time, it still leaves the possiblity of error.
One suggestion it makes is to unmask the password when the field is focused. That's an intresting idea, but not a great idea if there is a curious person looking over your shoulder.
The final suggesion is a checkbox, where the user can choose whether to mask or unmask the password. That's probably the best compromise, since it lets the person typing the password control things.
(In fact, we're doing something like that on the upcoming version of Sandvox where you are prompted for a password to access a server where your website will be hosted.)
The problem with this approach is that it's up to the creator of the web form to implement that behavior. It's also kind of klunky because it's not really obvious where the checkbox should be placed. Below the field? Above it? To the side?
What if, instead, there came into being an adjustment to the password input control on desktop computers that just included the mask/no-mask option in it?
(Here's a super-quick mockup.)
This is a followup to that, describing what we did to build our online store, and what decisions came into play for its user experience. (In another followup post, I'll discuss more of the back-end pieces we're using.)
When I realized that we could do just about anything we wanted to collect payments without the limitations we had before, I started looking around at a lot of online stores. I visited websites of fellow indie developers. I looked at the big online retailers. I looked at large retailers with an online presence.
And you know what? Everybody seems to have a different way to collect payments.
For example: some sites take you through multiple steps as you fill in your information. Fill in some fields, click a button to go to the next page, fill out another page or two, and eventually you're done. Others, on the other hand, collect all the information at once, with a single submit button at the bottom.
Different sellers handle input validation and errors differently. Some are proactive, offering helpful suggestions along the way if it looks like you have made a mistake; others wait until you have submitted the form to provide any error messages for you to collect.
After looking at examples and reading some online articles about payment form best practices, I started working on some iterations and refining them with Terrence's and Mike's input.
One overarching goal was to keep the form looking very friendly and simple, but allow for some more complicated scenarios (such as handling coupons or purchasing a gift license).
First off, I decided that we wanted a single-step form; it seems to me that the fewer steps there are, the fewer chances we will lose somebody along the way. We wanted to make sure there were plenty of explanations of what the input fields are for, and why we need them. We wanted as much real-time input validation as possible so that there would be a live status update as the visitor clicks from field to field. (More on that in the followup post.)
To keep the more advanced options out of the way, we used simple text links (prefixed with a right-facing disclosure triangle) to allow additional sections to be revealed only if needed.
We put plenty of explanatory text below each field, to provide context for each input. That text even adapts as needed when additional options are disclosed. (Example: the explanation for "Your Name" changes if an advanced section is disclosed.)
Though the inputs are all collected in a single form submission, we felt it was important to group the similar types of input together into discreet chunks. We came up with three main sections: What the visitor is buying — from this a price is calculated. Then, who the license is for. Finally, the actual payment.
As I mentioned in my previous post, we wanted to keep PayPal an an option as well. So after a few iterations, we came on the idea of putting the PayPal button off to the side, at the top of the section where we deal with payment. This lets the visitor choose how to pay after we've collected the other information we need. The normal path is to continue and enter the credit card information, but they can veer off that path and use PayPal instead. This approach seems to work pretty well.
To reassure the visitor that this form is safe, we use the word "secure" above the payment section and feature a lock icon if it's an HTTPS connection. Plus, we link to Stripe and their security page at the bottom.
In the field for the credit card number, we do something clever inspired by GitHub's payment form. Like GitHub, we show icons for the credit cards that Stripe can process. But as the visitor types in a number, the first couple of digits indicate which type of card they are using, so we highlight the card they are using and fade out the others. No point in asking them what type of card they are using; this approach means one less step for the visitor to take, but it visually reinforces the card that they are using.
Naming and explaining the field for the 3- or 4-digit CVC/CVV2 code is never easy, and it varies greatly from website to website. We decided to call it "verification code", explain it below the input field, and provide a little thumbnail for where it can be found on a typical credit card.
Since this code is on the back of most cards but on the front of Amex cards, we do something kind of fun. If you enter an Amex number — try typing "34" in the Card Number field — we animate the card to flip over to show the front of an Amex card. (Also, we highlight the explanatory text referring to the Amex location.) Try it!
That covers most of the design decisions for how to present the credit card input form. Next time around I'll describe what we are doing on the back end to deal with validation, internationalization, and dealing with unfinished transactions.
For the comments: How might you improve this form? (Despite the title, I don't think this is perfect by any means, and maybe there are more improvements we can make to it!) What are some other nice things that companies have done for their payment forms?
With the introduction of the iPad Mini today, I noticed that Apple's guidelines for the minimum size for touchable elements, 44x44 points, is probably no longer valid.
Because the screen size is 1024x768 in spite of the smaller form factor, that means that 44 pixels is going to be significantly smaller than 44 points.
I did some quick calculations based on the published specs for the iPad Mini, and it looks like the screen size is 81.44% of the size of the full-size iPad.
This means that apps should probably consider that their minimum touchable size is 54 x 54 pixels.
Or, developers can just assume that people with the iPad Mini have skinny fingers.
There are a lot of apps on the app store that are going to be difficult to use on the iPad Mini, I think.
Or did I miss something here?
Update: Thanks to Kris in the comments, who linked to this article. I guess iPad developers have already been designing iPad elements bigger than they needed to be (to maintain iPhone compatibility, with its denser pixels) so now the new iPad Mini just brings the density down to the same as the iPhone. Whew!