Tag Archives: design

WinRT from the eyes of a .NET developer

Following is the compilation of information related to what the .NET developer need to know about WinRT.

This biggest confusion, has been around the use of the .NET Framework across the blue side and green side. The reason for the, as I call it, .NET Metro Profile is because the Metro style apps run in an app container that limits what the application can have access to in order to protect the end user from potentially malicious apps. As such, the Metro Profile is a subset of the .NET Client Profile and simply takes away some of the capabilities that aren’t allowed by the app container for Metro style apps. Developers used to .NET will find accessing the WinRT APIs very intuitive – it works similarly to having an assembly reference and accessing the members of said referenced assembly.

At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknown and does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET – for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized (“generic”) interfaces.

One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files – look inside “C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\” in Developer Preview. If you poke around, you’ll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn’t mean that WinRT itself is managed – it simply reuses the file format.

Then there are a number of libraries implemented in terms of that object model – defining WinRT interfaces and classes. Again, look at “Windows Metadata” folder mentioned above to see what’s there; or just fire up Object Browser in VS and select “Windows 8.0” in the framework selector, to see what’s covered. There’s a lot there, and it doesn’t deal with UI alone – you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets.

Then you get several libraries, which are specifically dealing with UI – mostly these would be various namespaces under Windows.UI or Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces – e.g. Windows.UI.Xaml.Controls is closely matching System.Windows.Controls; ditto for Windows.UI.Xaml.Documents etc.

Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop – you don’t need any intermediate artifacts such as interop assemblies, you just /r a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) – the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you’ll see that it actually looks like an extern assembly reference – there’s no sleight of hand trickery such as type embedding there.

It’s not a blunt mapping, either – CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTime and System.Uri, respectively; WinRT collection interfaces such as IIterable<T> and IVector<T> become IEnumerable<T> and IList<T>; and so on. This goes both ways – if you have a .NET object that implements IEnumerable<T>, and pass it back to WinRT, it’ll see it as IIterable<T>.

Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which – particularly Windows.UI – look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight – data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by using the new namespaces, and tweaking a few places in code where the API was adjusted.

WinRT itself doesn’t have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don’t need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a WebView control…). All your .NET and Silverlight skills remain very much relevant in this programming model.

Advertisements

Mobile Application Development : Design and Tools

In late 1990s and early 2000s, developers as well as users  were confused about the choice of the platform  for their applications. They had to decide a solution from two choices – (1) An installable PC based software or (2) a Web application. Web applications was the unpopular choice for a few reasons – among them, Bandwidth limitations and a general insecurity about how safe using a software on internet would be.

But as the years passed by, the requirements too changed. When people started working collaboratively, (which was made much easier with the internet and with bandwidth growth) people slowly started moving into web based applications. Web based Emails are possibly the first web applications used widely. Software companies started developing cross-browser compatible web applications. Now Web 2.0 has changed the perspective of ’software’ totally. And Hybrid applications became possible with APIs etc.

Likewise, in Mobile development, there are three ways to create  applications. (1)Installable (or Native) Mobile applications. (2)Mobile browser based applications – which are websites optimized for Mobile browsers and (3) Hybrid mobile applications.

Three Design Approaches – Native, Web or Hybrid(blended)
Native – Performance, offline mode, findability, device attributes and monetization

Native design builds the code using the code library provided by the phone vendor.  Four primary targets are IPhone, Android, MS Windows Mobile and Blackberry. Native (installable) applications resides in your cell phone, and you  launch it directly from there, with whatever search parameters  are stored within your mobile (E.g.. The names of the 50 states in the USA, your favorite locations, daily weather, etc.). Except for free text search, all of  the search parameters can be stored in the mobile – OR they can be updated just one time.  The communication between the Data/Web server and the mobile phone could be drastically reduced. An application like a stock portfolio can be created within your Phone and stored. Every day you just need to update the stock prices. You need not download the entire portfolio each day. Also, the application resides within the phone, and can access your phone’s features such as your camera, phone book /contacts, etc. The disadvantage is obviously the development cost. No two mobile platforms can share the same mobile application, and there are too many Mobile operating systems (or platforms) existing in the market. If you develop a mobile application to market it widely, you need to develop that in J2ME (for phones that support only Java with no loaded OS), Symbian, Mac iPhone, Android, RIM, WebOS( for Palm pre), LinMo and Windows mobile.

