Colin Eberhardt reviews iOS Programming for .NET Developers

A fellow by the name of Colin Eberhardt in the U.K. has reviewed my book that teaches .NET devs how to write iPhone and iPad apps. Colin’s review of iOS Programming for .NET Developers is circumspect and has reasonable critiques. He summarizes the review with a few sentences that made me sigh with relief, because they confirm that I succeeded in writing a book that .NET developers gain real value by reading. Colin writes…

“What makes this book unique is that it helps you leverage your existing skills in a way that you would find very hard to do by yourself. The similarities between the two environments are far from obvious, but I am happy to say that there are a great many! I feel that reading this book has increased my comprehension of iOS application development far quicker than a standard text on learning iOS would have allowed.”

Visit Book Review: iOS Programming for .NET Developers for the full review.

Thanks for the review, Colin!

My book about iOS programming is now available in iBooks

Well, that was fast! Less than forty-eight hours after I submitted iOS Programming for .NET Developers to Apple’s iBookstore, it got approved and is now available for sale worldwide. I heard of some books taking weeks or even months to get approved, so I must have some special mojo working in my favor…

If you’re a .NET developer looking to learn iOS, and want to read about it on your iPad or iPhone, visit http://itunes.apple.com/book/isbn9780985784508

Visit the book’s homepage to learn more about it, and the various formats it is available in.

My book about iOS programming is now available!

Over the past several months I have been working like a madman on a book that explains iOS to .NET developers. I’m proud to announce that iOS Programming for .NET Developers has been published! Like my last book, Advanced MVVM, this book is self-published. It is currently available in paperback and Kindle editions, but stay tuned for iBooks and Nook editions coming soon.

For more information, and a free sample, visit http://iosfordotnetdevs.com

Big announcement on my iOS blog

I made a big announcement on my iOS blog, which I think many .NET developers might want to know about. To find out what’s up, head over to iJoshSmith and take a look at this.

The Hello World of genetic algorithms

I just published an article on my iJoshSmith blog that explains how a simple genetic algorithm works. The article is titled “Simple Genetic Algorithm in Objective-C” and can be found here…

http://ijoshsmith.com/2012/04/08/simple-genetic-algorithm-in-objective-c/

If you’re interested in expanding your mind today in some strange new ways, go check it out!

Does anyone actually care about WinRT?

If ever there was a blog post that ensures I will not be awarded the Microsoft MVP award again, this is the one. Not that I care…

Windows 8 was announced and distributed as a developer preview back in September of 2011. There was a short burst of excitement in the blogosphere about WinRT, which is the supposed replacement for the Win32 platform.

That fizzled out pretty quickly.

Recently Microsoft released the Windows 8 consumer preview. The most notable responses to this have been an overwhelming dislike for the new look and feel of Visual Studio, and a series of criticisms of Windows 8 for its usability by the average PC user (such as this video).

That hasn’t fizzled out yet.

Even firmly entrenched Microsoft developers, such as many of us in the XAML Disciples (formerly known as the WPF Disciples), have expressed a lack of interest in learning WinRT. See this Disciples thread which veered away from its original topic (an announcement of some WinRT feature) into a series of thought-provoking explanations of why people are not bothering to get into WinRT. The general consensus on that thread is that if you lack confidence in the prospects of Windows 8 and, by extension WinRT, why bother learning it? Why not spend your time and energy learning more successful and in-demand technologies, whose futures look bright and promising?

I am not saying that Windows 8 will fail spectacularly, nor am I saying it won’t. All that I can say with certainty is that the .NET developer community is decidedly not flocking to it, and that should be very concerning for Microsoft.

I think that WPF is the safest bet these days for Windows desktop developers. I can’t see enterprise software leaving the Windows desktop any time soon, and I certainly can’t see it migrating en masse to Metro for the PC. I think that we will start seeing more and more enterprise software being written for tablets, in particular the iPad.

If you have a compelling argument that proves me wrong, I’m all ears (well, all eyes, since this is a blog…).

Becoming an iOS Developer

This blog post describes my experience of learning how to write iOS software, after having spent many years exclusively in the world of .NET development. It provides warnings, suggestions, and tips for others who are interested in learning iOS development. The post ends with a qualitative comparison of programming in WPF and iOS.

[UPDATE: July 17, 2012] I self-published a book that explains iOS to .NET devs. It is titled iOS Programming for .NET Developers. Learn more about it here http://iosfordotnetdevs.com

