Disclaimer: this is an automatic aggregator which pulls feeds and comments from many blogs of contributors that have contributed to the Mono project. The contents of these blog entries do not necessarily reflect Xamarin's position.

April 28

Welcome the New Xamarin MVPs!

Xamarin MVPThe Xamarin MVP title is awarded to outstanding community leaders who demonstrate exemplary commitment to helping others become mobile C# developers by sharing their passion, real-world knowledge, and technical expertise with developers all over the world.

The contributions made to the mobile developer community by these MVPs include, but are not limited to:

  • Writing great articles, books, and blog posts
  • Building amazing plugins and components
  • Presenting at developer user groups, conferences, and online
  • Contributing to the open source developer community
  • Actively growing their local Xamarin community through organizing Xamarin Dev Days, user group meetups, and other developer events
  • Helping developers online through our forums, on Twitter, and Stack Overflow, as well as other online social channels
  • Shipping awesome, beautiful native iOS, Android, and Windows apps

Today, please join us in congratulating these outstanding community leaders on becoming Xamarin MVPs! Thank you for your hard work and dedication to the mobile .NET/C# developer community. We appreciate it and we know our developers do, too.

Adam Pedley AdamP

Adrian Knight ak

Allan Pead
ap

Ben Ishiyama-Levy ben

Dan Ardelean
Dan

Daniel Krzyczkowski Daniel

Garry Whittaker
gw

Gill Cleeren
gc

Ivan Toledo
IvanToledo

M. Riyaz mr

Michael John Pena
mjp

Michael Zaletel MZ

Vulcan Lee
vlee

Vojtech Madr vm3

 

 

Find and connect with any of our Xamarin MVPs by heading over to the official Xamarin MVP website, or you can find an MVP near you by location with this world map of members from the program:

 

Want to become a Xamarin MVP?


If you’re already making awesome contributions to the mobile developer community or know someone who is, make a nomination by simply filling out this evaluation form.

The Xamarin MVP program runs all year long and comes with great benefits; there’s never been a better time to get out there and get active with your local Xamarin Community!

The post Welcome the New Xamarin MVPs! appeared first on Xamarin Blog.

April 27

Making Your Xamarin.Forms Apps Accessible

iOS, Android, and Windows all expose APIs for developers to build accessible mobile apps for everyone. We’re excited to announce that we’ve added new APIs for accessibility in Xamarin.Forms to make it even easier for developers to build accessible, cross-platform mobile applications. In this post, we’ll take a look at new APIs added to Xamarin.Forms that make it easy to build accessible mobile applications.

Accessibility APIs in Xamarin.Forms

Xamarin.Forms 2.3.4 provides a base set of hint-related accessibility APIs. They consist of the following:

  • Accessibility.Hint
  • Accessibility.IsInAccessibleTree
  • Accessibility.LabeledBy
  • Accessibility.Name

By defining these properties, we can utilize the underlying accessibility functionality in iOS and Android, such as VoiceOver.

Making the Xamarin Evolve 2016 App Accessible

The easiest way to dig into how these new APIs work is with a real-world example. Let’s take the LoginPage from the Xamarin Evolve 2016 mobile application and make it accessible using the new APIs in Xamarin.Forms. In this layout, we have the usual Xamarin.Forms elements such as Entry and Button. Prior to Xamarin.Forms 2.3.4, we would have to use platform effects or a custom renderer to utilize the accessibility APIs. With the new APIs, we just need to add a few properties and our mobile app becomes accessible:

<toolkit:EntryLine
        Text="{Binding Email}"
        Keyboard="Email"
        HorizontalOptions="FillAndExpand"
        Placeholder="email address"
        x:Name="EntryEmail"
        StyleId="EmailTextField"
        IsEnabled="{Binding IsNotBusy}"
        BorderColor="#ECECEC"
        Accessibility.Hint="Enter your email here"
        Accessibility.IsInAccessibleTree="true"
        Accessibility.Name="Email entry field">
        <toolkit:EntryLine.HorizontalTextAlignment>
            <OnPlatform x:TypeArguments="TextAlignment" iOS="Center"/>
        </toolkit:EntryLine.HorizontalTextAlignment>
</toolkit:EntryLine>

Run the code on a physical device with accessibility functionality enabled, and the value you provided for Accessibility.Hint will be spoken to the user. This uses VoiceOver on iOS; on Android, some controls, incuding Button, unfortunately don’t behavior properly for reasons pertaining to Android itself, although an element such as Slider will read a combination of the Hint and Name values.

To enable VoiceOver for iOS, navigate to Settings -> General -> Accessibility -> VoiceOver. For Android, install TalkBack which is very likely already installed on the device and can be enabled under Settings -> Accessibility -> Vision. Windows users can enable the Narrator under the Ease of Access option in Settings.

Remember, you’ll need to have Xamarin.Forms 2.3.4 added to all projects using Xamarin.Forms, including your iOS and Android projects. Note that the accessibility properties may not be available in IntelliSense, as these are attached properties.

Conclusion

As you’ve seen with the above example, adding just four properties to my control in XAML added hint-driven accessibility to my mobile apps. We encourage you to give these new APIs in Xamarin.Forms 2.3.4 a try, and let us know what you think! You can read more about the various accessibility features on each platform’s website (iOS, Android, Windows).

The post Making Your Xamarin.Forms Apps Accessible appeared first on Xamarin Blog.

April 26

Shopbox Uses C# to Empower Small Business Owners with the POS System of the Future

.NET powers mission-critical mobile apps, and Xamarin has customers ranging from Fortune 500 enterprises building multi-app portfolios to extend their business to mobile-only disruptors whose apps are their business. Some do both; for instance, Shopbox is an intuitive, tablet-based Point-of-Sale solution allows business owners to easily manage their entire business, from customer transactions to staff performance and analytics, deliver high quality customer service, and focus on tasks that grow their business.

After releasing platform-specific iOS and Windows apps, Shopbox re-evaluated its mobile strategy and chose C# and Xamarin as its go-forward mobile development language. Today, we’ve invited Shopbox CTO Alexander Ribin, to share how his team successfully transitioned from disparate teams and multiple complex code bases to delivering rock-solid iOS and Windows apps that customers love just in three months.

Tell us a little bit about your company and role.

Shopbox is an intelligent, cloud-based Point-of-Sale (POS) system. Our tablet-based apps, available on iPad and Windows tablets, integrate with traditional POS hardware (printers, card terminals, scanners), allowing store owners to replace old-fashioned cash registers.

