MonoTouch is alive and doing well

Back in April 2010, Apple changed some rules that made it look like MonoTouch was seeing the last of its days. I documented it here. After all this time, it feels like its important now to write about the updates since then to MonoTouch.

The best news of all is that nothing really changed, after all: Apple is still accepting MonoTouch applications normally into the AppStore, including applications built specifically for iOS4, with things like backgrounds tasks. Here’s a list of some of the apps that have been accepted recently.

The platform also keeps improving. Several releases have been made since then, supporting every single functionality added Apple in the new OS. Improvements are also continuously made to the platform, and apps keep getting faster and faster with every release.

Finally, usage seems to be going up, with several books being released, several talks being done all around the world at user groups, and even the number of people hanging around in the IRC channel increasing daily.

I have just finished a new application for a client (I’ll write more about it soon), as well as released a new version of Cracklytics, my personal app (the new version is waiting approval).

For those of us (including me) that were a little worried about MonoTouch, it seems that now is the time to relax and enjoy the platform.

Is MonoTouch dead?

This post was originally posted on StackOverflow, but as many people follow my blog to read more about MonoTouch, I thought it would be nice to post my answer here. You can find my post on StackOverflow here.

3.3.2 An Application may not itself install or launch other executable code by any means, including

without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.

No interpreted code may be downloaded or used in an Application except for code that is interpreted and run

by Apple’s Documented APIs and built-in interpreter(s). http://adcdownload.apple.com/iphone/iphone_sdk_3.2__final/iphone_sdk_agreement.pdf

Most people here simply want to take Apple’s document by the word and say “yes, its banned”. Well, here’s my point of view: at this point, nobody really has any idea if MonoTouch is going to be banned or not, and I’ll explain why:

The Apple agreement version 3 (not the latest, the one before) clearly states that its illegal to use any other frameworks to develop applications other than the ones provided by Apple:

3.3.2 An Application may not itself install or launch other executable code by any means, includingwithout limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.No interpreted code may be downloaded or used in an Application except for code that is interpreted and runby Apple’s Documented APIs and built-in interpreter(s).

http://adcdownload.apple.com/iphone/iphone_sdk_3.2__final/iphone_sdk_agreement.pdf

