Microsoft MVP, Shahriar Hossain shows you how to build your first cross platform app with Xamarin. With Xamarin.Forms, you're able to get maximum code reuse to quickly build fully native apps for Android, iOS, and Windows. In this session learn how to share C# code to define the UI and business logic, enabling you to design your screens, fix bugs, and write your app just once. With Xamarin for Visual Studio, you use the language and IDE you know and love to get to market fast, sharing one codebase across all platforms. This slide also covers basic XAML, so those who don't have any xaml experience could find it useful.
Duration(Slide+Demo) : 1hr 30min
10. Thousands of iOS and Android APIs
Public web APIs
Backend integrations
Third party libraries
Memory, CPU and network constraints
11. HTML - Write Once, Run Anywhere Approach
• Lowest common denominator
• Browser fragmentation
• Developing & designing for 1
platform, happen to get other
platforms
24. Xamarin.iOS does full Ahead Of Time
(AOT) compilation to produce an
ARM binary for Apple’s App Store.
Native Performance
Xamarin.Android takes advantage
of Just In Time (JIT) compilation on
the Android device.
26. Efficiency through shared code
More apps faster: Accelerated time-to-market
with up to 100% shared code.
Truly native cross-platform solution: Native
UI and performance, high-fidelity API access.
Easy scalability: Go from 1–100 apps with reduced
time and effort.
Fully integrated solution: Easily connect with
high value cloud services: MBaaS, data, MDM.
Native UI
Xamarin and C#
Shared Code
Native UINative UI
27. Efficiency through shared code
More apps faster: Accelerated time-to-market
with up to 100% shared code.
Truly native cross-platform solution: Native
UI and performance, high-fidelity API access.
Easy scalability: Go from 1–100 apps with reduced
time and effort.
Fully integrated solution: Easily connect with
high value cloud services: MBaaS, data, MDM.
Native UI
Xamarin and C#
Shared Code
Native UINative UI
28. Xamarin’s Unique Approach
• Native User Interface
• Native Performance
• Shared code across
platforms
• C# & .NET Framework
• Full API Coverage
29. Xamarin.Forms approach
✓ 40+ Pages, layouts, and controls
(Build from code behind or XAML)
✓ Two-way data binding
✓ Navigation
✓ Animation API
✓ Dependency Service
✓ Messaging Center
Shared C# Backend
Shared UI Code
39. Use a single API to generate native, platform-specific user
interfaces
At runtime, each Xamarin.Forms page and its
controls are mapped to platform-specific
native user interface elements
Xamarin.Forms UI with C#
58. Device Remoting
Tests are performed one at the time,
which consumes more time and delays
bugs detection
Automated Testing
Test on thousands of devices simultaneously,
saving lots of time and detecting
bugs more quickly
Approaches to Mobile Testing
60. Free 30 Day Trial - xamarin.com/university
Unrivaled Mobile
Development
Training
Live unlimited mobile development training from
mobile experts, in your time-zone, on your
schedule, and as often as you'd like.
Multiple Teams
Multiple Code Bases
Expensive & Slow
Positive = Great apps delivered to user’s platform
Negative = Development hampered by multiple code bases & fragmentation
Multiple Teams
Multiple Code Bases
Expensive & Slow
Positive = Great apps delivered to user’s platform
Negative = Development hampered by multiple code bases & fragmentation
Well there are several challenges that we must overcome as mobile developers including….
First let’s take a look at the shear number of configurations there are between iOS and Android. As iOS progresses this number is only set to increase, and on Android it is already a HUGE number of configurations to even think about testing.
iOS: 7, 7.1, 8, 8.1, 8.2
Device Fragmentation:
OpenSignal is a global app that publishes an annual report on Android device fragmentation based on the distinct Android device types that download their app. This is their August 2015 data, with an astonishing 24,000 device types using their app, up by 60% from just last year.
Different device operating systems, form factors, screen sizes, resolutions, chip sets, and manufacturer modifications make it difficult to know that your app will work well on all devices
The fragmentation isn’t just in the devices, but as we start to build on our applications you soon found out they are ever increasingly complex.
Unhappy Users
Unhappy Developers
Increase in Abandoned Apps
Limited to what is implemented
PhoneGap, Cordova, Telerik Platform
Silver (swift)
If you have ever developed for a Windows Platform before these .NET namespaces might look familiar.
However, if we go to a new platform such as Windows Phone or Store we have a new SDK to use and a new set of namespaces.
You can think of iOS and Android development the same with Xamarin. You can see we have all of our .NET namespaces and libraries, but Xamarin give us 100% api coverage of each iOS API in it’s SDK that we access view C#.
The same is true for Android as well.
There is no compromise on performance.
Xamarin apps look and feel native because they are native.
SCRIPT
When mobile devices first came out, companies had to jump in with gusto. And they did so with what we call the siloed , platform-specific approach. They hired specific teams to build apps for one platform. Objective C for iPHone. Java developers for Android. Etc.
The benefit is that your app is very tailored to the platform that your users are engaging with it. And that’s what users want.
The downside is there is a lot of redundant work that occurs. You have three teams effectively building the same product for a different audience. It’s a very slow way to innovate and update. For every bug you find, you have to fix it three times.
What came from this was another approach to development: the hybrid or web approach. This is where you’re using Web technologies and putting a mobile wrapper around it. The benefit is that you save money. You can use your current Web teams. However, the performance of these applications is sub par at best. Mark Zuckerburg is famous for saying that betting too heavily on HTML 5 was one of the worst business decisions Facebook made. It’s unfortunate that a lot of organizations went this direction and this resulted in poor adoption rates and wasted investments.
SCRIPT
When mobile devices first came out, companies had to jump in with gusto. And they did so with what we call the siloed , platform-specific approach. They hired specific teams to build apps for one platform. Objective C for iPHone. Java developers for Android. Etc.
The benefit is that your app is very tailored to the platform that your users are engaging with it. And that’s what users want.
The downside is there is a lot of redundant work that occurs. You have three teams effectively building the same product for a different audience. It’s a very slow way to innovate and update. For every bug you find, you have to fix it three times.
What came from this was another approach to development: the hybrid or web approach. This is where you’re using Web technologies and putting a mobile wrapper around it. The benefit is that you save money. You can use your current Web teams. However, the performance of these applications is sub par at best. Mark Zuckerburg is famous for saying that betting too heavily on HTML 5 was one of the worst business decisions Facebook made. It’s unfortunate that a lot of organizations went this direction and this resulted in poor adoption rates and wasted investments.
Native With Code Sharing ......
UI build natively per platform, leveraging C#
C# + XAML
C# + XML
C# + XIB
One shared app logic code base, iOS, Android, Mac, Windows Phone, Windows Store, Windows
Xamarin.Forms is much more that just a framework and includes everything you need to get up and running to build out full native applications.
If you are used to MVVM type of development you will feel right at home.
Xamarin recently introduced Xamarin.Forms a new library for cross platform user interface. We will touch up on this later, but this enables you to be highly productive, share code, but build out UI on each platform and access platform APIs.
With Xamarin.Forms you now have a nice Shared UI Code layer, but still access to platform APIs
You can start from native, pick a few screens, or start with forms, and replace with native later
First you have a set of pages for each screen of your application
There are things like Content, and MasterDetail which gives you a nice flyout
With a tabbed view you get the correct look on each platform
iOS on bottom, Android on top, and on WP you have a Pivot control
Inside of a page are layouts
A lot of options from something simple like a stack panel to complex and powerful grids
You have more than 40 controls, layouts, and pages to mix and match from.
These are all of the controls you have out of the box, you can of course create your own.
What is unique is you get the native control and have access to it.
Consider an Entry Field
On iOS it is mapped to UITextField
Android it is EditText
Windows Phoneit is a TextBox
Here is an example of Xamarin.Forms in action using C# in the code behind to create a login screen. You can see how each is rendered with the native controls on iOS, Android, and Windows Phone.
Approaches to Mobile Testing
Get started today with free 30 day trial of Xamarin at xamarin.com