Pros:

  • Application runs faster
  • Able to run offline (provided that all the needed data can exist on the device)
  • Able to use all the phone capabilities – e.g. Shake, Accelerometer, Camera,

Cons:

  • Need to build for each target platform
  • Must deploy like Client server.
  • IPhone Apple Store is controlled by Apple
Web

Web based applications are built using a web toolkit.  Nothing is loaded on the device.  It uses the device browser to load and run the application.  It can be shown as an icon on the desktop that links the web server. The advantage of a mobile browser based application is the low development cost, and the disadvantage is the bandwidth limitations and the limitations of Mobile websites, which does not access your Phone’s components like your Address book, Camera, etc. Mobile Brower based applications are slow due to the bandwidth limitations and will eat up your data usage in your phone plan. Also, the user needs to remember the URLs and type it, which every cell phone user knows is just plain  hard. One advantage is that the development cost is low since the developer only needs to consider how to make it compatible with most mobile browsers, and not each type of cell phone. Also, now that many Mobile browsers support HTML and smart phones come with bigger screens to see full sized websites, and users can zoom in and out. We have keyboards too to manage this. But, if you want to browse websites, you can do that in your tiny Netbook, which you always carry with you, right?

Pros:

  • Build once for multiple target platforms
  • Deploy changes on the server side with no client changes

Cons:

  • Some limitations on functionality and features.
  • Lower performance
  • Cant run offline
Hybrid

They are Applications that use BOTH browser interfaces and native mobile components. The blended model builds a native application but uses HTML to provide some content and features. With HTML5 and JQuery, now the browsers are becoming capable of accessing a phone’s built in features like contacts, camera etc. Finally, what would be the disadvantages of  hybrid mobile applications? Two things comes to my mind…(1) Application security, and (2) the learning curve for the developers. Mobile developers need to know HTML and Web developers need to know mobile phone APIs.

Pros:

  • Existing web content (IF implemented properly) can be reused to reduce costs of native development
  • Maintenance overhead potentially reduced by less frequent updates

Cons:

  • It has all the drawbacks of native development, although potentially diminished (this depends on how much of the functionality is in the native portion of the app and how much is in the web content portion)
  • Properly designed web apps that can be reused without overhead are more of an ideal than reality

Following is the chart of different mobile development approaches used in the industry.

image

Some of the concerns for the business managers are:

  • Disconnected operation IS a big deal. Not for the business traveler so much, but for the people at the jobsite and the people working away from the office on a regular basis. On the jobsite, wireless coverage is often limited, particularly in remote areas and inside structures. For mobile workers (FedEx delivery people, telecoms workers, etc.) wireless access might not be guaranteed. With web-based mobile apps, no connectivity means the applications just won’t run. With proper design, native apps can always be accessible, even though the user may have to defer connectivity until he returns to the office.
  • The mobile apps will have narrow functionality. The best approach is to have a large number of small apps, rather than the traditional model of large applications with tons of functionality. This narrow functionality in turn results in a very narrow user base for each app, which in turn minimizes the need for apps than run on any device. There won’t be many apps that will have wide spread usage.
  • Designing for the lowest common denominator will mean that all applications will have limited functionality. To me, it makes a lot more sense to evaluate each app on an individual basis, rather than trying to come up with a one size fits all model. For an app with a broad user base, it makes sense to build something that will run on any device. But to say that an app used by 1% of the workforce has to sacrifice functionality and usability just so everyone can run it from their own personal devices doesn’t make sense.

The bottom line –

  • Go native on apps with narrow (small user base) functionality, and issue standard devices (one or two standard device types) to the users that run those apps
  • Go web on apps with a large user base, and let the users install the apps on their own devices
  • Hybrid apps are yet to see the light but I believe this is where the future is…

The choice of platform solely depends on your goals. You need a UI that is either:

1. truly usable
2. inexpensive

For option 1, native is the best solution; web is ruled out by its inability to optimally exploit the device.
For option 2, web is the best solution; native is ruled out by its costs; it is to be mentioned though, the price for this is a very austere UI.

Native Application are comparatively easier to maintain, whereas application written to run across multiple platforms may have complex code thus maintenance may not be that simple and testing will have to be intense to ensure a fix for particular platform does not impact anything else.

The advantage of non-native applications is one code base. one iteration of fix will take care of multiple platforms.

The very essence of leadership is that you have to have vision. You can’t blow an uncertain trumpet. – Theodore M. Hesburgh