Why iOS

About a year and a half ago, I realized the world had changed. Apple was dominating the mobile market, a computing space rapidly gaining importance and relevance in the business world. Microsoft wasn’t even close to catching up. In fact, they aren’t even close yet, as far as I can tell.

Despite my years of investment in becoming a Windows desktop software developer, and my four years as a Microsoft MVP, I decided to branch out into totally foreign territory. I bought a MacBook Pro, a heap of books for iOS noobs, and started from scratch. This was not an easy or comfortable decision, by any means, but it was the logical thing to do. So, I did it.

What I have accomplished so far

So far in my voyage as an iOS developer I have worked on three apps successfully launched and used in production. Two of them are iPhone apps that I wrote and published to the iTunes App Store: Master WPF and Two Letters.

Where I gained the most experience with iOS was working as Technical Lead on an iPad project for Trane. The app assists salespeople in selling residential HVAC systems to homeowners. You can watch a brief video about the app on my employer’s Web site here (scroll down the page a bit to watch the video).

Words of warning

I have had quite a few people ask me how I went about becoming a competent iOS programmer, usually because they want to become one, too. I warn that it will take a considerable amount of time, effort, and patience to get over the learning curve. If you think that going from WinForms to WPF requires a major mental adjustment, you ain’t seen nothin’ yet.

When you move to iOS, you will need to leave behind most of what you know about UI programming from the .NET world. Fundamental things like object-oriented programming, virtual methods, properties, and loops are still relevant, and having knowledge of those things is essential. But knowledge alone won’t be enough to get you up and writing an iOS app.

You will need to re-map your existing concepts and knowledge onto a new programming language, UI platform, APIs, operating system, IDE, keyboard shortcuts, debugger, error messages, etc. This takes time, and can be frustrating for people who are accustomed to being competent and productive in another environment.

Lastly, if you are a closed-minded person, don’t even bother. I found that switching from .NET to iOS programming required me to learn a very different way to think about writing software. I’m not saying it’s better or worse than what I already knew, just different. If you can’t admit that your technology of choice isn’t superior to all others, just stick with what you know and avoid the frustration. Successful, productive learning requires acceptance and humility.

The Eightfold Path

Once you decide to take the plunge into iOS programming, it might help to have a roadmap to follow. What follows is a high-level overview of the eight things I suggest doing and learning, to become competent at iOS development. Some of these steps overlap each other, but the overall progression of topics is the key takeaway.

Step 1: Pay Apple
You need to buy an Apple computer, an iDevice (iPhone, iPad, iPod Touch), and pay $99 per year to be in the iOS Developer program. Joining the iOS Developer program is necessary so that you can run your apps on your iDevice. It also grants you access to a large number of useful developer resources on Apple’s site.

Step 2: Objective-C
If you were to move to a foreign country, the first thing you would probably want to do is learn the native language. The same applies here. Objective-C is the language of iOS. There are others, such as Objective-C++, but almost all iOS developers use Objective-C.

I’m sure there are many good books out there that teach Obj-C, but I read and enjoyed “Learn Objective-C for the Mac”.

Step 3: Xcode
Xcode is the Visual Studio for iOS developers. Apple gives Xcode away for free, even if you don’t join the iOS Developer program you can get it. Xcode is where you write your code, design your screens, debug issues, configure provisioning files, analyze memory leaks, etc. You will spend a lot of time in Xcode, so it pays to spend some time learning how to use it.

Check out the Pragmatic Bookshelf screencasts about Xcode here.

Step 4: Memory Management
iOS does not have a garbage collector. Instead, it provides you with a very simple API that implements reference counting. This means that an object is immediately removed from memory when all “owners” of that object relinquish ownership. Before iOS 5 you needed to write all of that memory management code into your apps. Now, with iOS 5, there is a wonderful new compiler service called Automatic Reference Counting (ARC) which inserts the memory management code for you.

ARC is awesome, but I highly suggest that you don’t use it until you can manage memory yourself. In other words, don’t rely on ARC until you understand what it’s doing. There are many reasons for this; one of the most practical of which is the fact that most iOS sample code is pre-ARC.

My memory management bible, which I returned to many times until I finally “got it,” can be found here. You’ll probably need to read more in-depth explanations of memory management before that blog post will make sense and be useful.

