Infragistics WPF controls

Mono 3.0.4 is out! Features include Improved garbage collection, Async bug fix, and Xamarin studio support.

Mono 3.0.4 released Greetings to all of you open source patrons out there! I've just received news of the latest release of Mono (3.0.4). The new release includes several major improvements and bug fixes. In this article, I'd like to provide a brief overview highlighting the major changes in the latest release of Mono. So without further ado, here is a quick overview of what's offered in this version of the Mono project. Improved garbage collection The GC implementation has been given a makeover. These changes include: A new approach called "cementing" has been added to the SGen concurrent garbage collector. Mono allocates all new small objects in a defined memory space referred to as the nursery. When a collection occurs, the surviving objects become root objects and are copied to the major heap. Typically, few references that are allocated to the nursery survive to become roots, so the majority of the objects are instantly collected which leaves plenty of allocation space for new objects. These nursery collections minimize the work that must be done by the collector. One of the problems with the garbage collection in previous versions of mono involved instances in which objects are "pinned" in the nursery (due to managed/unmanaged references or other operations). Objects that are "pinned" cannot be moved to the major heap. Typically the collector must keep track of these "pinned" objects (and their relationships) and it rescans them on each collection attempt to try to see if they have been released and are able to be moved. This approach was an inefficient practice of the collector. This is where cementing comes in to play. Cementing is a process by which references in the nursery that are pinned are simply marked as root objects, but they remain in the nursery since they can't be moved to the heap. This dramatically reduces overhead related to pinned nursery objects and their relationships. There are also several bug fixes related to garbage collection including #9928 pointer free deadlock problem and bugs in mono_gc_weak_link_get Improved StreamReader/StreamWritter asynchronous operations The asynchronous operations have been rewritten to resolve bug #9761. Which caused the operations to fail on subsequent calls. OSX Homebrew installation conflict resolution Mono no longer installs a /usr/bin/pkg-config file on OSX, which resolves an issue that effected Homebrew installations. The installation only contains the new Gtk+ stack that allows the new Xamarin Studio to run on OSX with 3.0. This is exciting news! Conclusion (for now) Well that about wraps it up.  Oh, one more thing..   In case you haven't heard, Xamarin has released Xamarian 2.0 which includes iOS development from within Visual Studio, a brand new IDE called Xamarin studio that is geared toward developing mobile apps for Android, and iOS. The IDE runs on Windows, Linux and OSX! I would like to mention that I will be delivering a detailed product review on the new and exciting features of Xamarin 2.0. So check back for my review and thanks for reading! Buddy kick it on  

dot42 Android development with C#. All the best parts with less restrictions!

Check out dot42 and Xamarin 2.0 forr developing Android applications using the .NET framework.
Check out dot42 and Xamarin 2.0 forr developing Android applications using the .NET framework. [More]

dot42: an alternative to MonoDroid

Android development in Visual Studio I'm sure a lot of you have heard of the MonoDroid product by Xamarin which allows .NET developers to write android applications using your favorite .NET tools.  I find this option awesome because I'm a .NET developer and because I find native android development tedious.  It's not that Java is difficult, especially when compared to iOS development using objective-C (ughh).  My main problem with android development in Java is once you use Visual Studio for a few years, it's really hard to use anything else.   Enter Xamarin's MonoDroid I was really excited when MonoDroid was released.  That excitement faded quickly when I learned that i couldn't deploy my applications to my Android phone for testing without a license.  Instead, you are forced you use the Android emulator.  I've tried many times with many configurations to use the emulator.  It's simply not feasible for me.  The emulator is INCREDIBLY slow, when it works.  Other times I would wait for 20+ mins before giving up.  I'm not the only developer to express disdain for the Android emulator.  Just google Android emulator slow and you will find a lot of people have this problem. dot42: An alternative Let me start by saying that I ran across dot42 only 10 minutes ago, so I don't claim to have experience with the product.  What I can say is that like MonoDroid, they offer a free version of their product for personal (no commercial development).  Unlike MonoDroid, I see no news on their site to suggest that you can't deploy your application on your phone for testing with the free version.  If this is in fact true, this makes all the difference to me as a developer. (Update: I've verified that dot42 does NOT restrict deployment to your device of choice.  They even allow you to publish free applications to the Android app market!  Be on the look out for  a follow up article dedicated 100% to dot42 very soon!) I think MonoDroid is a great product and it is certainly a much more mature product that dot42.  I will be sure to write a follow up to this article once I've tested the product. What about you?  Anyone out there want to speak out about their problems with the android emulator?  Does anyone else wish that MonoDroid would allow us to test the product on our own devices?  Please feel free to comment and let us know what you think! Happy Coding! kick it on

