Category Archives: iPhone

An MVC4, iOS And Android App With ServiceStack, Xamarin and C#

A bit late getting this out, but I published a new course for Pluralsight.

An MVC4, iOS And Android App With ServiceStack, Xamarin and C#

This course was really fun to create.  I got to use several of my favorite technologies.

2013 08 19 16 52 05 thumb An MVC4, iOS And Android App With ServiceStack, Xamarin and C#

Here is the course description:

It can be very difficult to build a cross platform application that will work on the web as well as popular mobile platforms like Android and iOS.

In this course, I’ll take you through the complete process of creating an application that works on each of the platforms and uses a REST based backend API to share data and business logic—all using C#.

We’ll start off this course by learning how to build a REST based API using the popular open source framework ServiceStack. I’ll show you how easy it is to get ServiceStack set up and even how to store data for the API using a Redis database.

Next, I’ll show you how to create an ASP.NET MVC 4 application that uses the REST service we built to display it’s data and implement it’s logic. We’ll learn how to use JQuery to make AJAX calls to a REST based API from within our MVC 4 application.

Then, we’ll learn how we can use C# and the .NET framework to build an Android application using the Xamarin tools. We’ll use the same REST API, we created earlier and build a real native Android application that is able to consume that API for implementing its logic and displaying data.

Finally, I’ll show you how to do the same thing for an iOS application. We’ll again use C# to build a real native iOS application with the Xamarin tools and learn how to consume REST based web services from iOS.

So, if you are a C# developer and don’t want to have to learn several other programming languages to build cross platform applications; you’ll definitely want to check out this course. By the end of this course, you’ll have the skills you need to be able to implement an end-to-end cross platform solution complete with a REST based API backend all in C#.

Introduction to MonoGame

I’ve been playing around quite a bit with MonoGame lately and thought I would take some time to write a bit about it and talk about how to get started.

I’m also currently working on a Pluralsight course on cross platform development with MonoGame.

monogamelogo100x100 thumb Introduction to MonoGame

What is MonoGame?

Well, if you are familiar with XNA, then you already know what MonoGame is.

If you are not familiar with XNA though, it is basically a game development framework that allows for creating games quickly without having to write all that repetitious code that all games need.

Basically it makes creating games more about the game and less about the technical details.

The only problem with XNA is that it only really works for Windows, XBox360 and Windows Phone 7.  If you want to create a game on Android and iOS, you can’t use XNA.

This is where MonoGame comes in.  MonoGame is an open source port of the XNA framework that can run on many more platforms that Microsoft’s XNA.

Great, so what does this actually mean?

Well, if you are interested in game development, especially if you are interested in game development for the most popular platforms today, MonoGame might be able to help you to write pretty close to the same exact code and have it work on Android, iOS, Windows 7, Windows 8, Windows Phone 7, MacOS, XBox 360, Linux and the new Playstation console.

That is pretty awesome!  Especially if you are trying to monetize your effort.

In my mind MonoGame helps overcome two huge barriers to getting into game development.

  1. Difficulty of monetizing the effort.  By allowing the same code to be shared on most platforms, a game developer can get paid for their effort in multiple marketplaces.
  2. Not knowing where to get started.  The XNA API is so simple to use that you can get a simple game, like a Pong clone for example, up and running in about a couple of hours.

Also, because MonoGame is basically just XNA, you can find a whole host of resources on how to develop a game using the platform.

In my upcoming Pluralsight course, I show how to create a Pong clone on Windows and then we get that game up and running on Android, iOS and Windows Phone 7, with minimal changes.

dgun 853 50 games pr h thumb Introduction to MonoGame

Getting started

It can be a bit challenging to find good information to get started in each platform using MonoGame, but the basics are located on the Github page.

For the Windows tutorial there, you can use Visual Studio instead and use the MonoGame installer.

For each platform things area slightly different, but really not all that hard.  If you want to have your game run in Android and iOS, you’ll need Mono for Android and MonoTouch respectively.

For Android development, you can use Visual Studio as long as you have Mono for Android installed and all you really need to do is link your files from your Windows project and create a small bit of startup code in an Android Activity to start the game.