Step 5: Interface Builder
Interface Builder, normally referred to as IB, is an excellent tool that allows you to build user interfaces via drag-and-drop. Before Xcode 4 came out, IB was a separate stand-alone tool that was loosely integrated with Xcode. Starting in Xcode 4 it was moved into Xcode, enabling a more familiar design-time experience for .NET developers.

IB rocks. It’s so good that I have never once needed to look at the XML it generates to serialize UIs. Imagine using Cider or Expression Blend and never needing to look at and edit XAML by hand!

Step 6: CocoaTouch
CocoaTouch is to iOS as WPF is to Windows. It’s what you use to create beautiful user interfaces that do real work. CocoaTouch is a high level library, built on top of several lower level libraries, such as Core Graphics and Foundation. It is a library with many frameworks and APIs, ranging from touchable Buttons, to customizable maps, to video players, to device-level notifications. It also has deep and rich support for the Model-View-Controller design pattern baked in, including a full navigation system based on view controllers.

The best book I know of for learning CocoaTouch is the one from the Big Nerd Ranch.

Step 7: Core Data
Once you are comfortable with the language, IDE, and UI platform there is still one more topic you need to wrap your head around. It’s called Core Data. It’s a framework, by Apple, that simplifies working with an application’s data. It does a lot of things for you, including mapping entity classes to SQLite tables (or other backing stores) and translating high-level queries into low-level queries and executing them for you.

The book that I read to learn Core Data is called “Pro Core Data for iOS”. Apple also provides a lot of great documentation about Core Data.

Step 8: Publish Apps
Don’t just write apps. Publish them to the App Store. Apple can reject your app, and prevent it from being available in their App Store, for many reasons. Professional iOS developers need to know how to create iOS software that will be approved by Apple. Plus, these days, companies looking for iOS developers require that you can demonstrate your skills by having published apps. If you don’t have apps in the App Store, you’ll be at a huge disadvantage when applying for iOS jobs.

Apple recently published their own roadmap for getting started with iOS development here. I haven’t checked it out in depth, but it is getting rave reviews so far.

Comparing Apples and Microsofts

The last topic I would like to touch on, which is also the most difficult to communicate, is a qualitative comparison of WPF and iOS programming. This is inevitably subjective and circumstantial. I hope it conveys an impression of what one can expect when developing iOS software.

Apple expects developers to be smarter than Microsoft does. Microsoft works hard to ensure that programming technologies are usable by as broad a range of people as possible. Their tooling and documentation assume you aren’t quite sure what you’re doing. Apple, on the other hand, is not nearly as helpful and pandering. I’m not saying either approach is intrinsically better or worse, but as a reasonably intelligent developer I prefer not being handled with kid gloves.

Visual Studio has way better visual debugging tools than Xcode. Apple has been improving their debugging tools in each release of Xcode, but the debugging experience for a WPF developer exceeds that of an iOS developer any day of the week.

Objective-C is very weird at first. It takes some getting used to. Once you become accustomed to the odd-looking syntax, however, it’s actually rather simple and pleasant to work with. Compared to C# it is much less feature-rich, but that hasn’t been a problem for me. I have enjoyed writing Obj-C quite a bit.

iOS apps run lightning fast. Not having the overhead of a managed runtime environment, a garbage collector, code-access security, etc. really helps keep iOS apps fast and easy on the battery. Remember, when writing mobile software, battery is king and speed is a close second. Objective-C is basically plain old C with some extra keywords that support object-orientation, and a very lightweight runtime also written in C. It’s really, really fast.

In iOS you don’t decorate user interfaces with renderings created and styled in markup. Instead, you use bitmap images (typically, PNG images) or, in more demanding scenarios, draw to the screen in code. Since iOS apps exist in a fixed size window, you generally don’t need to worry as much about having resizable graphics, so using images is easier, assuming you have a way to get the images in the first place.

The primary design pattern used for structuring UIs is Model-View-Controller (MVC), not Model-View-ViewModel (MVVM) like in the WPF and Silverlight worlds. As I mentioned above, CocoaTouch has full support for MVC baked in. It’s quite nice to have that in the platform, because it’s less code you need to write and maintain. In my Master WPF app, I actually used ViewModels in one screen, but that’s a topic for another post.

Abort()

