Comment by bernadus_edwin | Hacker News Reader

Comment by bernadus_edwin | Hacker News Reader

Parent Full thread

I using xamarin in last 16 months

From my experience, xamarin take wrong UI improvement strategy

Dont get me wrong, this is a good product, i love it, but just going to wrong direction

This is the big 2 mistakes:

1. You change the API class and method name to .net version

For first time user, this is good approach, but i must rename every sample snippet code from stackoverflow

You should save the resource for renaming API to something else more valueble ( hint : fixbug )

Are you rename the API because of patent and legal issue?

2. Xamarin form

This is the worst strategy.

Maybe this is good for B2B

And maybe B2B is good money

But for me, indie programmer, B2C product, i dont need xamarin form

I need best approach to use UI library

Stop xamarin form, there is other way to get 90 percent shared library

Support more on MVVM cross

Duplicate total of the xamarin component store

Improvement object sharpie to support UIKit.h

Object sharpie not working if using UI library

Android binding still design for eclipse project, not android studio

I'm wasting 1 week to bind ListViewAnimation android, and still not working

My point is, it really hard to bind UI library on xamarin

Conclusion,

Please please turn around and go back to your real core value.

We like native, improve native, do not recreate the UI component

You know what happend when you try recreate UI?

Go check java se and Qt

Hello,

Changing the name is a necessity if you want to have a good looking program.

Consider an API like "drawString:" and "drawString:atPoint:" and "drawString:atPoint:withFont:". These are acceptable in the world of objective-c, because they are used with parameters, but they are not really suitable in this way in C#. So we map the API names to forms that are idiomatically correct in C#.

In the above case, we would like map those to a single "DrawString" method name with three different overloads. But this depends on the case. In general, we follow the .NET Framework Design Guidelines for our naming conventions.

As for forms, you are correct, we built it for a class of users that had different requirements than those that are building consumer applications.

Now, while I am the first one to tell developers to use our native APIs to create great consumer experiences, just last week I ran into a gorgeous looking app and only later I discovered that the gorgeous UI was actually built entirely with Forms, even the animations.

More importantly, the app was built on record time by a single developer. I could not believe it (need to ask the customer for permission to disclose that their product is built with our product).

So I walked away with a new insight: that good UIs require good taste and someone passionate enough to make the UIs happen and that even something that we intended for mostly business scenarios can create great UI experiences.

hi miguel,

thx for responding my comment. after read your explanation, i agree with your argument about xamarin form. it just need more feature and more sample. Xamarin sample layout is not esthetic. You should look at telerik example. And last one, when feature listview drag and drop swap row available on android ?

thx

Reply on news.ycombinator.com