Author: Charles Petzold
Pub Date: 2015
Size: 12 Mb
This second Preview Edition ebook, now with 16 chapters, is about writing applications for Xamarin.Forms, the new mobile development platform for iOS, Android, and Windows phones unveiled by Xamarin in May 2014. Xamarin.Forms lets you write shared user-interface code in C# and XAML that maps to native controls on these three platforms.
Code and XAML in harmony
Custom XAML-based views
The ScaryColorList program in the previous chapter listed a few colors in a StackLayout using Frame, BoxView, and Label. Even with just three colors, the repetitive markup was starting to look very ominous. Unfortunately there is no XAML markup that duplicates the C# for and while loops, so your choice is to use code for generating multiple similar items, or to find a better way to do it in markup.
In this book, you’ll be seeing several ways to list colors in XAML, and eventually, a very clean and elegant way to do this job will become clear. But that requires a few more steps into learning Xamarin.Forms. Until then, we’ll be looking at some other approaches that you might find useful in similar circumstances.
One strategy is to create a custom view that has the sole purpose of displaying a color with a name and a colored box. And while we’re at it, let’s display the hexadecimal RGB values of the colors as well. You can then use that custom view in a XAML page file for the individual colors. What might this look like in XAML?
Platform-specific API calls
DependencyService and the Portable Class Library
Can the technique illustrated in the DisplayPlatformInfoSap2 program be implemented in a solution with a Portable Class Library? At first, it doesn’t seem possible. Although application projects make calls to libraries all the time, libraries generally can’t make calls to applications except in the context of events or callback functions. The PCL is bundled with a device-independent version of .NET and closed up tight—capable only of executing code within itself or other PCLs it might reference. But wait: When a Xamarin.Forms application is running, it can use .NET reflection to get access to its…
The interactive interface
Keyboard and focus
Entry, Editor, and SearchBar are different from all the other views in that they make use of the phone’s onscreen keyboard, sometimes called the virtual keyboard. From the user’s perspective, tapping the Entry, Editor, or SearchBar view invokes the onscreen keyboard, which slides in from the bottom. Tapping anywhere else on the screen (except another Entry, Editor, or SearchBar view) often makes the keyboard go away, and sometimes the keyboard can be dismissed in other ways.
From the program’s perspective, the presence of the keyboard is closely related to input focus, a concept that originated in desktop graphical user interface environments. On both desktop environments and mobile devices, input from the keyboard can be directed to only one user-interface object at a time, and that object must be clearly selectable and identifiable by the user. The object that receives keyboard input is known as the object with keyboard input focus, or more simply, just input focus or focus.