This blog post was not intended to persuade or dissuade you to or from iOS. I don’t care what kind of programming you decide to do. Hopefully this has given you some insight into what it has been like for a .NET guy to try out something new and different. Maybe you learned a thing or two along the way.

Have a great day!

Master WPF on your iPhone

After being obsessed with WPF for so many years, I can’t just forget about it. Even though my focus is now on iOS development, I still think that WPF is an awesome platform. That’s why I wrote an iPhone app named Master WPF. It contains 500 questions, spread across 28 topics, that I painstakingly wrote, organized, and proofread until my eyes bled. The questions will help any WPF developer sharpen their skills.

It’s for WPF noobs, gurus, and everyone in between.

Master WPF on your iPhone or iPod Touch

You can download Master WPF for free on your iPhone or iPod Touch, running iOS 5 or greater. The app comes with 15 free questions so that you can try it out. If you decide that you want to master WPF with my app, you can make a small in-app purchase to unlock all 500 questions.

Think of it as a donation to a recovering WPF addict.

Screenshots of Master WPF

For more info about Master WPF, please check out http://masterwpf.com

WinRT is your friend

Microsoft’s BUILD conference of 2011 is over, but the shockwave it unleashed has barely even begun to materialize yet. The developer world is still scrambling to make sense out of what just happened. What they debuted at BUILD marks the end of one era, and the beginning of a new one. Good old Win32, that layer of abstraction between the Windows kernel and your desktop applications, which first shipped with Windows NT in 1993, is no longer the only way to build Windows apps. Windows 8 will ship with another layer of abstraction between the Windows kernel and your apps (technically, your “Metro” style apps) called the Windows Run Time, also known as WinRT. Windows 8 will support both Win32 and WinRT apps.

“So what?” you might be thinking. When stated as a technical detail, the inclusion of WinRT as part of Windows 8 might seem like a mundane matter not worth much attention. However, this seemingly minor detail represents a significant change in the Windows operating system, and in Microsoft’s business direction and vision of itself. WinRT was designed to support a whole new style of software application and human interaction model. It was built so that the operating system can run on x86 and x64 processors, like in your desktop or laptop, but also it supports running on the ARM processors used in mobile devices.

The user interface seen in the Developer Preview of Windows 8, released at BUILD, is a combination of Windows 7 and something totally new for Windows, often referred to as the “Metro” style.

The standard/classic Windows desktop that we all are accustomed to is still available, powered by good old Win32, but it is not what shows up on your monitor when you first boot Windows. When you first boot up, the WinRT-powered Metro screen fills your monitor(s). For me, at this early stage in trying out an early build of Windows 8, it feels like Windows has developed a multiple personality disorder. It can’t decide if it is an office worker or a high school kid. Then again, having this dual modality is not necessarily a bad thing, considering how most people use computers for work and entertainment in their lives, which are very different ways to use a computing device. I guess if Microsoft wants to remain relevant in a world increasingly dominated by iPads, this makes sense.