For iOS development, you will need to use MonoDevelop, which is packaged with the install of MonoTouch.  MonoTouch itself uses XCode and the iPhone SDK, so you have a bit more installing to do there, but the idea is pretty much the same.  One you have MonoTouch running on your Mac, you can link over the files from your Windows project, add a small bit of startup code, and you are up and running.  (You’ll also need to download the actual MonoGame source code to add to your project, since there isn’t an installer for Mac currently.)

Xamarin also has a seminar they did on MonoGame to help you get started.

True cross platform development, finally

At least for game developers.  For other applications in the mobile space, there are some solutions that help you share your code, but nothing that really allows you to have near 100% portability without a big sacrifice.

I was pretty amazed the first time my game just ran on my Android and iOS devices with virtually no changes.

I’d definitely encourage you to check out MonoGame and stay tuned for my Pluralsight video on the topic, where I will go through all the details of creating a game and getting it running on most of the major platforms.

MonoTouch

I’ve been so busy lately that I have neglected to write about a great platform for developing iOS applications called “MonoTouch.”

I recently released a new course on MonoTouch at Pluralsight.

I wanted to take a bit of time here to talk about MonoTouch and to tell you why you should be using it instead of developing iOS applications in Objective-C

text monotouch thumb MonoTouch

Flipping directions

gophoto 0197 scanned image 00363 thumb MonoTouch

When I first started developing with iOS, I firmly believed that the job should be done using the tools that Apple provided.

I still think it is a very good idea to learn Objective-C and how to develop an iOS application using Objective-C and XCode.

But I am convinced now that overall MonoTouch is the way to go.

Objective-C is a decent language, but it has a fairly steep learning curve for a C# or Java developer.  XCode, the IDE for developing iOS applications, is a decent IDE, but it is not nearly as powerful as MonoDevelop or Visual Studio.

The reality of the situation is that Apple’s development platform is still back in 1990.  Even though there have been some changes and growth, I firmly believe now that Objective-C and the underlying technology cannot ever catch up to .NET or Java.

I don’t say this lightly.  As I said, before I developed a fairly large application in Objective-C.  I authored a Pluralsight course on iOS development with Objective-C.  I was pretty convinced this was the way to go until I gave MonoTouch a try.

An unfair test

I really gave MonoTouch an unfair test, but it passed anyway.  I set out to learn, configure, build a MonoTouch application, and deploy it to the Apple App Store in 1 weekend.

I figured if MonoTouch could pass this test then I would immediately save more than the $400 cost for the software since the next application I was going to build was going to probably take at least a week worth of time to build in Objective-C.

MonoTouch easily passed my test and really exceeded my expectations.

The main advantage

By and far the main advantage in using MonoTouch is the language.

C#’s ability to wire up events through event handlers and delegates makes working with iOS so much easier.

There are many situations in iOS where you have to create a special class to act as a delegate for providing behavior for various iOS controls and classes.  In C#, many of these delegate classes can be replaced by a C# delegate or lambda expression.

Another really painful situation in Objective-C is memory management.  If you aren’t used to tracking memory usage it takes a bit to get adjusted to it in Objective-C.  Sure, it really isn’t that hard, but once I started working with C# to build my iOS application, I realized how much faster I could fly through the code without having to even think about it.  (The newer version of Objective-C has somewhat built in memory management, but it is not a true garbage collection implementation.)

Along with C#, you get the full power of the .NET framework.  Almost all of the base class libraries from .NET are available in MonoTouch.  (You basically have the silverlight .NET profile.)

This really comes in handy in 3 main areas:

  • Working with XML
  • Working with databases
  • Calling web services

If you try to do these things in Objective-C, it is possible, but it will hurt like hell.

Give it a shot

If you are interested in developing iOS applications and you haven’t tried MonoTouch, go give it a try.  Trust me, it is worth the effort.  One of the big factors that had me developing Android applications and shying away from iOS was the hurdle of trying to learn and work with Objective-C.

MonoTouch lets you reuse your C# skills without any extra overhead, since the application is compiled down to native ARM assembly code.