Shopbox started five years ago as a coupon-redeeming app for shopkeepers and, like many start-ups, pivoted to better establish product-market fit. After a startup finds its product-market fit, it’s time to make the shift toward becoming a “real company,” and I joined Shopbox as CTO eight months ago with the main objective of bringing the company to the next level.

My team is very talented but, due to the previous pivot, the infrastructure was complicated and full of legacy code that resulted in slower development. My first project was to reduce complexity and establish an agile, structured, and reliable delivery process. For me, a great day at work is a mix of three things: (1) dedicating time to making decisions on future development/feature(s) (2) reviewing code and helping my team, and (3) reflecting and improving what we have.

Describe your apps and what prompted you to build them. How has your platform strategy evolved over time?

Our vision is to simplify running a small business, gathering all necessary administrative functions into one place. We believe Point of Sale systems are the center of any small business, making them the most logical place to create a unified view for business information. We launched Shopbox in April 2015 for iPad tablets (written in Objective-C).

In 2016, we won a contract with Friends Arena (Sweden’s national arena, which holds 65K+ visitors and processes up to 40K transactions per event) to supply 350 cash registers for its food and beverage kiosks. As part of the agreement, we committed to delivering our system on Windows.

We had three months to develop the solution from scratch. We developed a standalone Windows version, with different requirements and unique features, completely separate from our iOS app, which only increased the complexity of our systems. After the project, we had two different mobile app code bases, a web solution, and two different versions of our API.

To illustrate, this was our system diagram:

Shopbox Diagram

We’d make changes in one place, but never had a clear picture where we might see consequences, making it almost impossible to provide a stable, reliable solution for our customers.

Why did you choose Xamarin?

After the Friends Arena project, we needed to reduce our system’s complexity, both in terms of the amount of code that needed maintenance and the number of repositories and code bases, as the friction usually lay between contact points.

We had a few main requirements:

  • We support nuanced, industry-specific hardware, and we needed the flexibility to make bindings to native libraries and connect to the hardware
  • Refusal to compromise on native UX. Our app is core to our customers’ businesses and delivering an amazing user experience is central to our mission, so slow response, buggy UI, or long loading times are non-starters.
  • As a startup, time to market is critical. We couldn’t afford to spend more than a few months streamlining our code, so we wanted a solution that allowed us to reuse one of our existing code repositories, either in Objective-C or in C#.

A native app is the best you can make, in terms of user experience and response time. In our case, native also means the ability to connect to platform-specific libraries, allowing us to work with esoteric hardware. Since Xamarin compiles code to platform-specific native languages, you achieve the same native results, both in terms of UX and speed, and it’s straight forward to use bindings for platform-specific hardware SDKs.

When you look at the alternatives available, it’s very clear that no other solution delivers on all of our crucial requirements, so our choice to use Xamarin was natural.

You recently moved to Xamarin; how are things looking now?

We’ve increased our front end development speed by more than 100%. It took only three months from our decision to use Xamarin to the first release of our rebuilt apps, which is very short considering we spent two years developing our software. Any time we “lost” making the change was paid off quickly.

We’re able to reuse approximately 70% of code across platforms; this will likely be even higher after we finish our transition to Xamarin.Forms. For our initial release, we used our existing UI files to get to market quickly but we’ll use Xamarin.Forms going forward.

Shopbox for iOS on iPad

How did you get up to speed with cross-platform mobile development?

Personally, I started coding when I was 15, and I “speak” over 20 programming languages, from Assembly to C# and web stack and including dinosaurs like Ada and VB6. Before joining Shopbox, I served as a developer in the Israeli army for three years and led a web development agency for seven years. We delivered custom web solutions, ranging from simple website to e-commerce platforms with unique specs to startups with big ideas and bigger requirements.

We have three front end developers. Before the transition, one developer focused on the Windows solution, one on the iOS solution, and the team leader split his time between each platform, depending on needs. Now, the entire team works on the same code base. We’re literally moving two times faster.

On top of developing faster, we create fewer bugs and conflicts, which allows us to spend even more time developing new features rather than fixing bugs.

We’re moving to a Continuous Delivery model as we speak. We plan to have four different environments running in parallel: dev, alpha test, beta test, and production. Each version of our app will spend one sprint cycle in each of the stages, increasing our release quality and allowing us to deliver a stable release every two weeks.

Since this could be very time consuming and error-prone if done manually, we’re using an automated process driven by Jenkins and HockeyApp. We’ll merge code between the different environments, as well as build and distribute to testers and public app stores at the click of a button.

What is the most compelling or exciting aspect of your app?

Per our UX/UI Designer, Frederik Smal,

“We provide our customers with a much more user-friendly interface than many other competitors. We use minimalistic, yet powerful, visual effects that naturally guide the user, from selecting a product until the end of the transaction (where the payment happens).

Compared to traditional POS systems, which were designed to fulfill just one purpose, we focus on the interaction between the user and our software. We provide an intuitive software that the user doesn’t need to learn how to use by implementing a logical hierarchy for each element and following standard design principles.

Last but not least, we focus on our app’s visual value: we believe that modern POS systems should be reliable, usable, and smart, but at the same time the user should feel a certain amount of joy while using it.

Mobile quality and ease of use are extremely important, and we can’t compromise. Our app is mission-critical to our customers; the smallest issue results in huge business impacts. Imagine yourself standing behind the counter during rush hour with a line of customers waiting to buy your goods, getting increasingly more frustrated as you try to fix something in your POS system.

What have your users said about your app? 

We had clients text us saying that they really loved the update after we released our Xamarin-based app, which had never happened before.

Internally, the front end team is much more collaborative now that they work on the same code. Our CEO, Christian Elbek recently remarked,

I really appreciate that both platforms are more aligned, and I can see a great improvement in output with the ‘one app’ approach. Quality has also improved immensely, which is essential for us since our app runs the core of the business for our users.

How are you incorporating user feedback into future releases?

Our roadmap is mostly driven by business needs. We divide feedback into two groups: bugs/usability issues and future development. The first category goes directly from our customer support team to our development pipeline, while we discuss the second in our roadmap planning meetings. We combine our ideas with requirements from Business Development, Sales, and Marketing team members and then prioritize, narrow down, and focus on the top of the list.

What’s your team planning to build next?

Our next big project is moving our backend from a Yii2 PHP framework on AWS to C# and Azure servers. For the client side, we’re focusing on new markets and integrations with more local hardware providers.

The really exciting features will come afterwards, when we we’ll start using intelligent APIs and analytics to offer business insights, such as sales projections, optimizing staffing, and automatically ordering ingredients, based on existing stock and expected sales.

