Videos of my MonoTouch and Mono and Mobile sessions from NDC 2011

Two weeks ago, I was in Oslo, Norway getting ready to present a few talks at the Norwegian Developer's Conference 2011 and now two weeks later, it's about time I point you to my MonoTouch and Mono and Mobile talks from the conference!

First I would like to thanks for everyone involved with the conference, the hosts, the staff, the speakers and the attendees. There was so many great talks going on that you're forced to download the videos afterwards!

All the videos from the conference are up on the NDC website for your viewing pleasure - http://ndc2011.no/agenda.aspx?cat=1071, I highly recommend Ander's talk on Coffeescript and Ryan's talk on Node.js as good starting points.

My MonoTouch: State of the Union talk is available directly here - http://ndc2011.macsimum.no/SAL4/Torsdag/1140-1240.wmv

My Mono and Mobile talk is available direct here - http://ndc2011.macsimum.no/SAL4/Torsdag/1500-1600.wmv

Whilst at the conference, there was a live panel discussion for .NET Rocks on Mobile Development - http://ndc2011.macsimum.no/SAL4/Torsdag/1740-1840.wmv

Read more: ChrisNTR

Posted via email from Jasper-Net

Dynamic ASP.NET MVC 3 models using Mono’s Compiler as a Service

I had an idea for an interactive MVC sample which will let you see the scaffolded editor and display for a model. I thought about a few ways to do this, the first being Mono’s compiler as a service. So far it’s a partial success – the model scaffolding works, but the attributes don’t (very possibly my mistake).

Getting the latest Mono Compiler

Miguel recommended that I grab the latest Mono build off Github, since there have been some improvements and bug fixes in the compiler. He wasn’t kidding, there’s a lot of active work going on in the compiler, and the Evaluator class (the main compiler service class) is no exception. Here’s the commit history just for the Evaluator (eval.cs):

https://github.com/mono/mono/commits/871ad48b98346cffc194b6ebe458a93d88dba009/mcs/mcs/eval.cs

A quick skim of the mcs (mono csharp compiler) commit messages in general shows a lot of work going on, including work on async: https://github.com/mono/mono/tree/master/mcs/mcs

The biggest change since the last Mono release, as Miguel blogged about in February, is the change from static API to an instance API:

…we turned the static API Evalutor.Eval (string expression), into an instance API. The instance API allows developers that are embedding the C# compiler-as-a-service in their application to have different contexts.

This required the entire compiler to be updated from being a giant set of static classes that could safely use global variables and state into a state that was properly encapsulated.

The API is now richer, we provide a way to configure the compiler settings using a settings class. This can be populated either manually, or by using the build-in command-line parser for compiler options.

This is good news – I find the new API easier to work with. The magical static stateful service API pattern works great for the REPL sample but causes problems if you’re doing anything much more complex. The downside, though, is that just about all the code samples and blog posts on the the Mono compiler service stuff don’t work as-is against the new compiler.

I didn’t want to set up a build environment for Mono. Fortunately, most established open source projects offer regular builds if you look around a bit. I grabbed the most recent MonoCharge package from http://mono.ximian.com/daily/, which includes all the precompiled binaries. They’re packaged as a .tar.gz, which opens up just fine in 7-zip. I just grabbed the Mono.CSharp.dll assembly.

Read more: Jon Galloway

Posted via email from Jasper-Net

Interview with Miguel de Icaza: Xamarin, Attachmate Layoffs, Future of Mono, More

Miguel de Icaza took time out from his hectic starting-a-company schedule to chat with me this morning about his new Mono venture, Xamarin, which he and other Novell ex-pats are just getting off the ground. He announced the startup in his May 16 blog post, hot on the heels of news that Attachmate Corporation, which acquired Novell in April, had laid off virtually all members of the Mono team.

De Icaza was able to confirm those layoffs with some confidence, because he had to conduct them himself. "It really could have been worse," he said. "I had to say, hey, you're no longer employed, but then I could say, and neither am I."