If you don’t know where to get started or want to learn a little bit more about MonoTouch, feel free to check out my course on Pluralsight.

Kudos to the Xamarin team for building such a great product!

(BTW, that photo is me flipping.  Actually it is a thing I used to call “throwing myself at the ground for dramatic effect.”)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

PaceMaker for iPhone Released

Earlier this year I announced the release of an app I had been working on for Android called PaceMaker.

Finally, I have succeeded in porting the application over to iPhone and it was definitely much harder than I had anticipated.

But I am glad to announce that as of today you can find PaceMaker for iPhone in the Apple App Store.

If you don’t know what PaceMaker is, you can read about it in my original post above or in the description in the app store, but to sum it up briefly, it helps you run at a desired pace by telling you to speed up or slow down when you are running too fast or too slow.

default2x thumb PaceMaker for iPhone Released

A unique perspective

Having originally written the application and then porting it over to iPhone gives me a kind of unique perspective on mobile development platforms.

Although it was a bit painful at times to basically recreate the same thing I already spent so much time and energy creating, I was able to very realistically contrast the two development platforms in many areas.

One of the major pain points I experienced was in documentation.  Google’s documentation on the Android platform is sometimes lacking, but is much more complete and descriptive than Apple’s iOS documentation.

I am still quite a bit torn on which platform I like more and which platform I think will win out in the end.  I do believe that if Apple improved their developer tools and moved to a new, more modern development language, that they would have a distinct advantage.

It seems to me though that whoever integrates the best across multiple devices and gets the highest quality applications built for their platform will be the winner.  iCloud could be a huge step in that direction for Apple.

Sharing the knowledge

I’ve just talked with my curriculum director at Pluralsight and I will be doing a beginning iPhone development for .NET developers course just like the Android Development for .NET Developers course I did earlier this year.

I’m pretty excited to do this because I am going to try and draw some major parallels between the two platforms and also from the .NET perspective.

I hope to create the course just like the Android one, where we will step by step create an application from scratch and then publish it to the Apple App Store.

Look for that in the next few months on Pluralsight.net.

Dailymile.com integration

Also included with this release for iPhone and Android is Dailymile.com integration.  I think this feature is pretty cool!  So I am really excited about it!

Dailymile.com is basically a social site for runners and cyclists.  It is basically a Facebook for runners.

I have added a feature to the Android and iPhone versions of PaceMaker to allow you to post your run details, including the GPX map of your run, up to the Dailymile.com server on your wall.

So when you go for a run you can capture all the information from your run and see it on Dailymile.com.

This was quite a pain to implement as I had to implement OAuth2 authentication in both platforms and integrate with a REST API.  But what a great learning experience!

Anyway, if you are a runner out there and you get PaceMaker, feel free to send me an email or drop me a comment.  I am always looking for feedback so I can improve the app.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Objective-C Here I Come!

Have I blabbed enough about the PaceMaker app I released for Android yet?

First month of sales are over, and it was much better than I had expected.  About 75 purchases in the first 30 days.  Not a huge amount, but that is almost with no advertising, most people who found the app found it in the market.

So what is the next step for PaceMaker?

Well, with the iPhone coming to Verizon this month, I think it is pretty obvious that it is time for the iPhone version.

Only problem is…

I know nothing about iPhone development!

Well I didn’t last week, but I am slowly learning.

iphone thumb Objective C Here I Come!

I bought my first Mac ever last week, a MacBook Air.

I have to say, the operating system on Macs has come a long way since I last used one.  (Did I mention I also don’t even know how to properly run a Mac?  But I know Unix, so I should be ok.)

I feel like the Mac interface is so much more polished and uniform than Windows, but it is pretty scary inside when you consider all the low level C and Objective C code.

Then again you have to consider that the wonderful .NET CLR is written right on top of a really crusty win32 API layer which is a bunch of scary C code that is about 20 years old.

So I am setting out on a brave new quest to learn Mac, iPhone and Objective-C and somehow port my application over to the platform.

Objective-C is kind of like an alternate universe