What advice do you have for developers or organizations who are just starting mobile development?

Keep it as simple as possible. Always weigh every feature or change, not only by the time it will take you to build and implement, but by the amount of complexity it will introduce.

Try to push as much as possible out of the core into existing infrastructures, and keep your code as minimal as possible. For example, we make sure that localization happens only on the UI level, rather than sending localized number formats between client and server (Nordic countries use a comma rather than a decimal). More generally, another example would be setting up “creation” and “update” date records to be updated by the database, rather than writing C# code to do so.

When choosing which technology to use, start by mapping your needs to identify which technology best fits with your requirements. In our case, after mapping our needs, the choice to use Xamarin was obvious.
 
 
Visit xamarin.com/customers to learn how our customers across industries and geographies deliver amazing mobile apps and xamarin.com/download to start building your own.

The post Shopbox Uses C# to Empower Small Business Owners with the POS System of the Future appeared first on Xamarin Blog.

April 25

How we do trunk-based development: answering frequent questions

We have reached the 4th installment of the series telling how we implement trunk-based development at Codice today. Previously, we covered:

Today, we will answer some common questions that were not covered before. So far, we just described the ideal cycle, but never told you what happens if tests fail, the various reasons why a task/branch can be rejected, what to do when a branch can’t be merged or how to handle broken builds. These are the topics we cover today.

Visual Studio 2017 for the Mobile Developer

Visual Studio is the world’s best IDE, and it just got better with the recent launch of Visual Studio 2017. This release is packed full of awesome features including live unit testing, new refactorings, code suggestions, and C# 7 support, as well as features that help mobile developers build better mobile apps, faster. In this blog post, we’ll take a look at some of the features that make mobile development a breeze in Visual Studio 2017.

Getting Started with Visual Studio 2017

The Visual Studio team has completely revamped the installation experience from the ground-up. The new install experience is intuitive, touch-friendly, and most importantly, we now have the option of a low drive-space footprint, selecting only the tools we require. We can select a Workload that best suits our requirements, such as Mobile Development with .NET, Universal Windows Platform, or .NET Core. Only the required components will be installed, helping to keep the download and final install sizes at a minimum. You can get started faster than ever, plus ensure that your install only contains exactly what you need to get started.

Project Templates

Many mobile apps at their core are simply list views with data pulled down from the web. In this release, we created new templates for Visual Studio 2017 to reflect this reality. By clicking just a few buttons, you can bootstrap your next mobile project with a mobile app for iOS, Android, and Windows 10 that includes tabbed navigation, MVVM, settings, and more. By clicking “Host in the cloud,” you can then take your mobile project to the next level by provisioning a backend for it, complete with client-side code for online/offline synchronization and automatic conflict resolution.

XAML IntelliSense

Opening any Xamarin.Forms XAML document now provides a significantly improved IntelliSense experience in Visual Studio 2017. The new code completion engine supports bindings, custom properties, custom controls, converters, and much more.

IntelliSense comes to Xamarin.Forms XAML in this release, making you a more productive developer.

Forms Previewer

The Xamarin.Forms Previewer gives us a “WYSIWYG” view of what our app will look like on device, as well as live updates of our changes. Visual Studio 2017 features many enhancements to the Xamarin.Forms Previewer to increase the range of supported controls and XAML constructs. This is a huge time saver in comparison to re-deploying to our devices to see changes.

Archiving Tool

Once we’ve developed, debugged, and tested our app, then comes the task of publishing to the app store(s). The Android Archive Manager provides a seamless app publishing process by guiding us step-by-step through the process without ever leaving Visual Studio 2017.

Inspector

The Xamarin Inspector is a tool for Visual Studio Enterprise customers that allows you to make changes to your user interface and instantly see the results. For example, we don’t need to re-run the application to see how a font change will alter the look and feel of our app; we can simply run the app with Inspector and see changes on the fly.

iOS Simulator for Windows

The iOS Simulator for Windows is another feature in Visual Studio 2017 Enterprise edition. It makes perfecting your app a breeze by allowing you to view the iOS Simulator without having to jump back to your Mac.

Profiler

Xamarin Profiler is a tool designed to detect memory leaks, unused resources, etc. Visual Studio Enterprise users can leverage the powerful features of Profiler to catch these issues before they make their way to users.

Test Recorder

Xamarin Test Cloud allows us to test our apps on real physical devices to see how they perform in the real world. This requires writing test scripts. Visual Studio Enterprise users can use Xamarin Test Recorder to record tests and run them on a multitude of devices in the Xamarin Test Cloud.

Wrapping Up

If you haven’t yet taken the dive into Visual Studio 2017, you should definitely give it a try today to take advantage of the many new features and enhancements for both .NET and mobile developers.

The post Visual Studio 2017 for the Mobile Developer appeared first on Xamarin Blog.

April 24

Implementing Push Notifications in Your Android Apps

An important feature of almost every app is the ability to support push notifications. With push notifications, you can update your users without requiring the app to run at all times or having it poll a server, potentially running down the battery. With the introduction of Firebase Cloud Messaging (FCM), Google made it a little bit easier to implement push notifications in Android apps. FCM is the new and improved version of Google Cloud Messaging (GCM) that you can use to send remote notifications to your client app. For apps that will be targeting multiple platforms or need to take advantage of advanced push operations (like segmented push), we can use FCM with Azure Notification Hubs.

Unlike GCM, FCM takes care of most of the underlying messaging plumbing for you. With FCM, you no longer have to write code to register your app or include retry logic to update subscription tokens. You can add basic FCM push notifications to your app by doing the following:

  1. Install a couple of Xamarin.Android NuGets and a credentials file.
  2. Add a couple of <service> declarations to your AndroidManifest.xml.
  3. Write a few lines of code to pull it all together.

Also, instead of writing a test program to send notifications, you can use the new web-based Firebase Console to send test notifications to your app.

Today, we’ll take a look at how to use the Xamarin.Firebase.Messaging package to build FCM-based push notification features into your app.

Set Up Firebase Cloud Messaging

Before you can use FCM services in your app, you have to create a Firebase Project in the Firebase Console. After you log in, click CREATE NEW PROJECT, enter a project name, and click CREATE PROJECT:

Next, click Add Firebase to your Android app. When prompted, enter the package name for your app and click REGISTER APP:


When you click REGISTER APP, credentials are automatically generated for your app to access Firebase servers. These credentials are packaged in a file called google-services.json, which is automatically downloaded after you click the REGISTER APP button. Save this file, as you’ll need it later!

