top | item 12949877

(no title)

umurgdk | 9 years ago

I've used in production and experience was good. Xamarin Studio is more than enough for development / debugging. Xamarin is very powerful, but usually people taking the wrong direction with Xamarin and using Xamarin.Forms. As like many other cross platform solutions Xamarin.Forms sucks. If you think making a native iOS application is easy with Swift, it is same with Xamarin too. When i develop applications with xamarin (desktop/mobile) i usually look for java/swift documentations or forums for my problems. This way i don't need separate xamarin community. Because you can write the same code in c# easily. Please check my workflow, for any further questions, twitter: @umurgdk

Recommended workflow: 0. Never ever use Xamarin.Forms other than quick prototyping. If you develop applications with other cross-platform frameworks, you already know all of them sucks and Xamarin.Forms is not an exception.

1. Create PCL / Shared project for your business logic (also your view models if you're using MVVM architecture). Believe me most of your application is platform independent (except the view layer). Your api communication, storage operations all handled here. See 3rd article to how to make storage/network platform independent.

2. Create native projects for each platform (iOS, Android, Windows) implement native views here (use xcode, android studio if you need visual designer). This part should be exactly the same as your swift/java code. For iOS you're just implementing an ApplicationDelegate class and UIViewControllers as same as your swift code. Same for Android part, nothing special to xamarin just implement your activity classes. At this level you have the full power of your native platform with one exception 3rd party native libraries. It's possible to use (yes i used some swift/java libraries for youtube player) them but really hard to integrate to your project, that part has to be improved and better documented.

3. Your shared code base need native features, for example storage implementations are totally different for each platform, or changing views (navigation) will be implemented differently for each platform. Since shared code base shouldn't know anything about native platform. You should abstract these functionalities with interfaces. For example create a storage interface with methods like saving/reading/creating files. Another example might be network communication. Abstract it as an interface on your PCL and implement this interface in your native project with full control of your platform. Your shared code base only knows how to use that interface. And then each of your native projects should implement these interfaces. At this point dependency injection may help to register implementations easily. Actually that part is what makes you share your business logic. Writing idiomatic cocoa navigation code is much better than using any cross platform implementations, you have full control but in the same time your shared code base using them without knowing anything about the platform.

discuss

order

No comments yet.