De Icaza is, of course, the originator of the Mono Project, an open-source implementation of the .NET Framework based on C# and the Common Language Runtime (CLR). In 1999 he and Nat Friedman founded a company called Ximian, originally to provide Linux and Unix desktop apps based on the GNOME platform. That company became a driving force behind Mono, and it was acquired by Novell in 2003.

But Mono never truly flowered under Novell, de Icaza said, especially in the mobile space. In fact, one of the reasons he is sanguine about the layoffs is that he and his Mono mates have been trying to spinoff the technology from Novell for more than a year.

"We all thought that Mono could really shine on its own," de Icaza said. "For years we've been wrapped in this bubble of Novell, and our mobile efforts didn't align with the strategies of an infrastructure company. We pursued them because a lot of people asked us to do it, and we're passionate about it. I guess you could say that I welcome being laid off, because it gave us a reason to get together and do what we all wanted to do."

Read more: Application Development Trends

Posted via email from Jasper-Net

MonoTouch/MonoDroid and Xamarin - what now?

If you are in the mono community then you'd have to be living under a rock not to have read that Novell was purchased by Attachmate then (first) heard the rumors that Attachmate Lets US Mono Developers Go and (second) seen Miguel's confirmation/announcement of the creation of Xamarin.

What I think this means is:

• Mono should be fine. It has always been open-source (see github.com/mono) and receives contributions from a variety or people regardless of who they work for.
• The MonoTouch and Mono for Android (aka MonoDroid) products published by Novell will effectively stop being supported "as of now". This is based on the fact that none of the devs work there any more.
• Attachmate hasn't announced any plans for those products - even whether they'll continue to be available for sale (along with the associated activation servers). It's impossible to predict what will happen here... various people are trying to get answers from Novell/Attachmate. Personally, even if Attachmate attempted to continue selling/supporting the products I would choose not to be their customer as soon as alternatives are available.
• Miguel and the team who built MonoTouch and MonoDroid have publicly announced they're working on comparable/compatible products to be sold by Xamarin (their new company). These new products are 3-4 months away, betas first prior to a real release. They've done it before, they can do it again!

Lots of people (myself included) have invested plenty of time and money purchasing, learning and using MonoTouch and MonoDroid. I even helped write a MonoTouch book (and some guys have been busy with a MonoDroid one too). We are all collectively upset, disappointed and angry (imagine how the devs themselves feel).

All of this uncertainty has provoked a number of reactions, among them suggestions that all the work done on MonoTouch/MonoDroid projects to-date has been wasted or that people should start learning the native SDKs for iOS and Android instead of committing to the Mono alternatives.