Add Packages to Your Project

Next, you’ll need to add two Xamarin NuGet packages to your app. Start the NuGet Package Manager (in Visual Studio, right-click References in the Solution Explorer and select Manage NuGet Packages), browse for Xamarin.GooglePlayServices.Base, select it, and click Install.

The Google Play Services package must be installed in order for FCM to work. Next, do the same for Xamarin.Firebase.Messaging:

Extra dependency packages will be installed for each of these packages.

Also, make sure that you have the Google Play Services APK installed on your Android device. Firebase Messaging uses the Google Play Services APK to communicate with Firebase servers.

Add the Google Services JSON File to Your Project

When you created a new project in the Firebase Console, you downloaded a google-services.json credentials file–it’s time to plug that file into your app!

Copy google-services.json to your project folder and add it to your project (in Visual Studio, you can click the Show All Files icon in the Solution Explorer, right-click google-services.json, then select Include in Project).

Save changes and close the Solution. Re-open the Solution and set the Build Action for google-services.json to GoogleServicesJson (in Visual Studio, the Build Action pull-down menu is in the Advanced section of the Properties pane):

Now that google-services.json is part of your project, the Xamarin build process can extract the credentials and merge them into the generated AndroidManifest.xml file. Xamarin.Firebase.Messaging uses these credentials to access Firebase services.

Add an Instance ID Receiver

Your client app has to first register with FCM before it can receive push notifications. The way this works is that Xamarin.Firebase.Messaging contacts FCM, sends it credentials, and gets back a registration token. This token, which is updated on a regular basis, is used to create a secure channel to Firebase servers. You can also forward this token to your app server so that it can communicate with Firebase.

Your client app must implement a FirebaseInstanceIdService to handle the creation and updating of registration tokens. This is actually a lot simpler than it sounds, as you’ll see next.

Declare the Instance ID Receiver in the Android Manifest

Edit AndroidManifest.xml (under Properties in the Solution Explorer) and insert the following <receiver> elements into the <application> section:

<receiver
    android:name="com.google.firebase.iid.FirebaseInstanceIdInternalReceiver"
    android:exported="false" />
<receiver
    android:name="com.google.firebase.iid.FirebaseInstanceIdReceiver"
    android:exported="true"
    android:permission="com.google.android.c2dm.permission.SEND">
    <intent-filter>
        <action android:name="com.google.android.c2dm.intent.RECEIVE" />
        <action android:name="com.google.android.c2dm.intent.REGISTRATION" />
        <category android:name="${applicationId}" />
    </intent-filter>
</receiver>

This declares the necessary receivers that will be used for managing registration tokens.

Add Internet Permissions

If your app does not already have the INTERNET permission enabled, enable it under Properties > Android Manifest > Required permissions:

Implement the Firebase Instance ID Service

Now it’s time to write some code! Add a new C# file to your project (in Visual Studio, right click your project name and select Add > New Item > Class). Give it the name MyFirebaseIIDService.cs and input the following code:

using System;
using Android.App;
using Firebase.Iid;
using Android.Util;
namespace FCMExample
{
    [Service]
    [IntentFilter(new[] { "com.google.firebase.INSTANCE_ID_EVENT" })]
    public class MyFirebaseIIDService : FirebaseInstanceIdService
    {
        const string TAG = "MyFirebaseIIDService";
        public override void OnTokenRefresh()
        {
            var refreshedToken = FirebaseInstanceId.Instance.Token;
            Log.Debug(TAG, "Refreshed token: " + refreshedToken);
        }
    }
}

Change the namespace FCMExample above to the namespace of your app.

That’s all there is to it!

The OnTokenRefresh method is invoked when the registration token is created or changed. Because the token is logged to the Output window whenever it’s updated, you’ll be able to see it while the app is running. You’ll enter this token into the Firebase Console when you’re ready to send a test notification to your app.

Try it!

Now that your app has enough functionality to receive background notifications from FCM, it’s time for a test drive. Before you build your app, make sure that its package name matches the package name that you entered into the Firebase Console when you created your Firebase project.

Rebuild the app, run it, and watch the Output window until the token is displayed. For example:

Copy this token to the clipboard; you’ll paste it into the Firebase Console in the next step.

Send a Message

Sign in to the Firebase Console, select your project, click Notifications, and click SEND YOUR FIRST MESSAGE:

On the Compose message page, enter in a message under Message text. Select Single device as the target and paste in the registration token that you copied from the IDE Output window:

Before you click SEND MESSAGE, background your app (you can tap the Android overview button and touch the home screen). Click SEND MESSAGE in the Firebase Console when you’re ready. When the Review message dialog is displayed, click SEND. The notification icon should appear on the Android device:

Open the notification to view the message; the notification message should be exactly what you typed into the Firebase Console:

Congratulations, you’ve just sent and received your first FCM push notification!

Learn More

This simple example only touches the surface of what you can do with FCM and push notifications using Visual Studio. To learn more about Firebase Cloud Messaging with Xamarin.Android for Visual Studio and other platforms, be sure to read Firebase Cloud Messaging and Remote Notifications with Firebase Cloud Messaging. The FCMNotifications sample app is also a good place to borrow code from if you’re building an app that uses FCM push notifications.

The post Implementing Push Notifications in Your Android Apps appeared first on Xamarin Blog.

April 21

Podcast: Building Up to Build

In this episode of the Xamarin Podcast, I’m joined by James Montemagno, Principal Program Manager for Mobile Developer Tools at Microsoft, to discuss what is new for Xamarin developers, including new features in the latest Visual Studio for Mac preview, Xamarin.Forms 2.3.4/2.3.5-pre, and updates to Visual Studio Mobile Center. Be sure to download today’s episode from your favorite podcasting app.



Subscribe or Download Today

Keeping up with the latest in .NET, C#, and Xamarin is easier than ever with the Xamarin Podcast! Cohosts Pierce Boggan and James Montemagno cover topics relevant to Xamarin developers, from designing mobile apps to identity management. Be sure to subscribe to the Xamarin Podcast on iTunes, Google Play Music, Stitcher, or your favorite podcast app you use to ensure you don’t miss an episode.

The post Podcast: Building Up to Build appeared first on Xamarin Blog.

The End of IKVM.NET

After almost fifteen years I have decided to quit working on IKVM.NET. The decision has been a long time coming. Those of you that saw yesterday’s Twitter spat, please don’t assume that was the cause. It rather shared an underlying cause. I’ve slowly been losing faith in .NET. Looking back, I guess this process started with the release of .NET 3.5. On the Java side things don’t look much better. The Java 9 module system reminds me too much of the generics erasure debacle.

