Today was the first day that I didn't secretly wish that I had my Laptop that I could hide under my desk with to work on. I also did a lot more coding today, so it's starting to feel like I'm hitting my stride with the iPad.
What went well?
Diet Coda fits way better into my mental model of the universe than Textastic did. Let me explain why. Diet Coda is a client-server application. It depends on a server to edit files. It doesn't allow you to download local copies of files and edit them offline - you have to be constantly connected to a server. For most people, that's a disadvantage but it actually works better for me. Here's why. Textastic requires you to download a copy of a folder or file to your iPad before you can make edits. The problem then is that you have to then upload them back to the server before you can build. That wouldn't be so bad if Textastic was using a kind of version control system…but it's not. Re-syncing your files to the server is an entirely manual process. You have to pick the local files or folders that you want to move back to your server, AND then pick which ones on the server you want those to replace. It's really not an intuitive process and I didn't enjoy it at all.
I felt much more at ease with Diet Coda and I actually was able to jump in with it and crank out a couple of new features on a project. I didn't have to worry about forgetting to sync a certain file, either to the device or back to the server. Every file I needed was right there and it's simple to edit. The best part though is really the integrated Terminal. I'm just a tap away from being able to run xcodebuild or check in my changes to subversion. Yes, you miss Objective-C syntax highlighting that you get from Textastic, and yes you miss cool features like the jump bar, but for me those were less important than the ability to more quickly access the Terminal and the lower amount of hassle to edit files.
I spent a fair amount of time in Google Docs again today, including some time collaboratively editing a document with someone. While I did stumble upon one crash, I really was surprised by how good the experience was. Everything he was typing showed up immediately on my screen, and vic-versa. Great stuff.
If you've ever compared Box.net to Google Drive and Dropbox the first thing you'll notice is that the Mac sync experience for Box is terrible compared to the others. The iPad app for Box, however, is great. This may be one of the best examples of a piece of my work that is actually better on the iPad. Using Box to look at documents and videos was great today.
So what didn't go well?
I used Screens once today…I almost made it the full day but I wasn't able to :( I needed to zip up a piece of source code to email to someone. In retrospect, I probably could have zipped it up, copied it to Dropbox via the terminal, and then emailed it to them via the Dropbox app…but I didn't think of that at the time. That's about it though. The experience was far more positive today than negative.
The new experience that I noticed today in terms of my interaction while using the iPad was that I tended to pair program with people more. Several issues came up today that I had to help with, and where before I might have just pulled out my laptop and dove in I tended to just sit with another developer and work through the problem with them. I could look at what they were doing, while pulling up other classes and documentation on my iPad. Sharing came into play again today, where I would find something in DocSets and hand the other person my iPad to show them a method or property that I'd found. Sometimes you don't need to be at the keyboard to get something done.
The best lesson that I learned today though is that while it may be difficult to create a new app from scratch on the iPad, as I was trying to do yesterday, it's really not hard at all to edit an existing one. Given what I experienced today, I am now absolutely confident that I could carry my iPad on a trip with me and be equipped to fix a bug or small issue that came up while I was away from a Mac. Diet Coda + Prompt are more than capable of tackling that, especially with Screens to view a debugger if I got stuck trying to figure it out.
Speaking of a debugger, one of the biggest issues facing developers trying to develop an app solely on the iPad is the lack of a console or a debugger - anything to get feedback about the app while it's running. In Xcode I depend heavily on the debugger. It's such a great tool for diagnosing issues. But before I learned how to use a debugger I used print statements in the console to diagnose issues. Sometimes I still use them. Printing out values and comparing them to what you expect is a great way to figure out if something is doing the right thing or not. So then I asked myself, wouldn't it be great to have this kind of support on an app I was working on on the iPad?
Yesterday I started out trying to make a simple debugger library that can be added to another app. It's actually very simple. It's got two parts: a log macro, and a console view. The log macro is very similar to other log macros, like DLog, except that it logs the text out to a file that gets cleared every time the app restarts (similar to how Xcode clears the console). The console view is a text view that just prints out the contents of that file. Simple enough. That way you can just add debug log statements to your app that are only intended to be viewed in this console. But you don't always want to see the console, so how do you handle that? I added a global swipe gesture that shows and hides the console as needed. It's super simple, but it's actually pretty effective. Here's a screenshot of the sample app below:
That's all for today. Overall the experience today was extremely positive. With two days left, I am getting more confident that I'll reach my goal of not only using an iPad for work for a full week, but also not having to use Screens for a full day. Wish me luck!