There are tons of fascinating technical details about WinRT that I’d love to dive into, such as how it was written in C++ but is “projected” into three separate stacks (XAML + C#/VB.NET, HTML5+JavaScript, XAML + C++), how it supports a subset of the .NET 4.5 framework, the fact that any method expected to take at least 50 milliseconds to complete was implemented async, and so much more. But there’s plenty of time to get into that, and other bloggers have already touched on a lot of the good bits. What I’m really happy to see in WinRT is the fact that it seems to be very, very heavily influenced by WPF and Silverlight. In fact, at BUILD one of the demos was converting a Silverlight project to WinRT just by changing a few namespaces and adding the occasional #if. Most of the skills that WPF and Silverlight devs have acquired over the years will be relevant and useful in the years ahead, hence the title of this blog post.

Many people have asked me why I decided to get into iOS development. The answer is, mostly, because as a Windows developer I felt that the world was passing me by. Things felt stagnant in the Microsoft world, while exciting advancements were happening all around in other technologies, especially the stuff coming out of Apple. Couple that with an unquenchable hunger to learn, and it only made sense to move on to greener pastures. But it looks like Microsoft might actually have something here, with WinRT. Only time will tell, but it’s exciting to see them try something bold and new (for them).

Thus far my experience with WinRT programming, which is obviously sparse considering the first preview build was just released, feels a hell of a lot like WPF or Silverlight programming. Windows itself basically has the next generation of WPF/SL built in, so to speak, and that is unspeakably exciting for me!

Some folks at Microsoft published this list of hardware that they use to run Windows 8 on touch-enabled systems. I read that list, did some research, then went out and invested in the ASUS EP121 slate. Now my WinRT dev rig looks like this:

That’s right, a tiny little slate computer is powerful enough to run the latest version of Windows, Visual Studio 11, supports multi-touch input, a keyboard, a mouse, and a 27″ external monitor…all at lightning speed. I am just amazed.

To install the operating system I needed to download the Developer Preview (which comes with Visual Studio Express pre-installed) and then followed the steps on Scott Hanselman’s blog post that shows how to put the ISO file onto a 16 GB USB thumb drive so that I could boot from that on my slate. I didn’t bother installing it to a VHD, as Hanselman explains, because I have a dedicated machine just for Windows 8, but it seems like many people are having success with virtualizing Win8 on their machines.

Regardless of whether Windows 8 might be a success or not, I think it is something that should be investigated. It’s too significant to ignore.

Strange times in the world of Microsoft developers

Over the past few months there have been many odd announcements, rumors and convulsions coming out of Microsoft. It all started when Bob Muglia announced that their “strategy has shifted” toward HTML5, and Silverlight will not reign supreme forever. That one statement caused ripple effects that literally put some people out of work, caused projects to be put on hold or cancelled, and made many people in the IT world wonder…

The major concern for people who have invested years of time learning Silverlight, whether it is valid or not, is that they are about to become dinosaurs. For people focused on WPF this news was not as threatening or shocking because, well, WPF was not the new kid on the chopping block anymore. Silverlight was. Until now. Chop!

An awkward time passed, with lots of angst and nail biting in the development community. People who were glad to finally be done with the horrors of cross-browser compatibility and dealing with the latest breaking changes in their DOM abstraction library of choice soon realized that Silverlight was slipping through their fingers. Instead, a hot new technology meant to solve all the world’s woes was soon to plop into their hands: HTML5 and JavaScript. This does not bode well with people who are used to the luxurious and productive world of C#, .NET, and the full powers of Visual Studio 2010. The situation seemed grim, and there was a lot of confusion about the future of .NET and Silverlight. Certainly Microsoft must be planning to explain things more clearly, to put these fears they stirred up to rest.

Unfortunately that didn’t happen. Rather, the opposite happened. Microsoft gave the world a sneak preview of Windows 8 and touted the fact that you can build apps for it that have the Metro UI style using…HTML5 and JavaScript. That’s right, world. Suck on that for a while. In the future we will (should? must?) build desktop Windows apps with the crap that we were trying to get away from on the Web when moving to Silverlight. I’m sure there is a good reason for all this, but I must admit that seeing this go down makes me super-duper happy that I’ve been diving head first into iOS and Android programming. If the future of developing Windows apps means abandoning C# and the .NET Framework and instead using HTML5 and JavaScript, I’m out. See ya, Microsoft. Good luck with that.

Perhaps the world at large does not follow all of this nonsense as closely as the people who bother to blog about it do. I have heard from several friends in major U.S. cities, including New York and Boston, that there are many opportunities for experienced WPF and Silverlight developers. Brief searches on Dice.com confirmed this. The “real world” seems to have just recently (past year or two) wholeheartedly adopted WPF and Silverlight. I have noticed that it takes a long time for large organizations to adopt new technologies, so perhaps all of this handwringing is for naught. Unless you depend on cutting edge technologies for a living, there’s really nothing to be concerned about. But there is something else to be interested in…

Jupiter is the code name for some new UI programming platform that supposedly might be available in Windows 8. There is a lot of speculation and rumor on the Web about what exactly Jupiter is, and is not, but there have been no official announcements as of yet from Microsoft. I have heard tales of it being a replacement for WPF on Windows 8, using XAML (amidst rumors of the XAML team at Microsoft being disbanded), it supposedly is called DirectUI, and it supposedly will support being used with native C++. All I can say is “Cool!” and I hope that this Jupiter thing turns out to be awesome, but I don’t care much about it until I can fire up VS and kick the wheels.

Supposedly all will be revealed and clarified at the upcoming BUILD conference in 2011. I suspect BUILD will answer some questions and unleash a new wave of turmoil in the developer community. Regardless of how successful the Microsoft PR machine is at that conference, one thing is certain. These are strange times in the world of Microsoft developers.