I hope someone will fork IKVM.NET and continue working on it. Although, I’d appreciate it if they’d pick another name. I’ve gotten so much criticism for the name over the years, that I’d like to hang on to it 😊

I’d like to thank the following people for helping me make this journey or making the journey so much fun: Brian Goetz, Chris Brumme, Chris Laffra, Dawid Weiss, Erik Meijer, Jb Evain, John Rose, Mads Torgersen, Mark Reinhold, Volker Berlin, Wayne Kovsky, The GNU Classpath Community, The Mono Community.

And I want to especially thank my friend Miguel de Icaza for his guidance, support, inspiration and tireless efforts to promote IKVM.

Thank you all and goodbye.

April 20

Requesting Reviews with iOS 10.3’s SKStoreReviewController

Asking your users to review your app is never easy, and there was never an intuitive way to do it. Developers were left to constantly prompt users to review the app with pop ups or by putting a Leave Review button somewhere hidden in the settings, as I have done for many years (here is a quick blog to show you how to do it). Starting on iOS 10.3 this has all changed with the introduction of the SKStoreReviewController, which controls the process of requesting App Store ratings and reviews from your users with a streamlined, in-app dialog. This useful feature is also extremely easy to implement:

if(UIDevice.CurrentDevice.CheckSystemVersion(10, 3))
{
  SKStoreReviewController.RequestReview();
}

Just like that, we get this great looking rating screen:

The MyDriving app using the new StoreKit App Store review APIs.

Important Details

There are some caveats to keep in mind with the SKStoreReviewController, mainly that it isn’t guaranteed to actually show the screen; iOS decide this. On average, it appears the dialog will come up three or four times a year when requesting. As such, you should do some research and only request after your users have used the app for some time. When you’re in development, though, the ability to test the dialog will always be displayed, when your app is in TestFlight it will never be displayed.

Opening the App Store

Finally, this dialog is governed by the App Store policy, which means it should not be called in response to a user action or button tap. This is best reserved for putting in a dedicated Leave Review option somewhere in the app. Apple has updated the mechanism to navigate your users directly to the App Store review page for your app by appending action=write-review to the App Store product URL, as below:

public void OpenStoreReviewPage(string appId)
{
  var url = $"itms-apps://itunes.apple.com/app/id{appId}?action=write-review";
  try
  {
    UIApplication.SharedApplication.OpenUrl(new NSUrl(url));
  }
  catch (Exception ex)
  {
    Debug.WriteLine("Unable to launch app store: " + ex.Message);
  }
}

Learn More

You can read about all of the APIs introduced in iOS 10 and iOS 10.3 on our documentation portal along with a full guide to requesting app reviews with this new mechanism.

The post Requesting Reviews with iOS 10.3’s SKStoreReviewController appeared first on Xamarin Blog.

April 19

2² Decades

Several years ago when we were in 100 robots together, Max was celebrating his 40th birthday. When I said that mine would be in 2017, it felt like an impossibly far future date, but, after what feels like the blink of an eye, here we are.

Along with many other lovely gifts I received this morning was a book with the subtitle Whatever happened to Generation X? by Tiffanie Darke complete with a bright yellow acid house cover and a quote by Douglas Coupland on the cover.

I’ll read the book when I go to Simon and Pinar’s wedding next month, but I’ll share my immediate reaction now. Despite the term being popularised by Coupland’s book, whatever did happen to generation X we won’t read it in a book. We’ll read and write about it on the web we built.

While I remember my parents freaking out when I wanted to wear a bright yellow acid house badge to school, at the time I was more in to loud guitar music like Nirvana and Blur. From the perspective of loud guitars it felt like I’d missed the party: Metalica’s Master of Puppets was already receading in to the rear view mirror and Led Zeppelin firmly in my parents era. While we didn’t have The Beatles though, I did have computers.

There are plenty of people who would argue that I missed the boat there too: Boolean algebra was developed in 1848; the Halting Problem proved to be undecidable over Turing machines in 1936 and Quicksort was developed in 1959. While the Infer team refused to give up at the halting problem and are now producing amazing real world results using static analysis, a lot of computer science was finished before I was born.

My kind of computers weren’t huge machines crunching numbers and doing maths though, they were small pieces loosely joined. Connecting to things and each other they didn’t operate on maths, but changed the world or built new ones. They automated my physics experiments so that I could spend more time kissing Ali in the common room, helped reverse engineer Grand Theft Auto maps and automated synthesiser parameters when I didn’t have real controls for them.

They let me record hours of music and made writing books, making films and recording music accessible to everyone. While that made lives harder for those trying to make a living from their art it helped many more lives flourish. Napster may have made Metallica pretty upset, but the french horn player from my school could plunder the past for funk loops to accompany his synthesisers.

The DIY explosion gave us hip-hop and a million flavours of dance music and the networks to share it. Eventually it also gave us digital versions of the Beatles and, now I have been able to download and listen to it all, I’m convinced they have nothing to top the Aphex Twin.

The same democratization of tools meant that as a software engineer I could scratch an itch and choose to build my own service on top of world class open source software or work for one of the companies that became huge making the web easier to use. I’ve seen enough of how the startup sausage is made to know that a lot of the glitter is not gold, but owning the means of production means I at least have the choice to strike out on my own.

Climate change may mean that our real world horizons are closer and the piles of stuff we collect smaller, but the virtual vistas we can explore are ever growing.

When I watch my children grow up with YouTube it’s amazing to think about what they will accomplish in the future. If they want to do something, they watch it, learn it and do it. Nothing is unknown and nothing is impossible. They’re incredible, which is lucky, as together we’re going to have to save the world.

These thoughts are my own. They don’t represent my employer. They don’t attempt to speak for my generation. I write them and share them because I can and because I want to. Someone might read them and comment on them or link to them to build a web. Thats how my generation works and that’s what we built. We may not have had the Beatles, but I’m OK with that.

Preview: Bringing macOS to Xamarin.Forms

Preview

It’s amazing to think that you can now have a running native macOS application with just a few tweaks to a Xamarin.Forms solution. And I have to say “application” because that’s desktop, right?

As I featured in last week’s Xamarin.Forms 2.3.5 pre-release announcement, macOS support in Xamarin.Forms is now in Preview. Let’s run through adding this new project to an existing Xamarin.Forms solution, the hurdles you may face, and the current and future state of the platform features.

Configuring a macOS Project

