Forem: Claudio Sanchez

The October Xamarin Best Practices Challenge

Claudio Sanchez — Wed, 14 Aug 2019 13:50:31 +0000

The October Xamarin Best Practices Challenge

As you may know by now, Xamarin-related challenges are very popular in 2019; so why not have yet another one.

This challenge would focus on proven best practices in all aspects of creating mobile apps (DevOps, project Structure, cross-cutting concerns, data, API, Testing, App Signing, etc).

How does it work?

If you are already familiar with prior challenges — like the Xamarin UI July challenge from Steven Thewissen, or the Xamarin Month, from Luis Matos- You would know that the challenge is in the style of an advent calendar, where an article about a particular topic is posted every day, by one of the amazing contributors. In this instance though, the article will be included in the Challenge repoas a Pull Request, and if also desired a brief blog post about the topic on the contributor’s own blog. The article should be in English.

What would I write about?

The Challenge Repo will contain a Table of Contents (ToC), with an outline of topics — you can either choose a particular topic from the ToC or add a brand new topic if the ones listed do not cover what you want to write about.

How do I sign up for this?

As the challenges before, we would need at least 30 writers — one for each day- but we will certainly welcome additional contributions. Follow the steps below:

Reserve a spot by submitting a creating an issue on the repo. Once reviewed, we will update the Table of Content with your topic, as well as updating the Calendar.

The article proposed by James Montemagno

Submit a Pull Request. Write the article in a markdown file inside of the challenge repo .
Publish your blog post linking back to the original article and your contribution in the repo.
Post the links on Twitter with the hashtag #XamarinChallenge.

What happens next?

Similar to past challenges, we will have a special event shortly after the month of October to talk about all of the contributions. Stay tuned.

The Calendar

Check out the README.MD File for an Up-to-date Calendar.

Instantly releasing features in a world that never sleeps, using Feature Flags

Claudio Sanchez — Thu, 14 Feb 2019 14:24:09 +0000

Now more than ever, businesses need to be nimble and continue to ship features at the speed of light™. This is even more true in the very competitive world of mobile apps.

Long gone are the days where we could wait several months to release a new version of our app.

These days, customers expect from your mobile app the same nimbleness as their Facebook app, Banking app or Dating app. And if you are not willing to do it, the competition will.

As you might know (hopefully thru the pain of others), it is very risky to roll out a faulty feature, as, in the world of the App Store, a new release could take between 1 and 2 days to be approved, and this could make your customer’s confidence in your product be lost forever.

So, how can we serve both masters? the ever insatiable desirer of new features, while still serving the Lord of Always-Works-Never-Roll-Back?

Feature Flags, my friend! They are the stuff dreams are made out of.

“With Feature Flags, you can launch brand new features and experiences in real-time. You don’t have to go all in with every feature in every release, which removes a lot of risk and enables you to instantly roll back if the feature needs more work.”

– Nancy Hua, CEO, Apptimize.

So now, let’s talk about how to do Feature Flag as a Service, by utilizing LaunchDarkly to make instant releases of features within our Xamarin Mobile app.

Let’s say, our Mobile Banking App team is rolling out a very innovative feature, called Spending Analysis. This feature tracks expenses and income over time and tells the customer how much money they have leftover to spend. Now, our Data Science Department is still tweaking the algorithm, so they want to make sure that the feature can be rolled out to just a subset of their customers, and eventually to the entire consumer base.

This is what the final result should look like once we turn on the feature.

The LaunchDarkly website has a very simple sign up process and onboarding. It took us about 20 seconds to do so, and we were in. The site gives you the choice of doing a Quickstart, or to skip straight the dashboard; We chose the later.

Creating a feature flag for our mobile app was simple. We gave it a name and key. We also selected a Boolean as the kind of flag. Lastly, we checked the box says Make this flag available to client-side SDKs, in order for the flag to be provided to our mobile app later on.

After having created a few feature flags, we are almost in business.

LaunchDarkly Dashboard

