Thursday, June 15, 2017

Native Mobile Cross Platform development tools and frameworks war ... part 1

 There are two main mobile platforms on the market, namely iOS and Android.. These are followed by platforms not having too much impact on revenue streams of software mobile developers , for example Blackberry, Windows Phone, and some other I really don't care about .

A native way of developing apps for  iOS (iPhone, iPad, iWatch, iPod ) is using Objective-C and/or Swift. The Objective-C is one of the best languages I have ever seen but unfortunately other people think otherwise, that's why Swift have been invented.

A native way of developing apps for Android is using Java (Dalvik) . Or one can use any language running in the JVM.

Writing and maintaining applications written for these major platforms may be difficult and expensive, if you want to keep these apps in sync across the different platforms. What is needed, is a layer, that will abstract away the hardware and platform differences and that will make it possible to code a program against a generic platform . Whatever is a non UI code, it is easy to write a code that will be the same across the platforms. The UI code is tougher to write because the way of rendering the native controls is different and the navigation mechanism between pages is different too across the platforms.

There are two major approaches to write the apps:

  1. Write a common code which contains no UI functionality and does not access any hardware feature of the devices and put it to a library , which will be shared by iOS and Android while maintaining a separate code base for UI on these two platforms. 
  2. Write a code that will abstract away even UI rendering so we can write a common UI code for all supported platforms. 
In order to be able to use these two approaches, it is necessary to use a single programming  language per an approach. 