Even though that’s the case (and was actually the case since 2.x, apple doesn’t have any problem accepting applications that do exactly that. For example, ALL EA games use Lua scripts, and lots and lots of people use external libraries that are not native to the iPhone. Even when the iPhone has those native APIs, Apple never had a problem accepting applications with different versions of it, like SQLite.

My point is that saying “YES, they’ll be banned” right now is simply WAAY too early. The only clear thing at this point is that Apple **could** in fact use that to ban apps. Just like they accept Apps today that are against some of their rules, they’ll probably continuing doing so.

There’s also the fact that are hundreds (or probably a few thousands?) of apps in the store currently running Mono, and Apple will need to accept updates for those apps. Major apps with millions of sales were created using Mono (and Lua), and I doubt they would refund every single user.

Lastly, Enterprise applications are deployed to iPhones without Apple’s approval, and that’s a big market that MonoTouch is on (I myself develop enterprise apps). There’s no way at this point that Apple could ban MonoTouch for those applications, and that will probably be enough to keep MonoTouch alive for a long time.

Cracklytics 2.0 is out!

Hi everybody,

After a few weeks of work, the new version of Cracklytics is finally out! There’s a lot of new functionality in it, besides lots of bug fixes!

To read more about the release, please take a look at the app site!, or just download it from the AppStore. If you like it, don’t forget to leave a review!

I’ll probably be blogging about many of the changes done to the app for performance and other things soon, so stay tuned!

Hello World using MonoTouch

At the MSDN Blogs, Shawn Burke has recently decided to do a comparison of the iPhone SDK and the Windows Phone 7 Series SDK (what a horrible, horrible name!) by writing a simple Hello World application and showing the difference between the two.

While I don’t think it’s really fair to compare a C-based platform with a .NET based one, Shawn’s point that the it takes a lot more code to write the same application is real. It’s also real to say that the iPhone SDK could run extremely well in a 400MHz processor three years ago, while the Microsoft will need a 1+Ghz processor and still isn’t on the market, but that’s a different conversation.

Anyway, I work daily with MonoTouch, a port of the Mono platform to the iPhone, and thought it would be a good idea to show how concise iPhone development can be when you write code on top of the platform. Here are the steps:

1. Open MonoDevelop, select File->New Solution->Type in name->click Forward->Click OK.
2. Double-click MainWindow.xib
3. In Interface Builder, drag and drop a UIViewController into the xib, and then a UIView inside the UIViewController
4. Drag and drop a UITextField, a UILabel and a UIButton into the UIView, and change the text on the controls accordingly.
5. Define three outlets in the AppDelegate class (for simplicity), and connect them to the UIViewController, UILabel and UITextField added previously.
   
   
6. Add and action to the AppDelegate called “OnButtonClicked” and connect to the TouchUpInside event of the button.
7. Control-S to save, Control-Q to close Interface Builder.
8. Back in MonoDevelop, open up Main.cs and inside the FinishedLaunching() method, add this line of code:
   window.AddSubview(ViewController.View);
9. Outside of the method, type “partial”, and select the OnButtonClicked option.
10. Finally, write the code to set the text:
    partial void OnButtonClicked (UIButton sender)
{
label.Text = String.Format("Hello {0}!", String.IsNullOrEmpty(textField.Text)?"World" : textField.Text);
}
11. You’re done! Press Command+Enter, and the application will run on the simulator.
    

You can take a look at the entire solution here. You won’t be able to open the solution in Visual Studio, but you can look at the files in any editor and see the code I wrote above. It even includes copy/paste! (yeah, low punch, I know).

So, at the end, how many lines of code have we written? 3 or 5, depending how you count. If I had written the code the same way as Shawn, it would be more like 7-8. So it’s more code than when using the Windows Phone SDK, right? Well, I would say wrong. Here’s why:

Although we used XML on the solution (the XIB file is XML afterall), we absolutely never touched the file at all. For all purposes, the code in that file doesn’t exist at all. I’ve been developing for 5 months using MonoTouch now, and I never had to open the XIB in anything other than Interface Builder.

So when Shawn mentions that he can write the entire thing in only 4 lines of code, (or even zero!) that’s not entirely true. You’ll be hand editing the XML directly daily, to the point of even writing untested, non-testable business logic in it (like Shawn did in his example). And that XML will have bugs in it (yes, it will). And if you’re going to do it, you better count those lines of code as well. In Shawn’s case that adds 15 lines and a totally different language developers will have to get used to.

Isn’t it funny how you never really hear objective-C users complain about their platform? The iPhone SDK is a really well developed API, and really simple to use to create applications. It’s different from Microsoft’s solution, but that doesn’t mean its bad (some would say its actually better just for that, I prefer to stay in the middle).

Before anybody says anything, yes, I used MonoTouch, and not Objective-C like the Shaw’s example. My opinion here is that the language doesn’t really matter: the framework does. What’s the problem if it takes 5 more lines of code in objective-C than C# to do something? I bet a lot of those obj-c developers can write those 5 lines a lot quicker than I do.

I love .NET, and I’ll likely be writing many apps in the WP7SSDK (worst acronym ever, I guess) in the future. From what I’ve seen so far, the platform sounds very interesting, and it’ll be great to reuse code from MonoTouch and just have to rewrite the view code for the new phone.

MonoTouch UIApplication and AppDelegate explained

When you create a new MonoTouch project, one of the first lines of code you see is the FinishedLauching() function, in the AppDelegate class. That’s also one of the first things to change when you’re following basically any tutorial. But what exactly is it? And why is it getting called?

When developing iPhone applications with MonoTouch, there’s always a lot of “magic” that happens behind the scenes; one of these is the AppDelegate class. Unlike most WinForms app, where all the events are always generated within your application, in the iPhone the OS generates a lot of notifications that get sent to the application. The AppDelegate object is one of the ways to receive those notifications from the OS (the other being the NSNotificationCenter). During the application startup, the iPhone OS deserializes the main NIB file (created from the MainWindow.xib file), which contains the UIApplication object and the UIApplicationDelegate object; you won’t need to create these objects, the framework takes care of that for you.

Every iPhone application contains one and only one UIApplication instance, which is a singleton and can be accessed via UIApplication.SharedApplication. Its main role is to handle the proper initialization of the application, and to maintain the list of Windows in the application (which contain all the UIViews objects). The UIApplication also helps routing URL requests and even takes care of things like the badge number displayed by the icon and orientation of the app. Anybody developing an iPhone store should consider taking a quick look at this class before releasing the app, to make sure all the settings are correct.

Together with the UIApplication instance, an UIApplicationDelegate is created. Its function is to receive the notifications from the OS that may affect the application. MonoTouch automatically creates a partial C# class called AppDelegate that inherits from the UIApplicationDelegate, which is kept in the Main.cs file. This is very handy, as every application should always implement at least 2 methods, also created automatically by MonoTouch: FinishedLaunching (UIApplication app, NSDictionary options) and OnActivated (UIApplication application). The default code created by MonoTouch can be seen below:

public partial class AppDelegate : UIApplicationDelegate
{

	public override bool FinishedLaunching (UIApplication app, NSDictionary options)
		{
			window.AddSubview (navigationController.View);
			window.MakeKeyAndVisible ();

			return true;
		}

		// This method is required in iPhoneOS 3.0
		public override void OnActivated (UIApplication application)
		{
		}
	}
}