Developing for macOS is a Mac only feature, so the same rules apply as when you are doing a Xamarin.Mac application. There is an excellent Xamarin.Mac guide here that covers the prerequisites.

When the time comes for you to integrate your Xamarin.Forms macOS project into a continuous integration system, rest easy that you can build for macOS on Windows just as you can now for iOS.

Add a Cocoa App Project

Until Xamarin.Forms templates adds a Cocoa App, we can easily add it ourselves. To do that in Xamarin.Studio or Visual Studio for Mac, add a new project to the solution and choose Mac > App > Cocoa App.

Adding macOS Project

Configure the Project

The Cocoa App template is configured with a storyboard implementation, which you won’t need. You may leave it there, but you’ll end up with two windows when your application runs.

Here’s the quick list of what you need to do:

  • Add the Xamarin.Forms 2.3.5.233-pre1 pre-release NuGet
  • Reference your Xamarin.Forms project (shared or PCL)
  • Import any assets such as images or fonts
  • Edit info.plist and remove the source entry (NSMainStoryboardFile)
    info.plist
  • Update Main.cs to initialize the AppDelegate

    static class MainClass
    {
    	static void Main(string[] args)
    	{
    		NSApplication.Init();
    		NSApplication.SharedApplication.Delegate = new AppDelegate();
    		NSApplication.Main(args);
    	}
    }

  • Update AppDelegate to initialize Xamarin.Forms, create a window, and load the Forms App
    • If you have other dependencies that need to be initialized, do that here as well.

[Register("AppDelegate")]
public class AppDelegate : FormsApplicationDelegate
{
	NSWindow _window;
	public AppDelegate()
	{
		var style = NSWindowStyle.Closable | NSWindowStyle.Resizable | NSWindowStyle.Titled;
		var rect = new CoreGraphics.CGRect(200, 1000, 1024, 768);
		_window = new NSWindow(rect, style, NSBackingStore.Buffered, false);
		_window.Title = "Xamarin.Forms on Mac!";
		_window.TitleVisibility = NSWindowTitleVisibility.Hidden;
	}
	public override NSWindow MainWindow
	{
		get { return _window; }
	}
	public override void DidFinishLaunching(NSNotification notification)
	{
		Forms.Init();
		LoadApplication(new App());
		base.DidFinishLaunching(notification);
	}
}

Run it!

With the macOS project as the startup, run it. Voila! You now have a native macOS application!

Example of Sample Weather App

What’s Next?

Now that you have an app, it’s time to put on your UX Designer hat and start exploring the changes you need to feel more at home in this new desktop environment.

Styling

Take a run at styling your Xamarin.Forms UI for macOS. The same styling used on mobile may not look right. This is easily updated!

With recent changes made to OnPlatform you can now target any number of platforms. That includes macOS.

<Button.TextColor>
	<OnPlatform x:TypeArguments="Color">
		<On Platform="iOS" Value="White"/>
		<On Platform="macOS" Value="White"/>
		<On Platform="Android" Value="Black"/>
	</OnPlatform>
</Button.TextColor>

Note you may also double up on platforms like <On Platform="iOS, macOS" ...>.

Window Size and Position

Is the launch window too big? Too small? Launching in an odd position on screen? You can adjust all of this in the AppDelegate on this line:

var rect = new CoreGraphics.CGRect(200, 1000, 1024, 768);

Known Issues

This is a Preview, so you should expect that not everything is production ready. Below are a few things you may encounter as you add macOS to your projects.

Not All NuGets are Ready for macOS

In order to work in a macOS project, packages must target xamarinmac20. You may find that some of your beloved libraries do not yet support macOS. What can you do? Kindly send a request to the project’s maintainer to add it. Until they have support, you may need to look for alternatives.

Xamarin.Forms Features

This preview has amazing coverage of Xamarin.Forms UI and features, but there are some known gaps to be aware of.

Not Yet Implemented:

  • OpenGlRenderer
  • ListView – ScrollTo, UnevenRows support, refreshing, SeparatorColor, SeparatorVisibility, Footer
  • ViewCell – IsEnabled, ForceUpdateSize
  • Image – Aspect
  • Picker – Bindable / Observable implementation
  • MasterDetailPage – BackgroundColor
  • TabbedPage – BarBackgroundColor, BarTextColor
  • TableView – UnevenRows
  • WebView – Most WebNavigationEvents
  • Navigation – InsertPageBefore

Send Your Feedback!

Add a macOS project and the Xamarin.Forms 2.3.5.233-pre1 pre-release to your solutions today and let us know what you think. What do you feel is missing? What problems do you encounter?

For a quick start, you can grab the WeatherApp I updated on GitHub: https://github.com/xamarin/xamarin-forms-samples/tree/forms-macos-preview/Weather

Join the macOS discussion in the Xamarin forums.

The post Preview: Bringing macOS to Xamarin.Forms appeared first on Xamarin Blog.

April 18

Guest Post: Adding a Calendar to Your Xamarin.Forms Apps with the Telerik Calendar

This is a special guest post from the Progress team at Telerik, the makers of the Telerik UI suites. Speaking on behalf of these awesome engineers of developer tooling is Sam Basu, a Developer Advocate for Telerik products and Xamarin aficionado. You may find him on Twitter as @samidip.

Celendar in action gif

Are you already building cross-platform native mobile apps using Xamarin.Forms? If so, great job picking your technology stack! After all, where else could you reuse your skills in C#/XAML to make apps that run on every platform with a truly unified single codebase? While Xamarin provides a vast array of frameworks, IDEs, and integrations, apps may sill need controls outside of those included in Xamarin.Forms. Rather than building your own custom control, developers may prefer to grab a well-engineered, performant UI control out-of-the-box from a service such as Telerik to help ship apps faster. Think of a polished UI as your must-have “wow” factor; that’s what you’ll get with Telerik UI for Xamarin.

Calendars keep our lives organized and productive; everyone uses them and increasingly so in digitally, so it’s no surprise that your mobile app may need to display a calendar and manage events. Turns out, however, calendar UI is tricky business, and the little details make all the difference.

The Telerik Calendar in UI for Xamarin is designed so you can offer your users the ultimate in productivity in your apps with various calendar scenarios. Yes, these are truly native calendars on every mobile platform, simply rendered through the Xamarin.Forms abstraction. The Telerik Calendar not only capitalizes on all of the innate benefits provided by native UI, it also exposes properties/events in C# to allow developers full customization and flexibility. This post introduces Telerik UI for Xamarin and then dives head first into leveraging the Telerik Calendar to explore all of the available customization options for developers.

Telerik UI for Xamarin

