::Austin iPhone DevCamp 2 thoughts:: [/tech/mac] (13:55)

I've finally recovered from the long weekend of iPhone hacking at the Austin satellite of iPhone DevCamp 2. I really wasn't sure what to expect from experience. My impression from some of the pre-event discussions was that there wasn't a lot of people actually doing iPhone development now, a fact which was confirmed when I arrived. That meant that my weekend of sharing iPhone coding tricks and finding answers to some of the problems I've been having didn't materialize, but the weekend was still fun. Sunday was the more entertaining of the two days, as the crowd thinned a bit and more people got down to doing some actual coding. Of course, the real value of these things is meeting people, and for that the event was a huge success.

It remains to be seen whether a regular meeting of iPhone developers will emerge here or if the Austin CocoaCoder.org group will just expand in scope to assimilate the local iPhone coders. I do know that I'm on tap to present my iPhone app at this Thursday's (Aug 7) CocoaCoder meeting, so I'm guessing at least initially we'll explore both roads and see where the local community takes things.

::iphone dev camp - austin:: [/tech/mac] (11:34)

I'll be hitting Austin iPhoneDevCamp 2 this weekend. Tonight looks like a purely social event, so there's a good chance I'll wait until Saturday/Sunday for the main event. I've been putting my spare time into an iPhone app that should be submitted to the App Store sometime today. Now that I'm done, I'm really eager to talk to other local iPhone developers to see what they have been up to and maybe see if others have found better solutions to some of the iPhone dev problems I've run into.

Hope to see everyone there!

::Mophie Juice-Pack Review:: [/tech/mac] (11:19)

I'll be doing some overseas travel next week. With 18 hours in the air plus some airport time, I am quite concerned about how my iPhone will hold up. I'm not sure if I'll have access to under the seat power on this flight, so I started my hunt for some sort of extra battery for my iPhone.

There were several cheap devices for running an iPod off of battery power, but none of them really looked like they were up to the challenge of keeping an iPhone going. All the designs I saw were tethered, whereby a batter was connected by cable to the device. That would be fairly awkward on a plane. And, the existing models were reported to put the iPhone into airplane mode. Obviously that's not a problem for this use case, but I'd like to be able to use the backup battery in non-airplane situations without any fuss.

Just as I was about to give up and dig out my old nano as a backup device, I ran across the Mophie iPhone Juice Pack. The Juice Pack fits around the iPhone like a case, except that it instead of just wrapping the iPhone, the iPhone slides into it like a dock. While in the case, the battery in the case charges the iPhone and keeps the battery full for as it can. On my first day of use yesterday, I got my iPhone home and the iPhone was at full charge, with the Mophie at about half charge. (The Mophie has a battery level display that works like MacBook/MacBook Pro batteries)

I'm very impressed. The Mophie is not cheap, but my initial usage makes me feel that the money was well spent. I won't know until I try, but I'm confident it will get be through my trip with power to spare. Being able to snap the case on the iPhone should make it easy to transport.

There are a couple of negatives to the device. The case adds a small amount of bulk and weight to the iPhone. That doesn't bother me, but if weight is a big deal to you, you might want to try it out. If you are already have another case, then you'll have to give it up to use the Mophie. My iPhone is generally naked, so no loss for me there. The biggest draw back is that although the Mophie does have a standard iPhone connector on the bottom, you cannot sync through it. The case was a little too thick to dock in my iHome, so I couldn't verify whether or not you can play through it. Even if it can play, I consider the lack of sync capabilities a very serious flaw for such a high priced accessory. Finally, if you are considering purchasing a 3G iPhone in the near future, you've got no guarantee that the form factor of the new phone will be compatible with the Mophie. As wonderful as I think the Mophie is, I do plan to jump on the 3G iPhone when it comes out. If I weren't desperate for a solution for my upcoming trip, I think I would wait a bit to make sure the device won't be obsolete when the new models come out.

::Should Java be on the iPhone?:: [/tech/mac] (09:56)