Very important here is the FinishedLaunching method, where you should define the objects in your window, and return true. If you’re using Interface Builder, the UIWindow object will already be created (like above), so all you have to do is add subviews to it. Also, be careful about how much work you do on this method: the app will get killed by the OS if you take longer than a few seconds to return (5-6 in my experience, but I couldn’t find a documented number anywhere). So if you’re planning on loading data from the web, or opening a big database, make sure you do that in a separate thread.

There are several other methods in the UIApplicationDelegate class that you should seriously consider implementing:

• ReceiveMemoryWarning: which is called when the iPhone is running out of memory and you should release memory right away or your app will be killed
• WillTerminate: called after the user presses the Home button, gives you the opportunity to save the app state so that next time the user comes back the app looks like it was when it was closed. You’ll have to write all the logic to do this yourself, but this is essential for a good iPhone HIG “compliant” app.

The UIApplicationDelegate also handles Notifications, with the RegisteredForRemoteNotifications and the ReceivedRemoteNotification methods. To see a full list of methods in MonoDevelop, simply put the cursor after the closing statement of a class and type “override”. The full list of methods available will show up.

Paging controllers with MonoTouch

I have just pushed a new control into my open source collection of MonoTouch controls, called PagedViewController.

I created this control during the development of my new iPhone application, Cracklytics (available soon in the AppStore, recommended!) mainly to simplify the usage of the UIScrollView to make applications that use pagination, such as the Apple’s Weather app.

Usage of the control is quite simple. All you need to do is create a new object of type PagedViewController, and pass a data source to it, like below (executed from inside a UIViewController):

var pagedViewController = new PagedViewController{
	PagedViewDataSource = new TestPagesDataSource()
};
this.View.AddSubview(pagedViewController);

The most important part of the code is the actual implementation of the TestPagesDataSource, used above. The class works as a factory of UIViewControllers, much like a UITableViewDataSource is used by the UITableViewControllers. The class needs to implement the IPagedViewDataSource interface, like the sample implementation below:

public class TestPagesDataSource : IPagedViewDataSource {
	private List _colors = new List{
				UIColor.Blue,
				UIColor.Red,
				UIColor.Yellow,
				UIColor.Cyan
	};

	public int Pages {get {return 4;} }

	public UIViewController GetPage(int i){
		UIViewController c = new UIViewController();
		c.View.BackgroundColor = _colors[i];
		c.View.AddSubview(new UILabel{
				Text= "Swipe to change view",
				TextAlignment = UITextAlignment.Center,
				Frame = new RectangleF(0,0,320,100),
				BackgroundColor = UIColor.Clear
		});
		return c;
	}

	public void Reload(){}
}

The most important methods there are the Pages counter and the GetPage(int i), which should return a new UIViewController. The Reload() method is called automatically when the Reload() method of the PagedViewController is called; you can use this to, for example, load more data from the web, or from a local database.

