DSL and Xamarin , a practical couple

While the Xamarin.Android and Xamarin.iOS is the best choice so far, I am also investigating Domain Specific Languages (DSL)..
DSL is a kind of metalanguage, that you use to tell it what to do and the DSL will tell the native language (Java, Objective-C, C# (Xamarin.Android, Xamarin.iOS) how to do it.

Thus, DSL does not mean that Xamarin framework will be displaced. On contrary! If we will treat the Xamarin language solutions as a native languages, then we should be able to easily describe what we want and the appropriate code would be generated. For the business logic, we don't need a DSL, but for the logic that glues everything together (menus, page flow, business logic, data access logic), we need a DSL. It does not make sense to write the same presentation logic in Xamarin.iOS and Xamarin.Android again, and again ... the presentation logic should be generated by the DSL in a human readable form...
I see it this way: a DSL will generate code for MvvmCross framework which is built on top of Xamarin libraries.
Since I am a Mono guy, I would prefer to be using a DSL tailored for .Net languages ...
Right now looking into using F# as a tool for writing DSLs ...

Any ideas, suggestions?

Let's get started ....

 After many sleepless  nights I have molded together an idea how the cross-platform mobile apps should be developed and what tools I would like to use...

My interest lays in enterprise kind of development, so when I was hand picking appropriate tools
the price was not a main factor for selection, instead the ease of development, maintainability and
possibility to quickly acquire developers for a given mobile project was made a priority.

Since I like C# and F#, I would like to use .Net platform to develop the apps. So bad the .Net is
Microsoft OS framework.  Luckily I was wrong, we can use Mono, which makes it possible to run .Net on almost any  OS.  To start with, I would like to be able to write apps for iOS and Android using only
one set of application code . Well, the problem is, the iOS wants to be written in Objective-C and Android in Java. It means, I would need to use  ObjC/C# and Java/C# and ... it does not look like
a fun I am looking for .

Fortunately, Xamarin has  created a nice product, which uses the bridges behind the scenes, so I don't need to worry about it . Their  software  (Mono based) runs on iOS and Android and is hiding from me
all the magic of calling Java and Objective-C from C# ....

Still, Xamarin.Android and Xamarin.iOS is pretty "low level" for my taste, so I want to use another
framework build on top of it. There already are MVVM frameworks for Monodroid and Monotouch
(old names for previously mentioned products) so hopefully I will get some fresh ideas when I will be putting  together a library (or should I call it a framework?) for cross platform mobile development.

There are also DSL based solutions, which I would like to investigate in a near future.

Thus, I cooked up some chart that I would like to follow:

Please, take a look and next time I will try to explain what the art above means......

Quest is going on .....

As I wrote before, there were many ingredients I was about to explore ... and I did . 

And I decided to let some ingredients go. Those over-stricken pieces are  to go :

• HTML5
• CSS3
• Javascript
• C# ??
• F# ?? Similar multi-platform solution needed 
• LESS  (maybe?)
• Coffeescript  (why not to bring fun to writing code?)
• iOS, Android, Blackberry etc (not necessary but good to know)
• knockout.js
• Server Side Events
• Javascript bridges to native code 
• Rx.Net (in case we will use C#, this way we will be able to build Reactive UI)
• Websockets (we can try to hook them up to Rx) 
• XML (we already know it, right?)
• JSON

Are HTML applications the right approach to achieve cross-platform deployability?

  I have been experimenting a lot with various HTML mobile frameworks and I don't think it is the best way to go. Of course , these frameworks are very convenient and you can deploy apps very quickly. 

The problem is, that not only you have to try to develop for different platforms, but also, you have to develop for different browsers. 

 If you want to shield yourself from the complexity  of particular platform, yes, then the HTML apps are pretty  successful in that. But you have to pay a price .... you also lose advanced features that each

of these platform can offer. 

Thus, I think the HTML apps are not the answer and I will investigate other possibilities to be able to 

develop for multiple platforms using one set of code. 

What is needed is a completely new approach in software development..... stay tuned....working on it :)

Ingrediences to be examined in order to cook up a good Xplatform mobile development stack ...

 Our mission:
           create "something",  that will help us to quickly deliver applications across various mobile platforms and devices.
 Requirements:
          reuse a vast amount of code base that we will pretend we have in place and we will pretend the business  code is written in .Net languages ,
          perhaps C#, F#.
          The fact is, many companies have written web applications in ASP.Net and desktop apps in C#.
          So, let's keep it simple and "profitable".

 Not all methodologies, frameworks or languages will be used in our effort. I have put together a shopping list and then  we will see how it goes .
 To understand cons and pros of the ingredients we are going to use or not, we should investigate and try to understand functionality of the stuff listed below:

• HTML5
• CSS3
• Javascript
• C#
• F# (for financial and scientific computing)
• LESS  (maybe?)
• Coffeescript  (why not to bring fun to writing code?)
• iOS, Android, Blackberry etc (not necessary but good to know)
• knockout.js
• Server Side Events
• Javascript bridges to native code 
• Rx.Net (in case we will use C#, this way we will be able to build Reactive UI)
• Websockets (we can try to hook them up to Rx) 
• XML (we already know it, right?)
• JSON

In case I forgot to throw in anything, please, let me know

Cross-platform mobile development. New approach needed.

  A cross-platform mobile development is a mess. In order for a company to develop a money making application on different platforms, we need to hire either developers who know a particular platform (which means we have to start as many projects as many platforms we have to support) or we have to hire developers who know it all (which will mean the application will be of average quality).
 If we look closer to investigate the problem, we will see, that using a right design and architecture, it will not be a mess any more. The design is more important than the actual coding in any project .
Many methodologies, including Agile and similar flavors    are not applicable in this field,  because they prioritize "working progress" and customer immediate satisfaction compared to a solid design and architecture.
 Agile methodology delivers software very quickly, that's why we need JIRA and similar tools to track all these bugs that have been created in environments, where "DONE" is more important than "DONE RIGHT".
 What we need in order to successfully target multiple mobile platforms, is to slow down, sit back and have a cup of tea or coffe and start thinking... I will not be using "scientific" terminology on purpose, because terminologies are invented by people pushing for certain ideas. I don't like being pushed.
Many bright developers have created systems for Android, iPad, iPhone, Windows Phone , Blackberry etc. It is good, each platform has its strengths and these developers tried to squeeze as much as possible out of these devices. It is excellent and for games and specialized applications it is the only way - to go native.
  Most of us work for corporations, which are in business to make money, it means, they need to target as many customers as possible. One problem is, that all the customers are using different devices and they are not willing to buy another device only to be able to run our application. Most of applications developed by corporations don't need to squeeze as much as possible from particular device. In fact, they all are similar  The application takes input from the user, makes some calculation and possibly saves the result in a database.
 And of course, the company producing the software wants to use developers who can be easily replaced or hired. They simply don't want to invest in having Java, Objective-C, C++, C#, etc. experts to be able to develop one application and I don't blame them. It is sufficient to have experts in one of these languages, because then they can come and go and the company will not feel the pain.
  In this blog I will be playing with idea of creating a development stack that is good for most corporate applications.

 Stay tuned...don't go anywhere.

IronGlue starts kicking ......

This blog is called IronGlue not by accident ... The Iron Glue symbolizes the fact, that software should be written to be solid like an iron and "glued" together so its iron "pieces" will not fall appart.

If these pieces will be glued together in an intelligent way, they can work in different environments and 

serving different purposes and still be the same pieces of iron .....