Xamarin Project Structure
A typical multi-platform project, split into separate projects for each platform and one project for a shared library. The shared library can contain both platform-independent code and a simple UI in XAML. This is quite a convenient separation that enables us to easily structure the code. A definite advantage.
Frameworks
The basic toolkit contains C# and the .NET framework. A practical high-level language is another advantage.
The .NET framework + Xamarin.Forms is a set of frameworks available for a shared library. This is basically a kit for modeling the app data. There are no platform-specific features like access to the file system and camera. On one hand, this increases the volume of the code, on the other hand, allows better code structuring.
There are platform-specific frameworks like Xamarin.iOS and Xamarin.Droid, as well as the C# UI for all the native platforms frameworks (for example, Core Data for iOS and Android.Support.v4 for Android). The majority of tasks, this allows to avoid using third-party libraries and utilize the standard platform capabilities with no additional wrappers. A big fat virtue.
Obviously, the necessity of using Xamarin(Mono) and the .NET frameworks increases the application size by 10 MB, however, this is more of a payback for the cross-platform features than a substantial drawback.
The UI
You can create user interfaces in Xamarin. There are two approaches to do that:
Xamarin.Forms
Xamarin.Forms as a cross-platform “description” of the UI that with a help of special renders transforms into the corresponding native elements. (Xamarin.Forms.ListView → UITableView). Because of this, the UI will visually different for both platforms (as the native iOS button is different from a native Android button).
The behavior of every element of a platform can be edited through a renderer. The UI is described in XAML in the code. There is a standard visualizer built-in to Xamarin IDE that uses a device simulator. Using this functionality can significantly ease and speed up the UI-building process, but also restricts the architecture of the app. It requires taking into account the state of the app when being executed by a visualizer. This solution is great for the apps with a simple UI or prototypes that aren’t bothered by the UI at all.
Native Platform UI
Using the native UI of each platform is an option for design-heavy applications. Xamarin supports the C# interfaces of all the platform’s native frameworks, including xib & storyboard for iOS and layout for Android. So, the UI elements’ work is no different from the similar experience in XCode and Android Studio.
Xamarin Libraries
Xamarin libraries are distributed through NuGet. Again, the majority of your app’s tasks can be carried out by some library, which there are in vast numbers. Either from third-party developers or Xamarin’s own, the libraries are there. Xamarin Studio has a NuGet package manager built in, which allows to quickly find and install the appropriate package, as well as upload a personal library to a shared environment.
iOS & Android Libraries
If the functionality you require can’t be fully found in the Xamarin libraries, you can connect the additional iOS (.a) and Android (.so, .jar) libraries. However, this is more complex procedure:
The С/Objective-C/Swift Library For iOS
- Create a project in XCode, assemble a library (don’t forget to check the dependencies).
1.1 Build a FAT file for all the platforms used.
1.2 Add the iOS Library Bindings Project to Xamarin.
1.3 Add the recieved .a library file to the project.
1.4 Specify the correct flags in the .a file attributes.
1.5 Create the UI by means of P/Invoke.
This is likely to leave you with a multitude of the [DllImport()] calls. You can fix it with the help of the Objective Sharpie utility, as it can process the library header files and create a fairly precise UI library description. The result has to be still manually tested though.
2. Use CocoaPods for simple libraries and dependencies. It really simplifies the step 1 by downloading the library, assembling it, and creating the UI through a single command in Terminal. Yet, complex libraries with dependencies on other pods can’t be handled that easy; so I advise you to use the approach from step 1.
For Android
3. Set up the C libraries for Android following the same complex procedure as for iOS in step 1.
4. Add the .jar/.aar library for Android. It’s fairly simple here:
4.1 Add a library directly to the Android app project.
4.2 Specify the right supported ABI libraries.
Xamarin will analyze the library’s Java UI and create its equivalent in C#. This is definitely the easiest way out of four.
Conclusion
Xamarin is a great tool for prototyping, building an MVP, and apps with the UI designed from the standard elements. In that case, you can reach from 80 to 90% code reuse between the platforms.
Another implementation area is the class of applications with heavy business logic. By using the native approach to building UI, you can implement the design of any complexity. The reuse percentage score depends entirely on the model size and the application business logic.
I don’t think it makes sense to use Xamarin to build apps with a simple model and business logic, as well as apps that are deep into graphics (games) or showcase high-performance requirements.
You can find the sample project I used in this article on GitHub.