We then moved over to the client side of the story and implemented the Spending Analysis, and placed on the Main Page of the Mobile App.

Spending Analysis Widget

Let’s add LaunchDarkly Xamarin SDK to our project, by including the LaunchDarkly.Xamarin NuGet package to your .NET Standard project. At the time of writing , the NuGet package is still in pre-release , version 1.0.0-beta9. There is also a more mature .NET client, but since we like to live on the edge, let’s stick to the Beta.

Install-Package LaunchDarkly.Xamarin

At some convenient time, during your app initialization sequence, you would want to initialize the LaunchDarkly client.

By now, you should be familiar with the paradigm these mobile SDKs have. You create a project, that gives us some sort of key, to be used as a form of authentication. We have stored this in a field called MOBILE_KEY_TEST.

After you have initialized the LaunchDarkly client, it will by default, communicate with the LaunchDarkly cloud and download all of the feature flag information. This includes a list of the feature flags and their state.

Each feature flag has a unique name/key. Our new feature will be using the key can-see-spending-analysis. I have placed my keys in a convenient static class for ease of access.

Checking if a feature flag is on or off, is pretty straightforward. From our MainPage ViewModel, we are calling a Service we implemented to abide by the Separation of Concerns and Single Responsibility principles.

The ViewModel calls the Can() method of the FeatureFlagService, to check on whether or not it should display the Spending Analysis widget.

At this point, the Spending Analysis widget is present in our app. We deploy the new version of it, and we notice that the Spending Analysis feature does not appear! — Do not despair, that should come as no surprise, as we have not turned on the feature flag ON yet.

The new feature is present in the code but is disabled via Feature Flags.

At this point, the person in charge of turning on features for our App can simply access the LaunchDarkly Dashboard and turn the feature ON.

A Voila! The feature is ON!!

Microsoft Build 2018 Recap talk at NYC Mobile .NET Developers User Group

Claudio Sanchez — Fri, 18 May 2018 18:35:50 +0000

Microsoft Build @ Seattle, WA. May 7–9

Last week, I got to co-deliver an interesting talk (with Sara Morsi as co-speaker) at the NYC Mobile .NET Developers User Group. We curated a selection of topics, from our recent experience at Microsoft Build, this past May 7–9, in Seattle, WA.

Some of the topics at Build we found most relevant for Xamarin Developers include:

Hyper-V Android Emulator Support
Visual Studio Tools for Xamarin
Platform Improvements
Xamarin Forms 3.0
Fluent Design for UWP
Visual Studio Live Share … and much more …

Follow this link to the presentation, as well as the meetup notes.

A Pull Request that will make people smile

Claudio Sanchez — Wed, 31 May 2017 15:33:48 +0000

If you have been working in a software team using any type of git workflow, I bet you are familiar with the concept of Pull Requests. This article does not intent to school you on the mechanics of creating it, but rather on the art of what constitutes a Pull Request that brings smiles to reviewers and collaborators alike.

The Title

Here is your opportunity to let the reviewer know what your Pull Request (PR) is all about. Do go beyond just including the issue number; try to reflect the main point of the pull request. Don’t assume the reviewer will know, just based on the issue number.

Examples of Pull Request titles:

BOS-8869 Introduced Social Login with Facebook, Google and Twitter.
MYAPP-0007 Fixed Crash bug when adding item to Calendar in iOS.
API-1020 Introduced Coach Marks for Filtering.

The Description

Putting together a useful description will significantly help the reviewer understand your changes. Specially if you changed many files, or the change is not trivial. Take the time to craft a detailed description, since you are in the best position to justify your approach/the functionality it provides; after all, you wrote it.

The description field of the Pull Request typically supports some type of markup (i.e.: MarkDown ). Just like you would for a well crafted essay, do make use of all of the formatting you have at your disposal to express the ideas in a clear manner.

Examples of Descriptions:

Added Sorting capabilities: sorting can be done by Category (ascending and descending), by Date Published (Newest and Oldest), and by Amount (Ascending and descending).
Changed implementation of the GetClubDetails method to process the request asynchronously. The return type is now Task<ClubDetail> and the method name GetClubDetailsAsync to follow the convention.
Modified the FilterOptionsService to sort options alphabetically.
Used the new Location API deployed to Azure and had to change Proxy, Service and Data Transfer Object associated with the Location Screen.

Bonus Points: Calling out the acceptance criteria of the story, will make it apparent what your change is introducing. Also, call out functionality is not included, in the case where a functionality has been split in several stories.

The Screenshots

“A picture is worth a thousand words” . This could not be more true when it comes to pull requests.

If the change involves any UI change, always include a representation of before and after. This saves the reviewer lots of time, and provides clear guidance of what to expect.

Some tips when including screenshots:

Resize the image to manageable size. The intent is to provide context of what changed, not to fill the screen with larger than life images.
Highlight areas of the UI that are expected to change. Specially if the UI is too busy, and the change cannot be spotted easily.
When useful, insert the images into a Table, for the purpose of contrasting the images side to side.

In the end, these are all tips that assist the reviewer in understanding the context of your change, and thus making the review process something that brings a smile to one’s face.

Sample Pull Request

Title: FITNESS-1039 Add Health Club Class List screen with loading state and booking capabilities.

Description:

The new Class ListScreen provides a list of available classes for the selected Health Club.

The user sees a loading state while the screen is loading the data from the web.
The user has the ability to book an available class by tapping on the Book button.
The user can cancel/reserve a booking, by tapping on the Booked button, for an already booked class.
Filtering is not implemented.

Screenshots providing a visual aid for the multiple states of the screen.

What Xamarin 3 means to the future of Mobile Development

Claudio Sanchez — Wed, 17 May 2017 14:28:00 +0000

It was just a few hours ago that Xamarin released Xamarin 3.With this announcement they have yet again revolutionized the way we write cross-platform mobile applications. The announcement first highlights the Designer for iOS, which is awesome, but I want to take a step forward, and instead talk about what I think Xamarin.Forms will do for your future mobile development efforts.

Some background

For the last few months my companyworked and developed an internal MVVM framework that provides services such as Navigation, Bindings, Loosely-coupled messaging, mobile optimized Dependency Injection, List Controls for effortless displaying data, etc. to be used in our projects because we believe these are things that real apps need, and what was available at the time did not fit our style of MVVM development, so we rolled our own. Were were in the process of rolling out support for Windows Phone and were very excited to what we would be able to accomplish with this newly created framework when creating apps for all 3 platforms.

What the future holds

While you might think that today’s announcement would be annoying, or bittersweet for us, it is quite the contrary. We no longer have to maintain and evolve our framework, and instead we can focus on applying all we learned while creating this -yet to be named- framework, and instead extend (if needed) what Xamarin has just rolled out.

Sample UI on all 3 Platforms. One of the immediate advantages of Xamarin.Forms over other frameworks (including our own) is that these services work on not only on the two (iOS and Android) but 3 mobile platforms (Windows Phone), and it promises the ability to achieve the quintessential 100% Code sharing.

“That’s not something new” — You might say; and I would have to agree with you. MVVMCross(the most well known mvvm framework in the Xamarin ecosystem) does that. But where Xamarin.Forms has no comparison is, in that it attempts (and in my mind succeeds) to bring XAML one step closer to being in all the mobile platforms (Something Microsoft just recently started doing).

XAML in itself is might not sound like a big win for seasoned iOS and Android developers, but think for a moment in the millions of developers who are already familiar with Microsoft technologies and UI creating in WPF, Silverlight and WP8. These guys already are already familiar with constructs such as Page Based UIs, Navigation Services, Two-way Bindings, Data Templates, etc.

I invite you not just to believe me, and go try it yourself. The framework is already available today and let me know how awesome it is!!

Originally published at claudioasanchez.blogspot.com on May 28, 2014.