Telerik UI for Xamarin is a collection of Xamarin.Forms controls and Xamarin bindings built on top of the native Telerik UI for iOS and UI for Android suites. The Xamarin.Forms controls also utilize controls and features from the Telerik UI for UWP, providing a common API that allows the developer to use the native Telerik components on all three mobile platforms (iOS / Android / Windows) using a single shared code base. UI for Xamarin provides rich and performant UI controls out-of-the-box, so that you can focus on delivering app features using functional UI components.

We know developers don’t always trust high-octane words, though, right? You can play around with the Telerik UI for Xamarin suite yourself and see if it fits your needs. You’re able to check out the performance and interactivity of each of the controls before deciding if it’s right for your Xamarin app. There are beautiful showcase apps that highlight UI for Xamarin controls for each mobile platform, along with the sample code to achieve the same results. Find the apps in respective app stores, including the iOS App Store and Google Play.

Getting Started

So, how do you incorporate Telerik UI for Xamarin in your Xamarin project? A simple trial download may be the easiest way to get started. Simply head to the download site and pull down the bits. Once downloaded, you’ll find examples, templates, and binaries specific to each platform as swell as shared ones.

If you have the luxury of starting work on greenfield projects, Telerik UI for Xamarin offers several handy project templates/wizards. The goal is to give developers a great starting point with their Xamarin projects, both on Visual Studio and Xamarin Studio.

Be it on Windows or Mac, one of the easiest way for developers to integrate UI for Xamarin in their Xamarin projects is the Telerik NuGet Server. The first step is to configure your IDE’s Package Manager to point to the Telerik NuGet feed. This is in your Preferences/Options and works the same way in Visual Studio and Xamarin Studio. Simply set up a new NuGet source to point to the Telerik gallery at https://nuget.telerik.com/nuget, authenticate yourself for the first time, and done!

Adding the Telerik NuGet source in Visual Studio.

Here’s how you use NuGet to pull in UI for Xamarin bits into an existing project, shown here for Xamarin Studio for brevity, though Visual Studio has the same workflow. Once you pull in the Telerik UI for Xamarin package, NuGet does the rest of the magic; you’ll have the required UI for Xamarin references in your shared PCL as well as all the platform specific projects. One big advantage of the NuGet route is that not only do you get an easy way to pull in UI for Xamarin references into your existing project, you also get easy updates too.

Add the Telerik NuGet package.

Several of the UI for Xamarin controls gain their polish, behavior, and performance from the fact that they are truly native UI controls customizable for each platform. Accordingly, to render them from a Xamarin.Forms abstraction requires custom renderers. No worries, though, everything comes ready out-of-the-box, you just need to register the renderers in your app. The docs will show you how to register the renderers for each control when using them on iOS, Android, and UWP platforms. Here’s a sample of what you need when using the Telerik Calendar control in iOS apps. The following code goes in the AppDelegate.cs file in your iOS-specific project:

using System;
using System.Collections.Generic;
using System.Linq;
using Foundation;
using Xamarin.Forms;
[assembly: ExportRenderer(typeof(Telerik.XamarinForms.Input.RadCalendar), typeof(Telerik.XamarinForms.InputRenderer.iOS.CalendarRenderer))]
namespace MyApp.iOS
{
    [Register("AppDelegate")]
    public partial class AppDelegate : global::Xamarin.Forms.Platform.iOS.FormsApplicationDelegate
    {
        public override bool FinishedLaunching(UIApplication app, NSDictionary options)
        {
            global::Xamarin.Forms.Forms.Init();
            Telerik.XamarinForms.Common.iOS.TelerikForms.Init();
            LoadApplication(new App());
            return base.FinishedLaunching(app, options);
        }
    }
}

Once you have all of the bits referenced and renderers registered, you’re ready to roll with the Telerik Calendar control. Fire up any XAML view and this simple markup renders the Calendar for you:

... xmlns:TelerikInput="clr-namespace:Telerik.XamarinForms.Input;assembly=Telerik.XamarinForms.Input" ...

Calendar Visual Structure

The Telerik Calendar control is a calendar for sure, just rendered with painstaking accuracy for your app with a many customization options and catered to the unique UI paradigms of each mobile platform. Before we start tweaking things, it helps to see the overall, big-picture control—the simple rendering of the Telerik Calendar with all visual elements explained. The labels should be self-explanatory:

Telerik Calendar control UI.

You also get some control to show or hide specific details to suit your needs. By default, the day names show up and the week numbers don’t, but here’s some code to flip both (along with the resulting calendar on each mobile platform):

var calendar = new RadCalendar();
calendar.WeekNumbersDisplayMode = DisplayMode.Show;
calendar.DayNamesDisplayMode = DisplayMode.Hide;

Telerik Camera control visual structure.

Calendar ViewMode

The Telerik Calendar has several supported *View Modes* that control how the calendar is initially rendered, namely:

  • Month
  • Week
  • Year
  • MonthNames
  • YearNumbers
  • Flow

Not every view mode is supported on all mobile platforms, with only iOS having the distinction of supporting them all. There are some methods exposed for changing up view modes programmatically, aside from via user action. Each of these return true if there is support or if navigation is possible, otherwise they return false:

  • TrySetViewMode: Sets the Calendar to a specific view mode
  • TryNavigateToUpperView: Navigates calendar to upper view if possible
  • TryNavigateToLowerView: Navigates calendar to lower view if possible

The hierarchy of navigation among view levels is mobile platform-dependent, like so:

  • iOS: YearNumbers > Year > MonthNames > Month > Week
  • Android: Year > Month > Week

Here’s some simple code to instantiate a calendar and set the view mode to year, all programmatically:

var calendar = new RadCalendar();
calendar.NativeControlLoaded += CalendarLoaded;
private void CalendarLoaded(object sender, EventArgs args)
{
    (sender as RadCalendar).TrySetViewMode(CalendarViewMode.Year);
}

Calendar Date Management

The Telerik Calendar exposes some properties that allow the developer programmatic flexibility to manipulate the calendar user experience:

  • DisplayDate: A date in the current view
  • MinDate: Gets/Sets the minimum date that could be displayed or selected
  • MaxDate: Gets/Sets the maximum date that could be displayed or selected

Each of the date properties can be set explicitly or relative to the current date, like so:

// XAML Markup
xmlns:TelerikInput="clr-namespace:Telerik.XamarinForms.Input;assembly=Telerik.XamarinForms.Input"