Even though Java bashing is the fashion of the day, I'm not afraid to say that I still love working with Java. I still consider Java the only credible choice for just about every flavor of web or enterprise development. Some might even label me a Java fanboy, though my affection for Java is purely pragmatic. By almost any objective technical measure, Java is usually going to be the best tool in the toolbox.

You might assume then that I'm going to argue that Java should be on the iPhone. In some ways, I do think that. I think Objective-C is a nice language, and I've even argued that Java would be better off if it were more like Objective-C. That being said, I still think overall Java is better than Objective-C. Although the recent introduction of garbage collection is a a godsend for Objective-C, the language still feels like it's stuck 10 years in the past. Header files? Prefixes on every class name to avoid naming conflicts? It's just a clunky language. That doesn't mean it's bad. I really do like Objective-C. It doesn't have the comforts and conveniences of Java, but it gets the job done.

The iPhone is also set up to be a security nightmare. I haven't looked too closely into the security of the iPhone yet. I know apps operate in a sandbox, and requiring signed binaries will eliminate many types of threats. However, given Apple's track record with holes in Safari on the iPhone I think it's pretty clear that we'll have the same type of security problems we've seen on desktop machines. Since the iPhone will be the dominant mobile platform, it won't be able to hide behind the small market share that has kept the mac desktop relatively safe. It is possible that Apple has most of the bases covered here since the iPhone is a small and tightly controlled environment, but I'm not entirely sure. Apple does a lot of things well, but security is NOT one of them. The iPhone would be much better off running apps inside of a virtual machine (like the JVM) with no direct access to raw memory or hardware.

So, I'm arguing for Java, right? Sadly, no. You see, the key to the joy of Mac programming is Cocoa, and by extension what makes the iPhone great to work with is Cocoa Touch. Sadly, even though Java has had years to catch up, Swing is no Cocoa. As a Java guy, my first instinct would be to simply mirror the Cocoa APIs in Java. In theory you'd get the best of both worlds. Sadly, Apple tried that, and it didn't work out very well. Wrappers like that rarely do. To be fair, few Java programmers of the time were interested in developing apps limited to the Mac desktop, so Apple never had any incentive to really develop the Java bridge as fully as it could have. The iPhone would be a different story because it's a platform that Java developers would embrace developing platform-specific apps for. Still, I think a Java bridge for the iPhone would be a lost cause.

Similarly, Java ME and Swing apps have no place on the device. The iPhone should run Cocoa Touch apps written specifically for the device and for the multi-touch interface. I'd submit Android as proof of that. Android applications just look goofy as they try to support more primitive 0-9 touchpad interfaces. Maybe I've been using a Mac so long that I've just turned into a snob, but I don't want ugly apps on the phone. If the iPhone allows non-Cocoa applications, then I feel we'll get a lot of junk Java ME ports instead of apps that look and work like iPhone apps.

So, in summary, I don't want Java on the iPhone. I do wish the entire Cocoa stack were based on Java, and I do think it would be better if it were. But Cocoa is not Java, and as such there's very little that Java has to offer the iPhone right now.

::How to MMS from an iPhone:: [/tech/mac] (13:08)

The lack of MMS capabilities on the iPhone is quite odd. I can't quite see a business case for it. AT&T should want it so that they can charge a premium like they do for SMS. Apple has no reason to not want it, except perhaps not wanting the minor development costs related to it. Still, there's no direct MMS support for the iPhone.

That doesn't mean you can't send pictures via MMS. Every cell phone provider has an email to MMS gateway. For people you want to MMS, just add the address to their contact and you can MMS as easily as you send an email.

Knowing the address is a bit trickier because you need to know your friends cell phone company. If your friend is on T-Mobile, you can use number@tmomail.net. If they are on Verizon, it's number@vzwpix.com. Here's a thread at macrumors

that lists current gateway addresses for the major cell providers. Finding the right address is a pain, but I only MMS a couple of people so it's not that big of a deal for me.

I ran into a couple of gotchas. The SMS messages come from your primary email account, so if someone responds to your MMS you will get the response in email, even if they only trying to respond by SMS. That can break your nice iChat-like log of SMS messages. Also, be careful what your primary email account is. I originally had a Yahoo account as the primary address, and some of the Gateways were bouncing my messages. Switching to another account solved that problem.

