Great News for MonoTouch Users

by Miguel de Icaza

Apple has removed the restrictions that were introduced earlier this year (the famous section 3.3.1).

Although Apple had not blocked any MonoTouch applications since the new rules were introduced, many developers either took a wait-and-see approach, or switched their development. We never stopped working on MonoTouch, just yesterday we released MonoTouch support for the new iOS 4.1 APIs. We did this within eight hours of the new operating system going public.

With these new terms, the ambiguity is gone and C# lovers and enthusiasts can go back to using MonoTouch. Developers that like garbage collection and their strongly typed languages can resume their work.

In addition, Apple has published their detailed review guidelines for application developers. This should help developers get their apps approved. And the MonoTouch Book is a great way to get started.

Thank you!

We would like to thank the MonoTouch community that stayed by our side all along and helped us improve MonoTouch and continued to build great applications during this time.

Those of us that have a crush on iOS and .NET are grateful to Apple and the Apple employees that helped make these changes happen.

Expanded MonoTouch iOS investment

Although we continued to extend, improve and polish MonoTouch the older terms made it harder to justify taking on some larger tasks, the risk was high.

We had some big projects in mind for MonoTouch. We are going to start prioritizing these new features, but we want to hear from our users, and we want to know what is more important to you. Please fill out this survey to tell us what do you think it would be more important to bring to MonoTouch.