Read more: ConceptDev (Craig Dunn's blog)

Posted via email from Jasper-Net

Announcing Xamarin

Today we start Xamarin, our new company focused on Mono-based products.

These are some of the things that we will be doing at Xamarin:

Build a new commercial .NET offering for iOS

Build a new commercial .NET offering for Android

Continue to contribute, maintain and develop the open source Mono and Moonlight components.

Explore the Moonlight opportunities in the mobile space and the Mac appstore.

We believe strongly in splitting the presentation layer from the business logic in your application and supporting both your backend needs with C# on the server, the client or mobile devices and giving you the tools to use .NET languages in every desktop and mobile client.

Development started early this morning, we will first deliver the iPhone stack, followed by the Android stack, and then the Moonlight ports to both platforms.

The new versions of .NET for the iPhone and Android will be source compatible with MonoTouch and Mono for Android. Like those versions, they will be commercial products, built on top of the open core Mono.

In addition, we are going to provide support and custom development of Mono. A company that provides International Mono Support, if you will.

Read more: Personal blog of Miguel de Icaza

Posted via email from Jasper-Net

Скрипты в .NET/Mono средствами самой платформы

Работая тут над одним проектом, потребовалось мне, что бы функциональность проекта расширялась на лету и сторонними разработчиками, причём возможностей к расширению было как можно больше, с возможностью правки кода на лету. Соответственно плагины для этого не очень годились из-за необходимости их постоянной перекомпиляции после любой правки. Выход: скрипты. До этого со скриптами я работал достаточно давно и это была Lua на C++. Вариант хороший, если бы не несколько минусов:

Отсутствие нормальной реализации или прослойки под .NET/Mono — во всех что я видел были какие-то недоработки (может и плохо искал — как минимум пропустил Lua в TaoFramework)

По всей видимости, нужно было писать кучу биндингов что бы среда исполнения .NET/Mono могла нормально взаимодействовать со средой Lua и обратно.

Тогда-то я и задался вопросом — а может быть в .NET/Mono уже есть что-нибудь для реализации скриптов? И ответ был да. Пространство имён "System.CodeDom.Compiler" было как раз то, что мне надо — возможность реализовать скрипты которые максимально соединялись со средой .NET/Mono.Правда если посмотреть на мой механизм скриптов изнутри, то это получается и не скрипты даже, а код, написанный на C#, просто динамически компилируется и загружается в память для выполнения. Однако, не смотря даже на такой «фейк», результата я добился — я мог править код, на лету перекомпилируя его прямо в своём приложении. И при этом это будет работать даже на машинах где не установлены Visual Studio и другие средства разработки, так как компиляторы, как минимум, C# и VB.NET идут прямо вместе с .NET и Mono.

Пример, о котором говориться в статье, можно скачать тут: http://zebraxxl.programist.ru/ScriptsInDotNet.zip

Пространство имён "System.CodeDom.Compiler"

Собственно самое главное в данной статье. Именно здесь собраны классы для компиляции кода в .NET/Mono сборки. Основным классом выполняющим работу является класс CodeDomProvider. По своей сути фактически — это интерфейс над компилятором, который просто подготавливает данные для компиляции и вызывает компилятор выбранного языка с нужными параметрами. Ну начнём по порядку.

А какие языки у нас вообще поддерживаются?

Что бы это выяснить достаточно вызвать статический метод CodeDomProvider.GetAllCompilerInfo. Данный метод вернёт массив СompilerInfo. В теории конечно может быть и так, что один компилятор поддерживает сразу несколько языков, но на практике я пока с таким не встречался. Но как раз на случай «многоязычности» компилятора в .NET/Mono как раз и сделано так, что сначала мы получаем информацию об отдельных компиляторах, а уже потом смотрим кто, какой язык поддерживает. Вот примеры вывода этой информации из примера:

0 compiler languages:

        c#

        cs

        csharp

1 compiler languages:

Read more: Habrahabr.ru

Posted via email from Jasper-Net

MonoTorrent

MonoTorrent is a cross platform and open source implementation of the BitTorrent protocol. It supports many advanced features such as Encryption, DHT, Peer Exchange, Web Seeding and Magnet Links.

Notable features include:

• Encryption
• Dht
• Peer Exchange (uTorrent style)
• Local Peer Discovery
• Web Seeding (getright style)
• Magnet Links / Metadata download
• IPV6
• FAST Extensions
• Sparse files (NTFS file system)
• Multi-tracker torrents
• Compact tracker responses
• IP Address white listing / black listing
• Fast Resume
• Initial Seeding (super seeding)
• Selective downloading
• Prioritised downloading
• Full bittorrent tracker
• Dynamic request queue size
• Memory Cache
• Endgame mode
• Per torrent and global rate limiting
• Individual file relocation

Source code: http://github.com/mono/monotorrent

Read more: MonoTorrent

Posted via email from Jasper-Net

Moonlight on Android

For the past week, the Moonlight team has been busy porting Moonlight to Android devices and today, showed it off at Mix 11. The video shows Moonlight running on both a Motorola Xoom tablet and a Nexus S phone. Keep in mind that we're still in the early phases of porting and there's still a lot of work left to do before we can ship a product, but it's still exciting! 

Update: For those of you reading my blog from Planet GNOME (or some other planet that doesn't show the video above), you can find it here, on YouTube.

Read more: A Moment of Zen

Posted via email from Jasper-Net

The Big Split: Mono 2.10 Debian Packaging

Most probably haven't noticed yet but I finished the Mono 2.10.1 debian packaging effort of the past 3 months and uploaded it to Debian/Experimental.

With Mono 2.10 I had to make the biggest changes in Mono packaging since the big Mono 2.0 upload. The runtime no longer supports the 1.0 and 2.0 runtime profile, instead it now supports the 2.0 and 4.0 runtime profile. This meant I had to drop all libmono*1.0-cil packages and add libmono*4.0-cil packages. This sounds like a lot of s/1.0/4.0/ work but it actually wasn't. Mono 2.10 ships a lot of new libraries over 2.6 and I had again to decide where they should go. "Where should this $library go?" I have been playing this game for the past 7 years maintaining Mono and I finally gave up on it... What, where, when, why? I could give now a 2 hours talk of the issues behind the current packaging approach (keeping the number of library packages low) but instead I will do something else. Please, just take a look at this picture for a second:

Read more: Hacking is Art

Posted via email from Jasper-Net

Windows Phone 7, Android and iOS with Mono

Nick Randolph has published five more parts of his series discussing some of the pain/success/difficulties experienced in building the same application across three platforms:

• Mono III: Shared Libraries
• Mono IV: Webservices
• Mono V: Content and Resource Files
• Mono VI: File Access
• Mono VII: Database

Over the past couple of months I’ve been thinking more about how to share resources between applications written for WP7, Android and iOS. Increasingly companies that I consult with are asking how they can build an application once and have it run across multiple platforms. My belief is that this isn’t easily achievable and even if it is would lead to a poor user experience on one or more platforms.

Read more: Silverlight Show

Posted via email from Jasper-Net

Mono for Android now available. C# and .NET developers rejoice now that you can make apps for Android

It must be developer news day today or something, not that we are complaining. The more tools developers have, the better they can make good games with! Mono for Andorid, now available for general consumption, will allow developers to develop applications and whatever else they want to using technologies like C# and .NET.

MonoTouch is similar to Novell's other product, MonoTouch, which allows iOS developers the same flexibility that Mono for Android is giving to Android developers, allowing them to develop iOS applications using C# and .NET for the iPhone, iPod, iPad. However, using both MonoTouch and Mono for Android side-by-side will allow developers to share code across all platforms from Android to Windows Mobile and iOS which will save time for developers who can then worry less about porting and more about game quality.

Included in Mono for Android:

Core Mono Runtime

Bindings for native Android APIs

Visual Studio 2010 plugin

An SDK containing relevant tools to build, debug and deploy your applications

Read more: Droid games

Read more: Mono-android

Posted via email from Jasper-Net

Mono Android and iPhone Updates

Today we are happy to release Mono for Android 1.0 as well as MonoTouch 4.0.

Both products allow you to use the C# language to write applications that run on Android and iOS devices.

Both products are based on the latest Mono 2.10 core. The Parallel Frameworks can be used to write more elegant multi-threaded code across all devices, and automatically takes advantage of multiple cores available on the iPad2 and Xoom devices. The C# 4.0 is now the default as well as the .NET 4.0 APIs.

Mono for Android

Our Mono for Android debuts today after almost a year worth of development.

Perhaps the most important lesson that we got from MonoTouch's success was that we had to provide a completely enabled platform. What we mean by this is that we needed to provide a complete set of tools that would assist developers from creating their first Android application, to distributing the application to the market place, to guides, tutorials, API documentation and samples.

Mono for Android can be used from either Visual Studio Professional 2010 for Windows users, or using MonoDevelop on the Mac.

Read more: Personal blog of Miguel de Icaza

Posted via email from Jasper-Net

MonoTouch 4.0

We just released MonoTouch 4.0, a product to build iOS applications using C# and .NET. We also released our new Mono for Android product.

New in MonoTouch 4.0

MonoTouch 4.0 is a major upgrade to our product as it upgrades the Mono runtime engine from the old, trusted and friendly Mono 2.6 to the latest and greatest Mono 2.10 core, these are some of the new features available as part of this upgrade:

Parallel Frameworks for C#: Great APIs for building multi-threaded software. Not only this is great for iPad 2 users and developers, but it also simplifies just plain multi-threaded programming by exposing Futures, Tasks and Parallel LINQ to the developer.

LLVM Compiler Support: In addition to the fast Mono compilation engine, MonoTouch can now also use LLVM to create optimized builds. When you build MonoTouch applications using LLVM your executables will run faster, they will be smaller, and you can optionally opt into generating the nimbler ARMv7 or Thumb code (fat binaries are also supported).

Example: My own TweetStation distribution went from 8 megs to 6 megs using Thumb + ARMv7 support. A very significant gain.

C# 4.0 and .NET 4.0: This release comes with the latest incarnation of the C# language as well as exposing the new .NET 4.0 APIs (many new functional constructs make for nicer looking code, like all the IEnumerable enabled-methods in System.IO).

There is one important limitation: C# 4.0 dynamic support is not functional, since it requires dynamic code generation to work.

Upgraded WCF stack: We still consider this a preview of the full WCF but has been expanded significantly.

All new iOS 4.3 APIs have been exposed.

NSDecimal, NSDecimalNumber are now exposed (mostly for the sake of CorePlot :-)

Many new convenience APIs have been introduced.

For a full detailed list of changes, see our MonoTouch 4.0 Release Notes.

Read more: Miguel's OSX and iOS blog

Posted via email from Jasper-Net

Exploring Cocoa with MonoMac and C# – Chapter 1 – Getting Started – Part 1

Below, you will find the outline of what you will learn in this chapter:

What you need.

Getting Setup.

Installing MonoMac add-in

MonoMac from source.

What you need:

Readers will need several things to effectively use these tutorial articles:

Apple Macintosh: You need an Apple Macintosh to build and deploy an application targeting the Apple Macintosh Desktop using Cocoa. If you do not want to layout the cash for a full system than a Mac Mini provides a low cost alternative and is more than enough to start creating applications.

Xcode: The development tools from Apple. You will need to have an Apple Developer Connection to download the tools. If you have already installed the iPhone SDK then you should be ready to go.

Mono Framework: You need to download and install the Mono Framework for the Apple Macintosh. The Mono Framework can be downloaded from the Mono web site at www.mono-project.com/.

MonoDevelop: The MonoDevelop IDE can be downloaded from the MonoDevelop web site at http://monodevelop.com/.

What you need to know to begin:

A basic knowledge of programming and C#. Since this document will be using C# in its examples a little experience programming in the C# language will definitely help you out. We will mostly be exploring the Cocoa API using C#, MonoDevelop and MonoMac so being an expert in C# is really not a requirement. There are many programming books and sites available to get you up to speed.

A willingness to experiment.

Get started:

If you have a Macintosh computer then you are set. If not then please back away from this document, get yourself a Mac, see the section What you need: above, and then continue with the rest of this chapter.

Read more: Cocoa-Mono

Posted via email from Jasper-Net

Hardware Accelerated Video Playback in Moonlight

David Reveman has just completed a series of optimizations in the Moonlight engine that allows Moonlight to take advantage of your GPU for the data intensive video rendering operations. This is in addition to the standard GPU hardware acceleration that we debuted a few weeks ago.

This is what the video rendering loop looks like in Moonlight:

Every one of those steps is an expensive process as it has to crunch to a lot of data. For example, a 720p video which has a frame size of 1280x720, this turns out to be 921,600 pixels. This frame while stored in RGB format at 8 bits per channel takes 2,764,800 bytes of memory. If you are decoding video at 30 frames per second, you need to at least move from the encoded input to the video 82 megabytes per second. Things are worse because the data is transformed on every step in that pipeline. This is what each step does:

The video decoding is the step that decompresses your video frames. This is done one frame at a time, the input might be small, but the output will be the size of the original video.

The decoding process generates images in YUV format. This format is used to store images and videos but and with previous versions of Moonlight, we had to convert this YUV data into an in-memory bitmap encoded in RGB format.

The final step is to transfer this image to the graphics card. This typically involves copying the data from the system memory to the graphics card, and in Unix this goes through the user process to the X server process, which eventually moves the data to the graphics card.

New Hardware Accelerated Framework

Read more: Personal blog of Miguel de Icaza

Posted via email from Jasper-Net

gui-thread-check

MonoDevelop often makes use of threads to run operations on the background. Although we make sure to invoke all GUI update methods through the main GUI thread, sometimes there is a bug and an update is done in the secondary thread, which causes all sort of random locks and crashes.

To make it easier to track down those bugs, I created a simple profiler module for Mono which can detect invocations to GTK# methods from a thread other than the main GUI thread. This module is available here:

https://github.com/slluis/gui-thread-check

To use it, build and install the module, and then run your application with the command:

mono --profile=gui-thread-check yourapp.exe

If the profiler is properly installed, you'll see an output like this:

*** Running with gui-thread-check ***

*** GUI THREAD INITIALIZED: 2861676352

Read more: Food for Monkeys

Posted via email from Jasper-Net

PDF Mod Update

I haven't blogged about PDF Mod since Nov, 2009. We've had five releases in the meantime, including 0.9.1 just released today!

We have had tons of improvements and fixes, and one major new feature: bookmark editing!

We're up to 26 translations now, including 11 of our user manual!

As a reminder, PDF Mod can:

• pull out (extract) pages from a document into a new PDF
• combine two documents, or parts thereof
• reorder and rotate pages
• extract embedded images
• edit basic metadata (title, author, keywords)
• edit a document's bookmarks (aka outlines)
• and that's it!

Read more: Gabriel Burt's Blog

Posted via email from Jasper-Net

PROTIP: PARALLEL-INSTALLING MONO VERSIONS IN AN APT-HAPPY WAY

If you’ve ever gotten tired of waiting for a new Mono release to appear, and taken matters into your own hands by compiling your own copy of Mono, you’ve likely faced the problem of “missing” libraries. “That’s weird, it says it can’t find gtk-sharp, but I have that package!”

This happens because every version of Mono on your system has what’s called a Global Assembly Cache – a location where all system-wide assemblies lives. So when you run an app like Tomboy, it loads its libraries such as GTK# from the GAC belonging to the Mono runtime being used. Ordinarily, this is in /usr/lib/mono/gac on a Debian/Ubuntu system.

When you have your parallel Mono, it doesn’t share a GAC – as a result, libraries in your main distro GAC are not available in your DIY GAC, as they were never registered in there.

Typically, the advice is to either start compiling every lib you need into a non-standard place too – however, here’s a better idea. Why not make Apt take care of not only your system’s GAC – but additional GACs too? We actually have structures in place to handle this, so it’s not as hard as you think (merely relatively unknown). This guide does NOT take startup scripts into account – it’s your problem to ensure you’re using the correct “mono” command to run your copy of MonoDevelop or Tomboy or whatever. You should probably learn about update-alternatives and $PATH for this. Oh, and this guide will BREAK HORRIBLY if you try to uninstall system mono completely. Don’t try it.

Setup step 1: preparation
Don’t install parallel Mono into /usr/local. I don’t care what happens to you if you do. Use some random folder in /opt, usually a per-build prefix like /opt/mono-2.10

Setup step 2: duplicating existing magic
Open a terminal, and copy /usr/share/cli-common/runtimes.d/mono to a new filename, e.g. /usr/share/cli-common/runtimes.d/mono-2.10

Setup step 3: tweak duplicate magic
Open your copied file in an editor, and change the name value on line 27ish (e.g. from “Mono\n” to “Mono (parallel 2.10 install)\n”). Then change the two places in the file, on lines 64ish and 120ish, from “/usr/bin/gacutil” to “/opt/mono-2.8.2/bin/gacutil” or equivalent.

Setup step 4: apply magic to existing packages
Run “/usr/share/cli-common/gac-install mono-2.10″ (or whatever filename you picked for your runtimes.d entry) as root. This will instantiate your parallel GAC(s).
From now on, every GAC library you install or uninstall will happen to every single runtime in runtimes.d.

To go back to how things were before, with only a single Mono runtime:

Read more: ApeBox

Posted via email from Jasper-Net

Why Mono for Android?

I have gotten a few questions asking why a developer should use Mono for Android (aka MonoDroid).  I thought I would just do a brain dump on my thoughts on this.

Java Developers are looking at MonoDroid and wondering "Why"?  They see that the core of Android is Linux, an open source operating system, with a bunch of passionette people behind it.  Java developers have a free runtime, they have a free IDE (Eclips) to develop with, they have a free SDK to develop with, they view Java as an easy language to learn (and I'm not debating any of these points).  Why would anyone want something else?  Let me introduce myself, I'm Wally McClure.  I'm a .NET developer, and I think you have a product that is being accepted into the marketplace.  For a developer to be productive, they need a language that they understand, an IDE that helps them to be successful, and knowledge of the underlying operating system (the -isms).

• I'd like to "get me some of that."  I'd like to be able to write programs that run on your platform.  I'd like to do that with the least amount of pain possible.  I'd like to reuse as much of my existing .NET knowledge as I can.  Mono, the open source implementation of .NET runs on a variety of platforms.  I can take my existing knowledge of C#/.NET and apply it to Android.  This solves my problem of the language.

• I'd like to use my existing tools as much as possible.  I've invested time, money, and energy in learning Visual Studio .NET.  I am productive in my existing environment, why should I have to add a new environment to program in.  Because Mono for Android integrates in with my existing IDE, the problem of having an IDE that I understand has been solved.

• Now, ultimately, I still have to learn the Android-isms to be productive.  We've already faught the Java, cross platform wars and we know that writte one run anywhere failed.  I don't think that anything can really help us on this. 

Now, I don't mean to imply that learning the Android-isms is simple.  Its hard.  You have to learn the platform.  There's no getting around that.  Does Mono for Android solve two thirds of my problem?  That would be underestimating the problem of learning the Android-isms.  I do think that it helps with half the problem.  Now that I am up and going, it seems that learning the Android-isms isn't that hard, but I would have had to learn them either way.

Read more: More Wally - Wallace B. McClure  

Posted via email from Jasper-Net

Mono.Addins

Mono.Addins is a generic framework for creating extensible applications, and for creating add-ins which extend those applications. This framework has been designed to be useful for a wide range of applications: from simple applications with small extensibility needs, to complex applications which need support for large add-in structures.

The main features of Mono.Addins are:

• Supports descriptions of add-ins using custom attributes (for simple and common extensions) or using XML manifests (for more complex extensibility needs).
• Supports extension metadata and data-only extensions.
• Support for add-in hierarchies, where add-ins may depend on other add-ins.
• Lazy loading of add-ins.
• Dynamic activation / deactivation of add-ins at run time.
• Allows sharing add-in registries between applications, and defining arbitrary add-in locations.
• Allows implementing extensible libraries.
• Supports add-in localization.
• Provides an API for accessing to add-in descriptions, which will allow building development and documentation tools for handling add-ins.
• In addition to the basic add-in engine, it provides a Setup library to be used by applications which want to offer basic add-in management features to users, such as enabling/disabling add-ins, or installing add-ins from on-line repositories.

Read more: Codeplex

Posted via email from Jasper-Net