Also, if your are on an iPhone, AT&T does not seem to forward MMS messages from their gateway to you or send a bounce back to the sender. I couldn't email a picture from my laptop to my phone using number@mms.att.net. That's understandable since the iPhone doesn't do SMS, but I'm quite surprised I didn't get the message back alerting me to the error. I hope that people who try to MMS from a phone will at least get an error message saying the picture can't be delivered.

::iPhone and openID:: [/tech/mac] (13:26)

One problem that has been bugging me about the iPhone's web application development strategy is login. It seems to me that most truly interesting web applications will need at least some sort of login capability. Typing names and passwords to access applications on the phone is too much work on device as simple as the iPhone. Keychain syncing could alleviate some of this, but it's not clear yet whether iPhone will support any sort of keychain notion.

The solution dawned on me. Apple should support openID. Without Apple support, it would still be wise for iPhone targeted applications to support openID to reduce password management issues and make mobile login faster. However, if Apple supported openID, things would be better. Every iPhone user will have an Apple account that can easily be transformed into an OpenID. Apple should be able to provide a streamlined authentication process that would get very close to a 1-step login from the iPhone. In fact, with just a minor change to Safari, your the iPhone could manage your openID so to potentially make that a 1-click login.

OpenID could really make iPhone web applications shine, so I hope the iPhone team at Apple gives this some serious consideration. At the very least, I strongly encourage anyone targeting the iPhone to consider supporting openID for login needs. It will make like easier for your users.

::My iPhone will be free, how about you?:: [/tech/mac] (10:43)

One blogger estimates that his iPhone will cost him at least US$2245. Since he asked others to do the math, I thought I'd add up my post-iPhone costs. Amazingly enough, I'll save so much money that the iPhone will essentially be free for me.

The original post estimates iPhone voice + data service for the iPhone to be $95 a month. That's pure speculation, but it's a reasonable enough number for the purposes of this comparison. That's a 450 minute a month plan. Being primarily a text message user, 450 voice minutes is well within my price range.

Currently, I have service with T-Mobile. My monthly bill is about $53 a month for a similar number of minutes and unlimited text messaging on a month-to-month plan. I also pay $85 a month to Verizon for EVDO data service. I primarily use my EVDO card for mobile web and email, so I think I'll be able to cancel my EVDO and use the iPhone for my mobile data needs.

So, my $95 a month iPhone service can replace my current $138 a month phone+data services. That's a savings of $43 a month. Using the math of the original article, I'm going to be saving $1032 over the two year contract period. The monthly savings will be able to finance my iPhone. In fact, it'll pay for itself so fast that I'll have a bit of a head start on a free 2nd generation iPhone when it comes out too. So, thanks Apple for the free iPhone!

::Why I cancelled my AppleTV order:: [/tech/mac] (17:52)

I love the idea of AppleTV. In fact, I ordered one right after MacWorld along with a new Airport Extreme. Over the coming days, I read up on what the AppleTV can and can't do, and I realized that the device just isn't for me.

It's a shame because I desperately need something like it. Right now I have a Mac Mini in the living room. I don't have cable/sattelite/etc, and the only other things plugged into it are a very old PS2 and a shiny new Wii. I only use the Mac Mini for Front Row things. (with Remote Buddy for VLC control) It's a great solution, but it has its quirks. I have to keep a keyboard and mouse handy to do system updates and to click those annoying VLC dialogs. It works, but it isn't slick. The AppleTV is a slick, all-in-one appliance with a great interface. So, why can't I pull out the Mini?

First, the lack of a DVD player is a killer for me. I don't want to add the clutter of a DVD player to my living room. I guess Apple assumes that you already have a DVD player and that you can always buy new movies from iTunes. Still, a media machine without at least the option for DVD support (not to mention Blu-Ray) makes no sense. It's a step backwards from the Mini.