We will balance your input with our own "gut" (we would not be truth to the Stephen Colbert spirit if we didn't).

....and discounts!

Joseph Hill has just told me that we are doing a 15% discount for the next two weeks for anyone buying MonoTouch. Use discount code "MONO-331" on http://monotouch.net/Store.

We have also a surprise in store for existing MonoTouch customers that we will be announcing next week.

Posted on 09 Sep 2010


Initial Thoughts on Oracle vs Google Patent Lawsuit

by Miguel de Icaza

Today Oracle sued Google over Java patents and copyrights that they claim Google's Android OS infringes. The lawsuit claims that Google knowingly infringed on those patents, and that the continued distribution of Google's Android is harming Oracle's Java Business.

You can read the actual complaint, the patents referenced are:

There is also a copyright lawsuit, but there are not enough details on the complaint to figure out what the claim is. Until there is a trial, we will not really know what is being asked here.

Pundit Prediction Time!

I would like to think that this is going to be solved with a quick settlement where Oracle will shake Google for a few billion dollars and the entire matter will be put behind.

Oracle will likely want to settle with Google under terms that will only cover Google's own use as they want to go shaking other OEM trees for more cash.

An unlikely scenario is for Google to pay the bills for all Android OEMs as they are coming out fast and strong from every corner of the world.

It occurred to me that Oracle could sell all the Java assets to Google. But Google probably passed on this opportunity back when Sun was put on the market.

What Jonathan Schwartz Knew

Sun's Ex-CEO Jonathan Schwartz has recently taken to the blogwaves to blog about the things he could not tell us while he was a CEO of Sun. While he might have found a new voice for gossip from the Sun days, he will not say a word on this matter, because he was likely engaged in shopping the patent lawsuit around.

Sun had created Java, but it turned out to be very difficult for Sun to monetize Java directly after the initial source code license deals that they struck with IBM, Microsoft, Oracle, Netscape and others. They created the J2EE market, just to find that other companies and startups executed better than they did on the systems that they had initially engineered.

Sun was left in the uncomfortable position of being the owner of the technology that everyone was cashing out on, but they themselves had very few revenue streams for Java. Like Clemens Vasters joked on Twitter today:

They had the Microsoft lawsuit cash and they had the embedded licensing business with Java Micro Edition and Java Standard Edition licensing deals.

The open sourcing of Java was also carefully planned. By picking the GPL as their license, they ensured that embedded system OEMs and developers would have to negotiate a different license with Sun if they wanted to use the OpenJDK on their systems.

There is very little public information on the Google/Sun split over Java ME and the creation of Dalvik. The rumors on the grapevine were that Google and Sun could not reach an agreement over the Java Micro Edition licensing. Sun wanted to sit in the middle between Google and the handset OEMs, while Google wanted to create a free-for-all operating system.

When it became clear that they would not be able to reach an agreement, Google started a project to replace Java Micro Edition and they used some clever engineering techniques that blended the best of both worlds.

It is likely that during these negotiations, Google threatened to build their own Java runtime and Sun countered with a list of patents. This would explain why Google went through the trouble of making the Dalvik virtual machine explicitly incompatible with the existing Java virtual machine instructions.

Although Dalvik uses a different set of instructions, Google created a translator that recompiled Java code into Dalvik code, and with this, they worked around whatever licensing technicalities they were aware at the time of the negotiations.

Needless to say, Sun was not happy with Dalvik. Not only because Sun had lost a large licensing deal, but also because it had the potential of becoming the de-facto Java virtual machine that everyone on the embedded space would pick instead of Sun's own Java Micro Edition.

In late 2007 Google announced both Android and the Open Handset Alliance to the public. On the Java front, Sun had delivered on the promise of open sourcing Java, but it had been a rough year for Sun and it would get worse, in the next twelve months after the announcement, Sun stock would lose 80% of its value.

Sun had their plates full, so Sun did not feel the need to react immediately to the Android threat, so they kept their grievances to themselves.

But Jonathan started to shop the company in late 2008. The monetary value of the Java assets had been devaluated due to the open sourcing of the technology under the GPL. I am going to bet that the same careful planning that went into picking the GPL went into pitching the potential for lawsuits.

The world had already witnessed the awesome iPhone and the eyes were on Google to deliver a killer phone. Jonathan must have known this and he must have been pitching this to the potential suitors.

By the time Oracle bought Sun, they knew that they would be going after Google and anyone else with a big, fat checkbook that did not have a licensing deal in place.

And that explains the Exodus of famous Java people from Sun shortly after the acquisition. The wheels of the lawsuit started spinning the moment the sale was done. Those employees are probably under NDA.

Update: I was wrong, apparently Gosling was not under NDA and has confirmed exactly what I said above:

Oracle finally filed a patent lawsuit against Google. Not a big surprise. During the integration meetings between Sun and Oracle where we were being grilled about the patent situation between Sun and Google, we could see the Oracle lawyer's eyes sparkle. Filing patent suits was never in Sun's genetic code. Alas....

I hope to avoid getting dragged into the fray: they only picked one of my patents (RE38,104) to sue over.

So now we know that Jonathan shopped Sun with a big "Sue Google" sign. So much for his visionary patent defense against Apple and of course this jewel:

The most egregious of such suits was filed against Sun by Kodak (yes, the film photography people).

Egregious, because Kodak had acquired a patent from a defunct computer maker (Wang) for the exclusive purpose of suing Sun over an esoteric technology, Java Remote Method Invocation (“Java RMI” – not exactly the first thing that comes to mind when you hear “Kodak”).

And he was just playing Wang's role a couple of months ago.

Update: this post from the Dalvik announcement era discussed how Dalvik's work around the license-from-Sun challenge.

Some Background on the Java Patents

The Java specification patent grant seems to be only valid as long as you have a fully conformant implementation:

(a) fully implements the Specification including all its required interfaces and functionality;

(b) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; and

(c) passes the Technology Compatibility Kit (including satisfying the requirements of the applicable TCK Users Guide) for such Specification ("Compliant Implementation").

This is more stringent than the Microsoft Community Promise that applies to .NET as the Community Promise only requires a minimum subset, it does not prevent supersets.

This seems to be what the lawsuit is hinged upon.

Is this it?

I vaguely remember in one of the endless anti-Mono discussions that someone pointed (maybe it was Gosling himself?) that Java had a patent grant for anyone to implement under any conditions.

They pointed to the spec. And I remember seeing this on the spec and thinking that it was a generous patent grant. Perhaps I was confused and the only patent grant is the one in the previous section, but if you know of the other document, please let me know.

Sun's GPL

By GPLing Java, Sun lost some of the exclusive rights that they used to have, in particular, anyone using the open sourced version of the OpenJDK is given the patent rights to run the software.

The problem is that the rights are only available as long as you are using the GPL version of Java. Any patent grants are not available if you use a third-party licensed version of the Java virtual machine. In that case, it seems like the only option would be to to go back to the Sun licensing terms.

Wishful thinking

Too many engineering resources are devoted to Android at Google and at their partner companies, but I can not help to think that Google could migrate Android from Java to the ECMA/ISO CIL and C#.

Unlike the Java patent grant, the Microsoft Community Promise for both C#, the core class libraries and the VM only require that you have a full implementation. Supersetting is allowed.

Additionally, Microsoft has placed the .NET Micro Edition entirely under the Microsoft Public License which comes with an even more generous patent grant, and covers a superset of the code covered by ECMA/ISO 335.

We have open source implementations of both, and even more luckily, the ECMA/ISO VM specification allows for different profiles, to allow for ultra-small or server-sized versions of the VM to be created. Ideal for mobile platforms.

Google could settle current damages with Oracle, and switch to the better designed, more pleasant to use, and more open .NET platform.

Some Humor

There is a silver lining in this whole mess, and it is that the tweetosphere came up with a few funny tweets, here are my favorites:

And while you are here

I am very excited to see the first MonoTouch book published.

Posted on 13 Aug 2010


Unix and Linux StackExchange

by Miguel de Icaza

Help create a non-tribal version of StackOverflow for Unix and Linux questions.

As we know, tribalism makes you stupid. So let us commit to the Linux and Unix Q&A site powered by StackOverflow that will help answer questions for Unix and Linux users of all distributions and blends.

At the time of this writing, only 91 users have committed.

Tell your Solaris, FreeBSD, NetBSD, OpenBSD, Unix, OSX, Linux, Red Hat, Fedora, Ubuntu, Debian, Mandrake, Mint, Arch, Slackware, CentOS, Gentoo, OpenSUSE, friends to commit to it and help create a global community of Unix love.

Posted on 05 Aug 2010


MonoTools 2 for VisualStudio has been released

by Miguel de Icaza

We just released Mono Tools for Visual Studio.

There are four main features in MonoTools 2:

  • Soft debugger support.
  • Faster transfer of your program to the deployment system.
  • Support for Visual Studio 2010 in addition to 2008.
  • Polish, polish and more polish.

Thanks to everyone that participated on our beta program for all of the bug reports and feedback!

MonoTools is the foundation on which we are building the upcoming Mono for Android toolchain.

New Long-Term Maintenance Mono Release

With the introduction of MonoTools for Visual Studio, we are also moving our long-term maintenance Mono release from the Mono 2.4 release to Mono 2.6, the release that we announced last week.

Getting Started

Download our betas from this page. On Windows, you would install our plugin for either 2008 or 2010 and you need to install Mono 2.6.5 on the target platform (Windows, Linux or MacOS).

On Linux, run `monotools-gui-server' or `monotools-server', this will let Visual Studio connect to your machine. Then proceed from Windows.

On MacOS, double click on the "MonoTools Server" application.

Once you run those, MonoTools will automatically show you the servers on your network that you can deploy to or debug:

ASP.NET debugging with this is a joy!

Soft Debugger

This release is the first one that uses our new soft debugger. With is a more portable engine to debug that will allow our users to debug targets other than Linux/x86 for example OSX and Windows.

This is the engine that we use on MonoTouch and that we are using for Mono on Android.

Our previous debugger, a hard debugger, worked on Linux/x86 systems but was very hard to port to new platforms and to other operating systems. With our new soft debugger we can debug Mono applications running on Windows, helping developers test before moving to Linux.

Faster Transfers

When you are developing large applications or web applications, you want your turn around time from the time that you run hit Run to the site running on Linux to be as short as possible.

Cheap Shot Alert: When dealing with large web sites, we used to behave like J2EE: click run and wait for a month for your app to be loaded into the application server.

This is no longer the case. Deployments that used to take 30 seconds now take 2 seconds.

Support for Visual Studio 2010

Our plugin now supports the Visual Studio 2010 new features for plugin developers.

This means you get a single .vsix package to install, no system installs, no registry messing around, no dedicated installers, none of that.

The full plugin installs in 3 seconds. And you can remove it just as easily.

Then you can just from VS's Mono menu pick "Run In Mono" and pick whether you want to run locally or remotely.

We now also support multiple profiles, so you can debug from Visual Studio your code running on Linux boxes, Mac boxes or your local system.

Polish and more Polish

MonoTools was our first Windows software and we learned a lot about what Windows developers expected.

We polished hundreds of small usability problems that the community reported in our last few iterations. You can also check our release notes for the meaty details.

Appliances

And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.

Posted on 03 Aug 2010


Mono has migrated to GitHub

by Miguel de Icaza

We have now migrated all of Mono's source code from the Subversion at our Cambridge office over to GitHub.

We are going to be maintaining a migration FAQ and providing help to developers on irc.gnome.org channel #mono for the new setup.

The web site has not been updated yet and we still reference Subversion urls, but this will be fixed in the next few days.

Posted on 22 Jul 2010


Mono 2.8 Trick: tracing exceptions

by Miguel de Icaza

Mono has an strace-like feature built into the runtime. This is useful to see which methods are being called by your application, just invoke Mono with --trace.

Our upcoming version has a neat new feature, when you use --trace=E:ExceptionName or --trace=E:all you get a stack trace of where the exception was thrown from:

$ gmcs.exe
mono$ gmcs missing.cs
error CS2001: Source file `missing.cs' could not be found
Compilation failed: 1 error(s), 0 warnings

And now with tracing enabled, we do it setting the MONO_ENV_OPTIONS variable:

mono$ MONO_ENV_OPTIONS=--trace=E:all gmcs missing.cs[0xb75136f0:] EXCEPTION handling: System.IO.FileNotFoundException: Could not find file "missing.cs".

"{unnamed thread}" tid=0x0xb75136f0 this=0x0x53f18 thread handle 0x403 state : not waiting owns ()
  at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,bool,System.IO.FileOptions) {0x00619}
  at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) {0x00022}
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) {0x0004f}
  at System.IO.File.OpenRead (string) {0x0002c}
  at Mono.CSharp.Driver.Parse (Mono.CSharp.CompilationUnit) {0x00016}
  at Mono.CSharp.Driver.Parse () {0x00068}
  at Mono.CSharp.Driver.Compile () {0x00098}
  at Mono.CSharp.Driver.Main (string[]) {0x000a2}
  at (wrapper runtime-invoke) {Module}.runtime_invoke_int_object (object,intptr,intptr,intptr) {0x00033}
error CS2001: Source file `missing.cs' could not be found
Compilation failed: 1 error(s), 0 warnings

Posted on 21 Jul 2010


Banshee Ships with Amazon Store Support

by Miguel de Icaza

Aaron just shipped Banshee 1.7.3 which lets you purchase MP3s from Amazon from the player directly.


Banshee Amazon MP3 Store Screencast!

Get it fresh!

Posted on 21 Jul 2010


Building apps for the Retina Display

by Miguel de Icaza

While adding Retina Display support to TweetStation I learned a couple of tricks that I figured would help other developers.

iOS 4 Points

Apple's Retina Display conveniently doubles the number of pixels on each dimension, the previous iPhone display had 320x480 pixels while the new new phone has 640x960 pixels.

To make existing applications run out of the box on these new displays Apple changed the units on the display and instead of using pixels they now use points. They are not really typographical points, but iOS "points". Both the old iPhones and the new iPhone have a resolution of 320x480 points.

This means that existing code that absolutely positioned views on the screen will get the views laid out in the same positions regardless of the device that the code is running on.

In UIKit points are interpreted based on the value of the UIView.ContentScaleFactor. If the value is 1.0 each point is mapped to one pixel. If the value is set to 2.0 each point is mapped to four pixels (2x on each dimension).

UIKit layout and CoreGraphics rendering primitives will automatically take this factor into account and position and render accordingly.

Images

The Image loading routines have been extended to load higher-resolution images by default when you use UIImage.FromBundle. On Retina Displays the code will probe for a file@2x.ext filename when you request file.ext to be loaded. For example this loads the background texture you use:

	texture = UIImage.FromBundle ("Images/texture.png");
	

TweetStation's images are here.

Bitmaps and Inkscape

All the icons and images on TweetStation were done using Inkscape. When I exported the icons they would invariably look blurry. For example, this is from my first attempt at getting the swipe menu on TweetStation working:

I would just draw my icons on Inkscape and then export them as bitmaps. Inkscape would then anti-alias the result, you can see how the reply icon is not rendered properly:

The Inkscape FAQ contains this bit of information that is very useful if you are drawing small icons:

With the current renderer, it is not possible to completely get rid of antialiasing. However, it is possible to partially suppress it on export. Usually, antialiasing is unwelcome in horizontal and vertical lines which become "blurred". To work around this, make sure your horizontal/vertical edges are snapped on the pixel grid, and all strokes are a whole number of pixels wide. Then, export bitmap at the default 90dpi so that 1 px unit corresponds to 1 bitmap pixel. In the resulting bitmap, snapped color boundaries will be perfectly crisp.

These are the settings that I use now to export the same graphic:

I used guidelines on Inkscape to help me:

This is the new version of the icon before it gets composited with the background

To export the same image at high resolution, set the DPI in the dialog box to 180. Inkscape will automatically change the width and height for you.

The other problem that I had was related to my centering code, this is what the rewteet icon looks like from the menu above:

The blurry sides of the retweet icon were caused by the math code setting the X position of the image at a fraction of a point (0.5).

After fixing both problems and adding a nice backdrop shadow, this is what the menu looks like:

Graphics Context

Loading images with more pixels for the background texture and the icons wont do you any good if you are drawing the images yourself.

When you create a graphics context using the pre-iOS 4 APIs you will end up with a context that assumes that you are not aware of the Retina Display and hence will rescale your drawing up. When you create an image context of 100x100 points like this:

	UIGraphics.BeginImageContext (new SizeF (100, 100));
	

You will end up with a context that has 200x200 points, but will automatically double all of your pen widths and will scale any images up. If you had a high-resolution image, it will first be scaled down when rendering to the context, then scaled up when rendering the data.

To take advantage of the retina display you need to call a new method:

	UIGraphics.BeginImageContextWithOptions (SizeF size, bool opaque, float scale);
	

If you set scale to zero, it will pick 1.0 for old display and 2.0 for retina displays. I use this helper method to support both iOS 3.x and iOS 4.0:

	void BeginImageContext (SizeF size)
	{
		if (Graphics.HighRes)
			UIGraphics.BeginImageContextWithOptions (size, false, 0);
		else
			UIGraphics.BeginImageContext (size);
	}
	

This is how the swipe menu is rendered at high resolution:

More

Apple's Supporting Resolution Independence document has more information.

Posted on 20 Jul 2010


Mono's Git Migration

by Miguel de Icaza

Mono's source code is being migrated to GitHub on July 22nd, starting at 9am Boston time.

We are psyched that Github was kind enough to host Mono's large repositories for free on their system. We are also taking advantage of their new Organizations functionality.

Gonzalo posted the following details about the migration:

We are moving our source code repository to GitHub.

On July 22nd ~9am EDT (1300 GMT) the subversion repository at "svn
+ssh://mono-cvs.ximian.com/source" will be set to read-only mode and
kept that way forever.

We estimate that the process of migrating all the projects and moving
them to GitHub will take more than 3 and less than 8 hours. Once it is
completed we will send an email to this list with URLs to the new
repositories, FAQs,...
	

If you have any questions about the migration, please ask them here and we will add them to our Git Migration FAQ.

Posted on 20 Jul 2010


Fresh Mono Baked

by Miguel de Icaza

Andrew just announced Mono 2.6.7, the version that is replacing our long-term maintenance release of Mono with plenty of bug fixes as well as the following new features:

  • Microsoft's ASP.NET MVC2 is now bundled with Mono.
  • Upgraded xbuild tool (Mono's msbuild)
  • Upgraded our LINQ to SQL (DbLinq)
  • Upgraded our Soft Debugger
  • We now publish CentOS/RHEL packages.

Our CentOS/RHEL packages install on /opt/novell/mono, just like our packages for SUSE Linux Enterprise and should not conflict with your own packages of Mono that you might have from some other sources.

Posted on 20 Jul 2010


« Newer entries | Older entries »