I was trying to think how I would describe Objective-C and here is what I came up with:

Objective-C is like one of those movies where there is an alternate universe where the same people exist as in this universe, but in some areas their technology is really advanced, but in others it’s really ancient.  Like a bunch of people flying around in flying cars, but their weapons are still bows and arrows.

I used to be a C++ programmer, so not too many things scare me, but some of the magical constructs in Objective-C are very frightening indeed.

I was just reading about a strange construct today that allow you to basically create the equivalent of a C# interface, but in Objective-C it is called a “Protocol.”  This seems fine and normal until I read the paragraph that says you can define some of the methods as “Optional.”  What?

Let me put it in C# terms so you can understand it.  In C# it would look like this:

public interface ILovePuppies
{
   private void HugThem();
   private void SqueezeThem();

   perhaps Corpse KillThem(); // Implement this one
                              //only if you feel like it.

}

This is not a joke.  I still can’t quite figure out what this is for, but it is kind of interesting.

Another thing I found interesting is Objective-C has this thing called a “Selector.”  It is not a function pointer, it is a variable that references the name of a method.

How is this different than a function pointer?

It is actually the name of the method being referenced.  So if you have a class Dog that has a method “Wag” and you have a class WildGuesser who has a method “Wag”, passing them the “Wag” selector will cause very different results.  How bizarre.

It’s weird to get sucked into the Mac world

It’s actually kind of funny.  Here were all us Java and C# programmers off basically doing the same thing; creating our interfaces and arguing about dependency injection and mocking our unit tests and these Mac geeks with their bow ties and designer jeans were going a totally different direction.

It was only by random chance that our two parallel universes should violently collide.  The iPhone came out and suddenly all these strange “Mac boys” were teaching us this new old language and reminding us to free up own memory again.

FOR GOD’S SAKE I JUST IMPORTED A C HEADER FILE FOR THE FIRST TIME IN 10 YEARS!  THIS IS CRAZY!

But, I have to admit it is actually kind of fun.

Sometimes a change of pace is refreshing

I don’t mean my harsh language to be derogatory towards you Mac heads out there.  You know you are cool, your boy Steve is leading this century’s computing revolution.

I honestly mean that.  Good job guys, you may just take over the world.

I’m actually enjoying this experience and beginning to think that if I come out alive, I will have gained some very valuable insights into programming in C# and Java.  It is good sometimes to view something from a totally completely different perspective.

Who knows maybe I’ll get to write that Objective-C vs Java vs C# post I’ve been dreaming of.

But what about…

MonoTouch?

Meh.  If I am going to program for a platform, I am going to program for that platform.  I’m not going to half learn how to program for the iPhone and learn on the C# crutch.  I didn’t do that for Android and I’m not going to do it for iPhone either.

Why?

Because I am stubborn and cranky?  Partially, but I actually have a few sensible reasons also:

  1. MonoDroid and MonoTouch both implement another layer over the phone’s framework.  Adding this additional layer makes it harder to do low level stuff, and with something as low level as a phone, doing low level stuff is often important.
  2. You are still using the underlying framework for either Android or iPhone.  It is not like using C# code behind the scenes allows you to write a Silverlight UI that you can use on any of the mobile platforms.  You still have to learn the entire phone development framework, which dovetails into point three…
  3. It is much easier to get help and find resources for raw Android or iPhone development than for MonoX development.  Not trying to bash the Mono projects here, but most of mobile programming is spent googling for how to do things.  By sticking with C# you are really limiting yourself in terms of finding answers.
  4. Change and learning different things is good.  I’m not sure you can fully appreciate the design of a framework or platform unless you develop against it the way it was designed.  I could be wrong, but I think there is a potential “lost in translation” problem in using C# on the iPhone or Android platforms.

After I learn iPhone development, I might try MonoTouch and see if it makes my life easier, but I need a good baseline first.

Well, I’m off on my journey.  Going to head on to the back of the wardrobe in the “Spare-Oom.”  I have to meet Mr. Tumnus, we are having tea with Mr. Wozniak and Mr. Jobs.

mrtumnus thumb Objective C Here I Come!

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.