Occasionally I see this question pop up in various forms; usually an app developer has written some fairly clever code that relies on the
dynamic keyword in C#. Their code runs swimmingly on every other platform—and it also compiles just fine for iOS. But when they run the app on a physical iPhone or iPad they see runtime exceptions… often in strange and unexpected places. Finally, the problem gets tracked back to usage of
dynamic, but the question remains: “Why didn’t that work?”
Buried down in the Xamarin.iOS documentation, we can find a page that discusses the limitations of MonoTouch / Xamarin.iOS (https://developer.xamarin.com/guides/ios/advanced_topics/limitations/). On this page there exists some guidance regarding “Dynamic Code Generation” in which (among other things) it says that the Dynamic Language Runtime (DLR) is not allowed. OK, this seems related to the
dynamic keyword, but you might be wondering how, exactly. The topic mentions that this is somehow due to the
System.Reflection.Emit API not being available in iOS—but you clearly aren’t using that .NET feature, so what’s the deal?
It boils down to a security restriction in iOS. Apple does not allow apps to generate executable code at runtime, because this would be a potentially major security vulnerability.… Read more
I’d like to share a really awesome bit of code that I’ve been using in my XAML applications for a while now… there are many frameworks and examples out there, but I’ve not yet seen anyone else using this exact technique before…
If you are building app UIs using XAML, then you are more likely than not also using the MVVM design pattern. The general idea is that your code which handles application logic, business rules, etc. gets placed into ViewModel classes, and all visual widgets/controls get placed into XAML views. Typically we would have one View per ViewModel, but that’s not a requirement at all (more like a generalized observation), and in fact there are some situations where we might want to have multiple Views for the same ViewModel (or break a complex ViewModel into multiple parts while still connecting to a single View). The ViewModels are supposed to capable of standing alone, and we use data bindings and command bindings to connect the two. This way, we can unit test our ViewModels thoroughly, and (sometimes) allow UX designers to dictate the XAML layout directly.
That’s all fairly normal and typical.
As we dig a little more deeply into the mechanisms of data binding, we learn that part of the “magic” is achieved by way of the INotifyPropertyChanged interface (which includes only one thing – an event named PropertyChanged).… Read more
Xamarin Forms is a really great platform for mobile app development – we have used it on several apps now and had much better results than when trying to use the native SDK’s directly. Every now and then though you run up against a roadblock with the default renderer implementations where some feature (perhaps a key feature of your app) simply does not work the way it should. Secondary toolbars on iOS are one of those. I recently spent a couple of days trying to coax this feature into working properly before finally finding a solution (many other folks seemed to have simply given up on it).
Xamarin Forms supports the notion of Page-level toolbars. These are represented by the Page.ToolbarItems collection, and each ToolbarItem represents a clickable button that is hosted within the toolbar. In fact, there are two toolbars – the main “primary” toolbar that fills the right end of the navigation bar at the top of your screen, and also a “secondary” toolbar. You can only fit a few (two or three at most) toolbar items on the primary toolbar, and the rest are generally expected to go into the secondary toolbar. On Android this is done by adding an expansion button to the far right end of the primary toolbar which drops down a vertical menu containing the secondary toolbar items.… Read more
This post is about probably my least favorite part of mobile app development – figuring out and assembling all of the various images needed to build an application and publish it into the stores. Each platform has its own requirements for this, and often you will need to provide multiple resolution versions within each platform in order to handle varying pixel density ratios. Xamarin supports all of the necessary resource types of course, but it is still up to us as developers to include the right images in our projects.
For very simply apps this isn’t quite as big of a problem – but it becomes a huge headache for medium-size and large-size apps. To help make my life easier, I like to use a spreadsheet to identify all of the images needed along with the final image resolutions and preferred file names. This works great because I can give this spreadsheet to the UX designer and have them provide all of the assets – already sized and named appropriately so that I can just drop them right into my project. So let’s cover all of the various image types that an app might need – including both the minimum required images as well as optional ones.… Read more
Cloud Saturday is a new event for the Atlanta area, and we are currently looking for speaker submissions. The event is being planned for 9/26, and will be held in Alpharetta at Microsoft’s regional training facility. While Microsoft is a sponsor, this event is open to ALL cloud platforms. Amazon, Google, Microsoft and any other vendor platforms are equally welcome (and encouraged!) to have representation. As this is the inaugural event (we hope to hold this in future years as well), there are only a limited number of speaking slots available… so please sign up soon if you are interested in being a part of this event! We are accepting multiple submissions per speaker – however not all submissions may be selected, depending upon our ability to accommodate the additional sessions and/or the interests of keeping the event well-balanced.
Sessions can be technical in nature, or management oriented. We expect that our audience will include a healthy mix of developers as well as IT managers and architects.
Please visit http://atlanta.cloudsaturday.com/want-to-speak/to learn more or to sign-up as a speaker.
As Dave Baskin posted earlier this week, several of us from Wintellect were in attendance at CodeStock 2015 in Knoxville this weekend. Wintellect is proud to have been a sponsor of this year’s event, and we were also thrilled to have several of our consultants selected as speakers. Dave, Josh Carroll, Joel Cochran and myself all presented one or more topics each this year. Everyone’s talks received positive feedback from attendees.
While the rest of the team covered primarily web topics, both of my talks were on the cross-platform mobile platform Xamarin – an introductory level talk as well as a more advanced talk on custom renderers in Xamarin Forms. I was originally only scheduled to deliver the second talk, as another speaker was lined up for a Xamarin intro talk. However the other talk was cancelled at the last minute (illness I believe), and we were given the chance to fill in for them. Interest in both sessions was strong – even though there were some other very popular talks scheduled in the same time slots and our morning session didn’t even appear on the schedule until the evening before.
We covered a lot of ground in each session and had some great conversions – both during the talks as well as back at our sponsor table and in hallway conversations.… Read more
In the previous post I implemented a custom attached property to be used in Xamarin Forms XAML when a built-in accessory view is desired on a table cell. In this follow-up we will continue and build out the iOS renderer that is responsible for actually enabling the feature in our running application.
What about Android and Windows Phone – won’t they be affected too? That’s the beauty of the Xamarin Forms rendering model – it is up to each platform to decide how to natively implement the controls described in XAML markup. In this case, we have extended the existing XAML (not replaced it), and so the Android and Windows Phone renderers will simply just ignore the extensions unless we customize the renderers for those platforms as well.
Note: The following information comes through decompilation and inspection of the iOS renderers found in Xamarin.Forms.Platform.iOS (this assembly can be found in your Xamarin.iOS installation, or in your debug/bin output folder after compiling a Xamarin Forms project for iOS). I used JetBrains dotPeek to decompile the source from that assembly file.
The process of mapping a XAML
ListView to a native
UITableViewSource and the various Xamarin Forms cell types to
UITableViewCell objects is performed by a fairly complex orchestra of intertwined classes in the default iOS rendering system.… Read more
In my last few posts I introduced a simple app that lets you browse the various built-in font variations supported by Xamarin Forms. If you recall, the application adopted a “stack navigation” design, which is quite common in mobile applications. However, there is one small flaw with our implementation so far – on the iOS platform it is customary to indicate that a ListView/TableView cell can be used to “drill down” into the navigation stack by including a “disclosure accessory” on the far right end of each cell. This accessory can be seen in the iOS Settings app below (the small chevron icons in the right margin of each cell):
Now, we could simply change our cell templates to add a custom image aligned to the right edge – but that wouldn’t be 100% correct. A Xamarin Forms
ListView maps to the native
UITableView, and if you review the iOS programming guide for Table Views you can see that there is built-in support for these that is provided by the operating system. These built-in icons can vary from one version of iOS to the next, and by using them (instead of custom icons) we can be assured that our application will continue to look correct as the platform evolves.… Read more
Xamarin Forms allows us to write code once that targets all three major platforms – iOS, Android, and Windows Phone. But the default color palette for the platforms differ – iOS prefers a light background with dark text, while the default themes for Android and Windows Phone are the opposite of that. And unfortunately for us, that’s usually not good news. From a branding perspective, it is advantageous to have a consistent color palette between our application properties – no matter which mobile platform our application is running on. Furthermore, if we need to produce artwork (icons, glyphs, background images, etc.) for our app, then we would prefer to only need to do that work once.
The simplest and easiest way to provide that consistency among the three platforms is through themes. While Apple prefers that applications on their platform adhere to the visual theme of the operating system, both Android and Windows Phone offer ways to customize the theme elements. In my previous post, you saw how I used a custom Android theme to hide the Main Activity Icon while also switching the UI over to a light-background theme. In this post, we will do the same for Windows Phone.… Read more
In my previous post, I introduced a simple demo app that used the Stack Navigation Pattern. This is a standard pattern frequently used on all phone platforms to present hierarchically organized pages of information. In my demo app, it was used to navigate to each of the three detail pages from a main starting page. It is referred to as “stack navigation” because you can always return to the previous page.
On Windows Phone, this is done using the hardware “Back” button that resides below the touchscreen interface. On iOS devices, this is done using a UI button that is placed into the top navigation bar (on the left end of the bar). And on Android, both mechanisms are supported. There is a hardware button below the touchscreen as well as a UI button in the top navigation bar.
However, on Android the default behavior of a Xamarin Forms application is to display the application’s icon (the Main Activity’s icon) into this same area of the top navigation bar – and this behavior is fine for apps that don’t use stack navigation. But for apps that use stack navigation, this leads to a cluttered navigation bar which simply doesn’t look all that great (IMO).… Read more