The control currently works fine if you don’t have lots of pages, probably a few dozen, because the controller automatically loads all the pages during startup. If you have more than that, though, the pages would end up using too much memory, so you would have to modify the controller so that only the current page, as well as the previous and the next pages are loaded.

To see this control working, download the entire solution from github.

Notes from an (officially new) iPhone developer

I have just finished uploading a new application to the App Store. While it’s waiting for Apple’s approval (hopefully that will happen soon), I decided to write down some information about how the application was developed. This won’t be a technical guide or a how-to; rather, these are some random thoughts that new developers to this platform can probably learn from.

Step 1 – Get the idea right

This is the first and the most important step: make sure your idea is rock solid, and that it’ll work well for the iPhone. The iPhone is an extremely constrained platform (small screen, no keyboard, no mouse, etc), so you need to make sure your application is doing the perfect thing for your user. Back in 2008, I attended an Apple Developer Day specifically for the iPhone, and the one thing I took out of that presentation were the ingredients to create a good iPhone app. You can watch that video here – Seven Qualities of Successfull iPhone Apps. Always remember that iPhone apps are not supposed to do everything, and that 90% of the ideas you’ll have won’t fit well in the Phone.

Step 2 – Go back to paper and pencil

Now its time to put write your idea down, and design how your app will look. There are some online tools available to do that, but nothing is easier and simpler than a sketch book and a pencil. I always use Erik Loehelm’s great template, and recommend everybody else to do so.

Iterate over your design multiple times. I mean, really, multiple times. Think about the position of every element, and how you could remove that element in the first place. The iPhone is very different from a normal page or desktop app, so saving space and finding innovative ways of displaying data is fundamental.

Step 3 – Do it!

Not much to say here, other than that this is hard and will take a long time to be done. Choose your tools wisely, based on what you know and what you want to learn, and just do it. Many times during development you’ll feel the urge to add new features to the app; many new features will be only a couple of lines away from you. Resist the temptation! Focus on your original wireframes, and getting that done.

Technically speaking, make sure you do things the right way: web calls should always be done asynchronously, UI elements should always be preloaded, memory should be freed as quick as possible. Get very used to write threaded code, and be extra careful with memory leaks. The iPhone is a fast computer in many ways, but you’ll often be amazed at how it is slow at some things.

Step 4 – Test it, and test it again!

Be very serious about testing. Nothing is worse than spending your users time by having your app crash every once in a while. Make sure you test special conditions: network on/off, rotating the app, different versions of the iPhone OS, multiple touches at the same time, and so on. Make sure you keep lists of all the bugs you have found. In my case, I like to use 37Signal’s Backpack application for that, but it really doesn’t matter which tool you use.

Make sure you always test in the iPhone, not on the simulator. The simulator only simulates the iPhone OS, not the hardware, and there are thousands of differences between each platform. You’ll find a lot of bugs in the phone that simply do not happen in the simulator.

Step 5 – Make it pretty

This step really should happen all along the way, but I thought it would be better to have a different topic for it. Along the way, you’ll have to develop multiple controls for your applications, buttons, align text, show different icons, decide on colors to use, and many other things.

Here’s my tip: Hire a designer.

If you can’t, do not try to do the design the app right away. Rather, try to first become a little bit of a designer. Learn about colors, learn about photoshop, learn about UI design. Apple provides lots of guidelines on UI design for the iPhone. Read it all, multiple times. Also learn about animations, and how give the user the right feedback at the right time.

UI design is hard stuff, a lot harder than most developers (me included) would like to give credit for.

Step 6 – Enjoy

Yes, you have just finished developing your new app. You have just submitted it to the App Store, and now you’re contemplating what to do. This is the step I am at right at this moment (February 6th 2010, 4pm).

Thinking back, it seems that the fact you need Apple’s approval to run your application on the iPhone is not entirely bad. It definitely forces you to focus a lot more on the steps above, which translates into a better application for your users.

It also translates to a lot more work, but nobody ever said this was going to be easy. Apple’s frameworks make it a fairly easy task to develop an iPhone app, but all the things around the platform in general end up taking a lot more work than you were probably expecting (at least that happened for me).

