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
Now that we’ve seen the awesome new stuff in Xamarin Studio for F# let’s go a bit further and actually use some of those improvements to our advantage. However, instead of just a regular blog post, I thought it’d be worthwhile to do a screencast for y’all.
You can view the demo code directly on GitHub. Enjoy everyone!
With the (almost) stable release of Xamarin Studio 6 comes a ton of great new improvements. I absolutely love the new dark theme! However, some huge improvements were made to the IDE for F# support, as well. Improvements that I feel may have gone without much notice. So I wanted to help get those improvements out in the open more as well as to recognize the folks that made all of this happen. At the time of this writing, I’m running the alpha build (v6.1) of Xamarin Studio.
Speaking of recognizing folks, huge shout out to Dave Thomas and Jason Imison for all their hard work in getting these improvements into Xamarin Studio. F# in Xamarin Studio would be nothing without these guys.
Xamarin Studio 6 now includes project templates for Xamarin Forms in F#. This is a pretty big update since, before, you couldn’t even add a PCL project in F# in Xamarin Studio.
With this you can start creating cross-platform mobile applications with Xamarin Forms in F#! While this was doable before, it is much easier without going through a few workarounds to get things working. Just select this project and the templates do everything for you.… Read more
The last day of ng-conf 2016 continued with lots of great information. Some highlights:
ng-transcludedirective now supports a name property and directives can specify multiple transclusion slots that correspond to these names. This allows Angular1 to come closer to how
ng-contenttags work in Angular2.
Some highlights of day two of ng-conf 2016:
angular2/coreis now referenced as
@angular/core. This change allows for better use of the ES2015 modules and better optimization when using the offline compiler.
I just finished up the first day of ng-conf 2016 and as usual, it has been a great informative conference. Thanks to the organizers, sponsors, and Angular team members for all your efforts.
Here are some highlights from today:
In this post, I want to focus on managing application state. In the example application, I tried to create an application that had a reasonably complex user interface (“complex” is relative here, of course). The user interface needed to show where changes in one area of the page had immediate impact on other areas.
If we look at the “edit view” of the application, there are three panels: the list of images grouped by tags, a details table of image information, and the image edit panel. User actions performed in one of these panels have an immediate effect on the other panels.
“The horror! Revoke his Angular2 license now!!”
I’m in no way saying this is a best practice or even a good practice. Including jQuery is not required or even desirable for most Angular2 applications. Angular1 had a dependency on jQuery or its own jQuery-lite version, but for Angular2 this is no longer the case.
jQuery will also cause problems for other scenarios, like pre-rendering the Angular2 application on the server or in a web worker, because jQuery components are expecting to work with the physical DOM. Plus it weights your application down with additional dependencies that will cause the application to load more slowly for a user.
But using jQuery was practical for this situation and gives me the chance to demonstrate how Angular2 can interoperate with existing web technologies. Let’s take a step back and look why jQuery might be worth considering in certain scenarios.
There’s been much discussion about creating general purpose user interface components (commonly called “widgets”). Think of widgets as resuable pieces of user interface that can help you to build your application, for example, a progress bar, a dynamic and sortable table view, menu bars, charts and graphs, etc.… Read more
Angular2 has a strong emphasis on components. An application is made up of a tree of components, starting from the root component and working down to child components. This helps to organize your application into logical and manageable pieces. Complex user interface can be broken down into smaller components, assembling them together, to better organize your application’s functionality and how it is presented to the user.
Components can be further categorized. Some components are just simple user interface components, for example like a date-picker widget or a simple user information card. These components are used throughout your application, but they don’t exercise your application logic. That work is delegated to other parts of the application. These components might be called “Presentation” (or “Dumb”) components.
Other components serve to organize and orchestrate the activities of child components and application services. These components know about the application logic. They might push application data down to child components and respond to events emitted by them. They might transform an event into a transition to a new application state. These components might be called “Container” (or “Smart”) components.