// Code Behind
MyCalendar.MinDate = DateTime.Today.AddMonths(-1);
MyCalendar.MaxDate = DateTime.Today.AddMonths(5);
MyCalendar.DisplayDate = DateTime.Today.AddMonths(2);

What do users want to do most from a Calendar? The ability to select dates, of course. The Telerik Calendar sports a simple date selection functionality, both through user interaction and programmatically. Date selections should be available as single, multiple, or a range of dates. Two key things make this possible:

  • SelectedDate: Gets/Sets currently selected date
  • SelectionChanged: Event raised when the selected date is changed

Here’s some code that sets up the calendar to display the default month view mode and selects a date programmatically:

RadCalendar calendar = new RadCalendar();
calendar.SelectedDate = new DateTime(2016, 12, 14);

Below is the result; notice the style differences in the calendar controls rendered across different mobile platforms.

Telerik Camera control date selection.

Calendar Appointments

Any calendar UI needs to display appointments, it’s how you keep users engaged and productive. Appointment support in the Telerik Calendar begins with the Telerik.XamarinForms.IAppointment interface, which sports three basic members: StartDate, EndDate, and Title, but you should definitely consider adding more descriptors to your appointments as needed. A sample Appointment class implementing the interface is below:

public class Appointment : IAppointment
{
    public DateTime StartDate { get; set; }
    public DateTime EndDate {  get; set; }
    public string Title { get; set; }
    public bool IsAllDay { get; set; }
    public Color Color { get; set; }
}

A collection of appointments, all stemming from an IAppointment interface implementation, can be fed to the Telerik Calendar control directly by simply using the AppointmentSource property, which can also be data bound. Here are some sample appointments being bound to the Calendar and the corresponding results in each platform:

calendar.AppointmentsSource = new List() {
    new Appointment() {
        StartDate = DateTime.Today.AddDays(1),
        EndDate = DateTime.Today.AddDays(2).AddTicks(-1),
        Title = "Mom's Birthday",
        Color = Color.Red },
    new Appointment() {
        StartDate = DateTime.Today.AddDays(3).AddHours(17),
        EndDate = DateTime.Today.AddDays(3).AddHours(22),
        Title = "Big Game",
        Color = Color.Green },
    new Appointment() {
        StartDate = DateTime.Today.AddDays(11).AddHours(20),
        EndDate = DateTime.Today.AddDays(12).AddHours(4),
        Title = "Progress Party",
        Color = Color.Red }
};

Here’s a quick look at how professional Telerik Calendar appointments can look like through the Telerik UI for Xamarin Examples app (find the app on the iOS App Store and Google Play):

Calendar in action gif

Custom Calendar Cell Styling

Sure the Telerik Calendar has a polished UI, but there are times where you may want to customize its look and feel by manipulating the tiniest details and, in true developer-friendly form, the Telerik Calendar allows you to have custom styles for each cell.

You can set a property called SetStyleForCell to a custom function that can style individual Calendar cells. All cells share a common base class, the CalendarCell, with the following properties:

  • Text: Gets the text displayed in the cell.
  • Type (CalendarCellType): Gets the type of the cell. The possible values are:
    1. Date: All cells that correspond to actual dates have this type
    2. WeekNumber: Cells that hold week numbers
    3. DayName: Cells that hold the days of the week

Each cell can be styled using the CalendarCellStyle class, which has the following options:

  • BackgroundColor
  • BorderColor
  • BorderThickness
  • FontSize
  • FontWeight
  • ForegroundColor

Armed with cell styling flexibility, here’s how to color the first day of spring to be a green cell in the Calendar, for example:

var calendar = new RadCalendar();
calendar.SetStyleForCell = this.EvaluateCellStyle;
private CalendarCellStyle EvaluateCellStyle(CalendarCell cell)
{
    var springStyle = new CalendarCellStyle {
        BackgroundColor = Color.Green,
        FontSize = Device.OnPlatform(14, 30, 17),
        FontWeight = FontWeight.Normal,
        ForegroundColor = Color.FromRgb(139, 209, 0)
    };
    var dayCell = cell as CalendarDayCell;
    if (dayCell != null && dayCell.Date.Day == 22 && dayCell.Date.Month == 3)
    {
        return springStyle;
    }
    return null;
}

And the result:

Another common customization opportunity may arise with Appointments, where you may have a need to custom-style appointments on a busy calendar. With the Telerik Calendar, you get an AppointmentStyle property which is of the CalendarAppointmentsStyle type. This allows for complete color-coded customization of appointments with text and shapes.

Here’s the visual structure of appointment styling in calendar cells; you can use text or shape or both.


Some of the styling opportunities with CalendarAppointmentsStyle come with the following properties:

  • DisplayMode: Defines how appointments are visualized. Values can be Text, TextWithShape, TextWithBackground, and Shape.
  • Padding: Defines the padding of the rectangle that holds the events.
  • Spacing: Defines the empty space between two appointments in the same date.
  • ShapeType: Defines the shape representing an appointment. Values can be Rectangle, Ellipse, TriangleUp, TriangleDown, and Rhombus.
  • AllDayIndicatorLocation: Defines the location where the all day indicators are visualized.

Some examples of shapes representing appointments can be visualized as below:

An example of an all-day appointment indicator is below. You get to control the location, width, and padding of how the indicator is rendered in the calendar cell:

Conclusion

With Xamarin.Forms democratizing cross-platform mobile development for .NET developers, you can be proud to choose the Xamarin technology stack… just don’t go reinventing the wheel with complex manually-built UI. Telerik UI for Xamarin is here to help, and the engineering efforts behind each control show in their performance and polish. When you need to support any type of calendars and events in your cross-platform mobile app, the Telerik Calendar stands ready out-of-the-box, with a myriad of customization options. Just look through the detailed docs when you’re ready and keep your app users productive with the right calendar support. Cheers and happy coding!

The post Guest Post: Adding a Calendar to Your Xamarin.Forms Apps with the Telerik Calendar appeared first on Xamarin Blog.

Trunk-based development blends well with task branches

This is the third installment in the series of blogposts telling how we develop Plastic SCM. In the first two posts, we covered what our new working cycle looks like once we moved to trunk based development and then we gave a brief overview of the meaning of release versus deploy.

In this third blog post, we will be looking back and filling in some gaps. What exactly is trunk-based development and how does it blend with task branches?

Monologue

Monologue is a window into the world, work, and lives of the community members and developers that make up the Mono Project, which is a free cross-platform development environment used primarily on Linux.

If you would rather follow Monologue using a newsreader, we provide the following feed:

RSS 2.0 Feed

Monologue is powered by Mono and the Monologue software.

Bloggers