Overall, spending the last 3 weeks developing the new application all by myself was an amazingly gratifying experience, different from any other experience I’ve had developing for the web. Highly recommended.

MonoTouch Presentation at the ChiPhone Group

Later this month I’ll also be talking about MonoTouch at the chiPhone User Group. I’ll also have the pleasure of hosting the meeting this month at our offices at the Willis Tower (old Sears tower):

• When: February 25th, 2010
• Where: Redpoint Technologies, Willis Tower, 233 South Wacker Dr. Suite #750, Chicago IL
• Price: FREE! Register here.

The presentation will be pretty much the same as the one I’ll give to the Chicago ALT.NET group, but because most people in the group already develop iPhone apps using XCode I’ll try to talk more about .NET in general and C#, instead of on the iPhone library.

ALT.NET Chicago MonoTouch Presentation

Next month I’ll be presenting about MonoTouch at the ALT.NET Chicago February 2010 Meeting:

• When: February 10th, 2010
• Where: Redpoint Technologies, Willis Tower, 233 South Wacker Dr. Suite #750, Chicago IL
• Price: FREE! Learn more and register here.

MonoTouch is a new SDK based on Novell’s Mono platform that allows developers to create native iPhone (and soon iPad) applications using .NET languages and APIs. In this presentation, I’ll be talking about the iPhone platform in general, how MonoTouch fits in that ecosystem, and I’ll show how to create a quick sample application.

If you’re coming to the meeting, and have any questions or things you would like to see in the presentation, please contact me!

As many of you know, I’ve been co-hosting the ALT.NET meetings the great Sergio Pereira at our Redpoint office for the last two years, so it’s was big pleasure to be invited to present. Thanks goes to Sergio for the opportunity!

Developing with MonoTouch on Windows and Visual Studio

Here’s how to develop with MonoTouch on Windows and Visual Studio 2008. You won’t be able to compile the code, as it depends on libraries that simply do not exist on Windows, but tools like Resharper will work perfectly. This will allow you to write the code faster, but you’ll still need the mac to run the app on the Simulator or the iPhone.

On the mac:

1. Create a new project with MonoTouch
2. Put it in a network share, or a code repository, so it can be accessed from Windows.

On Windows:

1. Download 7-zip and install
2. Download MonoTouch’s trial version. We’ll need one DLL from this package.
3. Open the pkg file with 7-zip and go to this directory: monotouch-eval-1.4.7.pkg\monotouch.pkg\Payload\Payload~\.\usr\lib\mono\2.1\
4. Extract all the DLLs to a directory of your choice (not inside the project).
5. Make copies of your SLN and CSPROJ files, and call them “mysolutionVS.sln” and “myprojectVS.csproj“
6. Edit your new mysolutionVS.sln:
   • Change the two references (at the top and bottom of the file) to point to the new myprojectVS.csproj.
7. Edit your newmyprojectVS.csproj file:
   • Delete the “ProjectTypeGuids” line. In my case, the line to be deleted contains the following:

     <ProjectTypeGuids>{E613F3A2-FE9C-494F-B74E-F63BCB86FEA6};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

8. Create a new file in the same directory called “myproject.csproj.user”, with the following content:

   <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   	<PropertyGroup>
   		<ReferencePath>C:\path\to\monotouchlibrary\</ReferencePath>
   	</PropertyGroup>
   </Project>

   The ReferencePath above should point to the directory where you saved the DLL files in step 3. Do not include the dll name.

9. Open the new solution with Visual Studio.
10. Finally, remove the current references in that the project contains, and add references to the DLLs from the directory in step 3.

That’s it! You’ll now be able to open the solution in Visual Studio, and use tools like Intellisense, Resharper and others to facilitate the development. To compile the app, use the original solution file in MonoTouch. If you add or remove files, make sure you add them again when you go back to MonoTouch.

While I prefer to make these changes manually, as they’re quite simple, that may not be the case for you. In that case, Manfred Pohler created a little application that automatically does it for you, called VSMTouch. I haven’t used it, but it seems to do something similar to the steps above.