Second, it's only 720p. My Mini pumps out 1080p resolutions just fine. Why the AppleTV should be a step backwards? There isn't really much content above that, so perhaps this is more of a whine than a practical complaint. However, the amount of content should increase. (I have a couple of 1080p video podcasts now) 1080p is reasonably common and isn't particularly expensive. The 42" Westinghouse 1080p LCD I got a year ago for $1800, for example, sells for $1300 now on Amazon. Anyone looking for a high def TV today should be buying a 1080p set, so it just smells bad to not be able to support those resolutions.

Third, iTunes video content is terrible. I know it's gotten better recently, but I've yet to see anything on iTunes that compares to what you can get from a torrent. Torrent content is cheaper, available sooner and downloads faster. Remember, the appeal of buying online is that it is supposed to offer a BETTER experience than unlicensed downloading. I love the idea of buying a season pass for a show and having it right there on my box with no work required by me. But, if is slow and of low quality, what is the point?

Fourth, it's not clear how realistic it is to import your own content. The AppleTV doesn't support a very exhaustive set of formats. I'm skeptical about the quality of re-encoding external compressed videos for the AppleTV. And, even if it is possible, we'll still have to see what kind of solutions third-party publishers have for quickly getting stuff into iTunes.

It's really too bad. I love the idea of AppleTV. I want AppleTV. I would have no problem paying the premium and being an early adopter. However, when the solution offered is such a backwards step, I have to bow out. I hope that AppleTV improves enough to be a competent replacement for my Mac Mini, but this initial version just isn't it.

::macdev.ca Cocoa workshop review:: [/tech/mac] (12:40)

I spent last weekend at the macdev.ca Cocoa Workshop here in Austin. It was a two-day class intended to give a basic introduction to OS X programming.

I think the class succeeded in doing what it advertised. Someone with very little (if any) programming experience would be able to take this class and learn how to create very basic Cocoa application. The class focused on using XCode and Interface Builder, with the hopes that if you are very comfortable with the tools you'll be able to expand to learn new components and APIs quickly. This is a validate approach for a beginning Cocoa developer since these tools let you do quite a bit with very little code. The class also spent a lot of time showing how to use the API documentation to figure out how to use components quickly, without needing to invest a ton of time up front in completely understanding how they work.

As a long-time coder, I found the class rather slow. I would have loved a faster paced class targeted at people who were already proficient coders who just needed to learn how to think about Cocoa apps. However, the slow pace didn't really hurt that much. APIs and components are easy to pick up. The hard thing for me has been getting comfortable with the basics and learning the tools. I got that out of the class, and the slow pace gave me lots of time to play around and experiment, making sure I really understood what was going on. If I hit a snag, the instructor was there to help out. In the long run, that may have been more of what I really needed than. I did get my money's worth from the class. The online tutorials from Apple make sense now, and I've been able to move on to much more advanced topics that I would not have felt comfortable with before.

If you are looking for a taste of Cocoa, I would definitely recommend the class. It delivers quite a bit of value for a low price. If you aren't a professional programmer, the class is perfect. If have some programming experience, you will probably find the class a bit slow-paced but still valuable. If you have done Cocoa before and are comfortable with the tools, you will probably be better served taking one of the longer, more advanced classes.

::Learning Cocoa - second pass:: [/tech/mac] (11:47)

I got started with Cocoa and objective-c a couple years ago. As much as I loved working with Cocoa, I didn't really get very far with it. There were always much more pressing things to learn, and it's hard to really pick with just an hour or two here or there to dedicate to it. I'd find that my the next time I sat down in front of XCode that I had forgotten what I had learned last time. Really learning a new style of coding (and Cocoa GUI programming is quite shift for an web/enterpise Java guy) takes more of an investment.

With that in mind, after the RedHat buyout, I decided one thing I would do to reward myself would be to take a Cocoa class. I had the Big Nerd Ranch Cocoa Bootcamp in mind. It looks like a fantastic class. Just as I was trying to pick out a time to register, I discovered a Cocoa class here in Austin. It's a much smaller introductory class, but I think it will meet my needs (getting a solid introduction to Cocoa) quite nicely. Then I go on learning, and maybe hit up the Big Nerd Ranch class later on. Perhaps after is Leopard is out so that I can get a handle on objective-c 2.0 and all the new cocoa libraries that will be in it.

Now, if I could just find a cheap WebObjects class here in town...