These approaches are supported by major players on the market: 
  1. Common business code, separate UI code 
  2. Common business code, common UI code
    • Xamarin.Forms (C# and any .Net language) 
    • NativeScript   (Javascript, Typescript and any language transpiling to Javascript)
    • and more popping up ....
In next article I will try to dive in to cons and pros of these different approaches. I have picked only those as outlined above , there are many more frameworks trying to achieve the same thing . 

Thursday, June 16, 2016

An easy way of building applications using NoSQL or Graph Databases ....

In 1993 I have been developing and selling  an application that allowed a rapid development of applications with forms , modal popups , menus and much more .
The application was developed using the Smalltalk programming language which could seamlessly call C++ language and vice versa.  Declarative parts of the applications were saved in proprietary files (similar to JSON, but more compact and it allowed circular references) .
Later  I have been distracted by other tasks in my life and I abandoned  further development of this idea.

Now, when I became interested in NoSQL and Graph databases, I discovered that my idea of building applications can be implemented effortlessly using for example Neo4J, which will hold screen definitions (that can be rendered in any language on any platform) and also an application code in any language (kinda language plugins) . It would be nice to hold in the DB executable AST and then generated any language out of it  (but it is a far fetched idea, perhaps later ) .
Since my passion for time being is C# and increasingly F#, I will try to implement it in  .NET but the application should be language agnostic ..
I will post articles as I go and describe different challenges and maybe ask for help and opinions.

Any ideas and help welcomed. The repository is completely empty right now , please allow couple of days to put in some material that makes sense....

Sunday, March 13, 2016

Agile philosophy hoopla hey

  Nowadays the  Agile technology is a fashion whoever does not do it, is considered to be behind times.
  While Agile may be good at the same time it received lot of criticisms . Agile is a concept already  30 years old, and it may be good but if you twist the rules or does not follow them at all then it brings more harm than good. Many incompetent managers are adopting this fuss without any understanding. On the other side the managers, who get it, can deliver amazing results. 
  Lately I saw lot of incompetence and it is really frustrating. On the stand-up meetings people sit and have a cozy time. On these meetings people talk only to the manager and squad leaders take orders from the small dictators called managers. 

  All the theory , however excellent ( I believe Agile is a pretty interesting and perhaps already outdated  approach and  if  you don't understand it, it causes more harm than good) does not help if programmers (developers) are treated like dirt and don't use adequate tools to get the job done. 

  Many times we spend 50% of our productive time on presentations talking about the new silver bullet and listening to nonsense like "we don't need a team of great individuals , rather we need a great team of individuals".   Go and figure .

  Tools...developers are going thru all those seminars and look excited while they know nothing will change. How can you be Agile if you still use donkeys instead of cars to do the job. 
For example :  I know a case where developers are working on a mobile project involving iOS, Android but also a web based part of the app. Besides the fact that "everybody has to know everything, we are Agile" (it means you have to know web based front end , ASP, back end, to be  database expert, master javascript and all existing framework, master Objective-C, Java, C#, C, C++, CSS, HTML, iOS, Android, , Linux,  OSX, Windows and you have to be able to rotate quickly, we are Agile!!) .
 According to some managers, who only want to appease  their breadgivers, you have to do all the above and still using  elephants  instead of using more modern tools. 

  Here comes an example: some teams are using MacBooks to work on iOS projects. Of course because they have to be  "knew it all" people,  they also need to have a webserver (IIS) running on virtual windows running in the Mac so the company has not to spend money for extra laptops.
 It is actually an excellent idea , I do it myself, but I have a good hardware...
Other less fortunate people are using a Mac with a  crawling 500 GB harddrive which  it is  almost full and thus slow. Some of developer are using 4GB of RAM (or at least 8GB)  and running a iOS debugger, an iOS simulator, IIS on virtual server and watching the Tube.. (work related videos of course..:). As a result the Mac becomes slow, overheated and as a very result it is failing to work... Buy hey, we have some Agile seminars  today so Mac will have time to cool down. 
  Any excellent theory is not good if there is not a sufficient infrastructure to support it.  
Upgrade to 1GB DDS, use at lease 16GB and try to convince managers (who sometimes are detached from reality) to make IT people network run faster, fix proxies that does not allow many time to go to professional websites to do the research etc. etc. 
 Only upgrading Macs can speed up things 4-5 fold. And the bucks to pay is much less than the price of work time otherwise lost.  After upgrading Mac you can take on crawling network ....

 Happy Agile!!!

Tuesday, February 2, 2016

Nativescript and Xamarin should join forces 2

I wrote recently that UI could be developed in Javascript and the business logic in C#.
Well, we can develop the whole app in one language and then the preprocessor will transpile
certain parts (mostly UI) to Javascript..
So, we will have exactly what I wrote in part 1but still be able to write the entire app in one language.
How good is that?

Take a look here . Not sure if it would work with Nativescript but since Websharper has custom translation, it should be possible , Will try  during next holdays ....

Sunday, January 31, 2016

Nativescript and Xamarin should join forces

Sorry for having the coffee break one year .. I am back. Coffee was good.

Xamarin cross-platform tools is good, but I don't understand why we need to develop the entire mobile app in Xamarin. Whatever is not UI code and thus does not need to be using native framework (Cocoa, Android ...) should be written in Xamarin code (C#, pick). This way the Xamarin is faster than the native framework in most cases.
On the other side UI  should be written either in the "native" language (Obj-C, Java..) or Javascript.

Javascript is a very good candidate, because we already have two good Javascript frameworks that are enabling writing UI natively using Javascript and CSS....It is not using HTML .

By now,  mobile applications are developed as one piece,,,,It is not a very good idea, because the maintainability cost is going thru roof months later.
If we develop an app as 2 applications (one written in Javascript and the other Xamarin C# or F#) , then we can keep the business logic written in C# in one app and the UI , written in Javascript, in another app. The advantage is, that the two apps don't hold any references to each other's objects .
All communication can be done via pipes or sockets.

I am experimenting with this approach as time allows and hopefully soon I will be able to show the "framework" I am putting together.

Saturday, August 16, 2014

UI is the Bottle Neck

   Many companies are jumping in and try to port iOS to Android and vice-versa.
Specially if you are using Xamarin, it should be easy, right?  As one "expert" told me: "It is everything C#, so you should be done porting it in no time " ...
Well, it is not that easy . The biggest obstacle is using UI in a platform independent way .  I think each page could be defined with 3 markup files. One would contain "WHAT" has to be displayed, the second "WHERE" it should be displayed and  the third would define binding to underlying models .
Three files should be used in order to support "separation of concerns".

Stay tuned, working on it , :)

Sunday, July 13, 2014

Xamarin.Forms - a cross-platform development framework

 Xamarin.Forms,  a new addition to efforts to write one code - run everywhere.
It looks really nice, one can do sophisticated things with it  ....
Don't you know what it is? Go to Xamarin.Forms and see for yourself.
I don't completely agree with this framework library design, but it is a very brave step to make cross-platform mobile development pretty easy.
I think the framework/library is rather thick and is shielding  developers from the Android, iOS and Win8 Phone good stuff... It looks like Xamarin Android application is using only one activity , and iOS only one controller.  Xamarin is maintaining its own menus, page stack and some more...
While I really like many aspects of Xamarin.Forms, I think a better approach would  be to get rid of
"Renderers" and instead to use partial classes together with shared projects . Thus we could achieve a better flexibility and minimize  redirections in the code.
I like the declarative way of defining how app and each of the pages will behave,,,
Here Xamarin guys  did a good job  ,,,,,
Congratulation and hopefully I will  be able to use it in the current projects