Dependency Injection with the Microsoft Unity Container: Injecting multiple ICommand implementations

Injecting multiple ICommand implementations with the Microsoft Unity container Hello, and welcome to my second article on Dependency Injection and IoC with the Microsoft Unity Framework.  In my last post Dependency Injection and Inversion of Control with the Microsoft Unity Container I discussed the importance of coding to an interface and not a concrete implementation.  I also introduced the idea of dependencies, and dependency injection using Unity. As I've been working a lot lately in XAML using the MVVM (Model-View-ViewModel) Pattern, I find myself implementing a lot of ICommand classes.  The ICommand interface is very simple, with a method for execution, a method to check if the command can execute, and an event handler to specify the state of the command execution.  The interface is very useful because of the way that XAML can bind to these commands to perform actions on button click's and other user interface actions.   Dependency Injection with multiple ICommand implementations So I had a lot of implementations of the ICommand interface that were used to call on the service layer of my application to complete application tasks. My past experience up until this point never required for me to register one type with multiple interfaces.  Luckily, I found it that Unity has a nice way to handle this issue. So when I setup my container, I register the commands like this _container.RegisterType<ICommand, LoadQuizesCommand>("LoadQuizes"); _container.RegisterType<ICommand, CreateQuizCommand>("CreateQuiz"); _container.RegisterType<IQuizService, QuizService>(); _container.RegisterType<IMainQuizMenuViewModel, MainQuizMenuViewModel>(); Then here is the ViewModel where the dependencies are injected in the constructor. using Domain.QuizIt; using Microsoft.Practices.Unity; using QuizIt.ViewModels.Interfaces; using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Windows.Input; using Service.QuizIt.Interfaces; namespace QuizIt.ViewModels { /// <summary> /// This represents the ViewModel that is bound to the Main Quiz user interface. /// </summary> public class MainQuizMenuViewModel : IMainQuizMenuViewModel { #region "public properties" public ICommand LoadQuizesCommand { get; set; } public ICommand CreateQuizCommand { get; set; } public IQuizService QuizServiceManager { get; set; } public List<Quiz> Quizes { get; set; } public string QuizName { get; set; } public string QuizDescription { get; set; } #endregion #region "constructors" public MainQuizMenuViewModel([Dependency("LoadQuizes")]ICommand loadQuizesCommand, [Dependency("CreateQuiz")]ICommand createQuizCommand, [Dependency]IQuizService quizServiceManager) { this.LoadQuizesCommand = loadQuizesCommand; this.CreateQuizCommand = createQuizCommand; this.QuizServiceManager = quizServiceManager; } #endregion } } Notice how I specify the same names in the Dependency attributes in the constructors as I did when registering the types.  This way I can specify the command by name and resolve different implementations for multiple ICommand interfaces. I hope you enjoyed reading this post.  Please feel free to comment if you have any tricks of your own with injecting multiple interfaces.   kick it on

About the author

My name is Buddy James.  I'm a Microsoft Certified Solutions Developer from the Nashville, TN area.  I'm a Software Engineer, an author, a blogger (, a mentor, a thought leader, a technologist, a data scientist, and a husband.  I enjoy working with design patterns, data mining, c#, WPF, Silverlight, WinRT, XAML, ASP.NET, python, CouchDB, RavenDB, Hadoop, Android(MonoDroid), iOS (MonoTouch), and Machine Learning. I love technology and I love to develop software, collect data, analyze the data, and learn from the data.  When I'm not coding,  I'm determined to make a difference in the world by using data and machine learning techniques. (follow me at @budbjames).  

Related links

Month List