Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Monday, July 14, 2014

From around 1995 until 2010 there was really only one operating system for client computing: Windows.

Prior to 1995 there were a lot of options, though most not recognizable to users today: 3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now most of these weren’t “client computing”, they were relatively dumb terminal technologies that provided access to a server (back then called a mainframe or minicomputer). Very much like today’s web browser (sans JavaScript).

Today we’ve returned to a chaotic landscape of client computing: browsers, Windows, iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995 technologies went away, they are just mostly emulated in Windows. What is interesting though, is that most of today’s client computing technologies do actually enable smart client software development. This includes the browser which can be used as a smart client technology via JavaScript development, even though the majority of browser “apps” are actually just colorful versions of 1990-era terminal-based computing where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.

What is interesting about this return to client-side chaos is that it has reopened the door for third party developer tools as a niche market.

In the early 1990’s there were quite a number of companies selling developer tools for other company’s platforms. Borland with C++, Delphi and TurboPascal, Gupta with SqlWindows, Powerbuilder, and a lot more.

When Windows became the dominant client computing platform most of these dev tools fell by the wayside (not that they went away, they just stopped being mainstream). This was because they couldn’t compete with Microsoft’s dev tools, which were always in sync with the platform in a way that was probably too expensive for third parties to match.

I think it is notable that our return to client computing chaos (or pluralism?) today has already led to numerous third party dev tool vendors that sell dev tools for other company’s platforms. Xamarin, PhoneGap, Telerik’s tools, and a lot more.

What is different to me is that in the early 1990’s I thought it was pretty obvious that Windows would become a dominant platform, and I tended to argue against using third party dev tools because I thought they’d have a rough go of it. As cool as Delphi was, I always recommended VB.

Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the foreseeable future. It is hard to imagine Windows returning to its monopoly status, but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate desktop computing environment either.

As a result we business developers need some way to build software independently of any particular platform or OS vendor, because we must assume all our business software will need to run on multiple platforms and OSes.

So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably convinced that building smart client software (at least for business) means using third party dev tools from vendors that aren’t tied to any one platform.

Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate toward a combination of Xamarin and Microsoft .NET as a way to use my C# and .NET knowledge across all platforms. I get to develop in Visual Studio on Windows where I’m most comfortable, and my resulting software runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.

As far into the future as I can see there’s no obvious platform/OS “winner”, so as a developer the question isn’t which platform to target, it is which third party dev tool reaches all platforms with a solid strategy that will stand out and thrive over the next many years.

Monday, July 14, 2014 1:00:31 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, July 01, 2014

There’s been a lot of exciting change in cross-platform development for C# developers over the past few months. Microsoft introduced the Universal Apps concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced Xamarin.Forms (Windows Phone 8, Android, and iOS).

Beneath the Universal App support in Visual Studio 2013 is a broader concept called a Shared Project. With the Shared Project Reference Manager add-in for VS13 you can reference these shared projects from any project, not just Universal App projects.

As a result, you can build a solution like this one:

SharedCodeSolution

This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI code from the NonUICode.Shared project.

In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project. In the WinRTApp all the UI code is in the HubApp1.Shared project.

The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough in common with WinRT or Xamarin.Forms for sharing.

None of the UI projects contain any business logic or logic to call services. All that code is in the NonUICode.Shared project so it can be maintained just one time. The service calls use HttpClient, which is reasonably common across all the UI platforms, and for the few differences I’m using #if statements to accommodate the per-platform code. For example, here’s a bit of code from a shared viewmodel class: 

    public async Task SaveData()
    {
      if (this.IsDataLoaded)
      {
        var webClient = new HttpClient();
        var data = JsonConvert.SerializeObject(this.Speaker);
#if ANDROID || __ANDROID__ || __IOS__
        var content = new StringContent(data, System.Text.Encoding.UTF8, "application/json");
#else
        var content = new HttpStringContent(data);
#endif
        var urlString = apiSpeakerUrl + @"/" + this.Speaker.Id.ToString();
        var response = await webClient.PutAsync(new Uri(urlString), content);
        if (!response.IsSuccessStatusCode)
          throw new Exception("SaveData failed");
      }
    }

The overall result is that with reasonable effort you can create an app that spans every type of smart client technology available today; from Windows Forms up to iOS. These apps can share all your business and service client code, and can often share a lot of UI code.

(fwiw, if you build your business logic with CSLA .NET it is a lot easier to create and maintain the shared business and service client code than if you try to build that code by hand)

CSLA .NET | WinRT | WP8 | Xamarin
Tuesday, July 01, 2014 3:32:53 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [3]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
July, 2014 (2)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In