Model-View-ViewModel (MVVM) is a client-side design pattern. It guides the structure and design of your code to help you achieve “Separation of Concerns.”  Implementing MVVM requires a bit of a mind-shift in the way you think about the functionality of your application. It has a significant learning curve and requires some additional upfront effort to get started on the right path. But the benefits are significant:

  • Your code is easier to understand, maintain and troubleshoot.
  • You are much more productive when you leverage the frameworks’ (WPF, Silverlight, XAML, WinRT) built-in features like Data Binding, Resource Dictionaries, Dependency Properties, Routed Events, Commands, etc.
  • You can test your app’s behavior “under-the-skin,” avoiding the pitfalls and cost of testing at the UI level.
  • Your ViewModels afford testability. You can have unit test coverage allowing “Test-Driven-Development” and “Automated Regressions.”
  • Decoupling the View from the ViewModel in the way enabled by MVVM allows designers and developers to work productively in harmony.

If you want your Windows Phone App and Windows Store App to be also available on Android, iPhone and iPad, you will be able to reuse a significant portion of your effort when developing on those other platforms if your app is structured as an MVVM app.

I sense, from my conversations and interactions with developers in code-camps and user-groups over many years, that these potentially significant advantages are not enough of a motivation for many developers to make the switch to MVVM. There is also a perception that implementing MVVM is overkill for a “small” app. MVVM is perceived to be too heavyweight and not worth the effort for many Windows Phone Apps, Windows Store Apps and development prototypes. This is a view shared by many and I understand and sympathize with this perception. However, I am proposing that we use MVVM for all applications, however small and seemingly insignificant. My proposal is based on two realizations:

  1. Inserting the learning curve of MVVM in the critical path of a large project is counterproductive, in my opinion. Using MVVM in small apps and prototypes is the best way to understand and experience the MVVM development style and thinking.
  2. There is a brand-new reason for C# developers to start “thinking in MVVM.” Structuring your C# and XAML code as MVVM and separating your classes as Models, ViewModels, Views, Services, DataAccess and such will give you a head start in reusing a lot of your code on other platforms like Android and iOS. Think about this for a moment – if you want your small Windows Phone App and Windows Store App to be available on Android, iPhone and iPad, you will be able to reuse a significant portion of your effort when developing on those other platforms if your app is structured as an MVVM app. The potential increase in the reach, customer base and revenue is enough for a lot of developers to reconsider the effort to achieve the separation of concerns enabled by MVVM.

Reusing C# code to create apps for Android and iOS is made possible by Xamarin. The level of code reuse depends on the level of separation-of-concerns that you achieve in your application. The Models, Services and Data Access code is reusable with little effort through Xamarin’s absolutely fantastic ability to create native Android and iOS apps using C# code. It is possible, by using MVVMCross, to take code reuse to another level by reusing your ViewModels also. Stay tuned for more about these techniques and technologies on this blog. In the meantime, whet your appetite by reviewing these resources:

AIS has invested heavily in early adoption and technical readiness for designing and building browser-based and native applications for mobile, touch-enabled devices. See examples of our work here, and read more about our full range of mobile-related offerings here

This article will show you how to create a custom TimeZoneInfo that incorporates AdjustmentRules for Daylight Saving Time (DST) Transitions all the way back to 1918. The backdrop for this effort is covered in my previous blog post: Beware of Daylight Saving Time Transitions in .NET. You might want to read that one first for the context.

As noted in the previous post, the System.TimeZoneInfo uses AdjustmentRules to account for DST Transitions, and the default AdjustmentRules do not incorporate all the available DST data. But it is possible to create a custom TimeZoneInfo and populate the AdjustmentRules with DST Transition data available to cover all DST transitions.

Read More…

Back in 1980, Daylight saving time (DST) started on April 27th. But calling the IsDaylightSavingTime method in System.TimeZoneInfo class for April 15, 1980 returns true. The following test fails:

  1. [TestMethod]
  2. public void DST_Started_On_April_27_1980()
  3. {
  4.     var ts = new DateTime(1980, 4, 15, 12, 0, 0);
  5.     var isDst = Utils.EasternTimeZone.IsDaylightSavingTime(ts);
  6.     Assert.IsFalse(isDst);
  7. }

Let’s do some sleuthing and get to the bottom of this.

Read More…

CensusMapper is a Windows 8 app that retrieves U.S. Census Data using the recently released Census API and displays that data on a map using Microsoft’s Bing Maps API. The application is built using XAML and C#. The intent of this version is to establish a proof of concept as well as introduce a design and user-experience direction to be explored and evolved going forward.

Upon startup, the app retrieves the population counts for each U.S. State and displays those counts in a marker positioned in the geographic middle of each state.

CensusMapper - Initial View

Read More…