Xamarin Developer Summit Schedule Breakdown

In just under a month some of the biggest names in the Xamarin community will be presenting alongside a prominent members of the Microsoft Xamarin and Xamarin.Forms teams at the Xamarin Developer Summit.

Xamarin Developer Summit – 11/12 July – Houston, Texas

Whilst I’m not going to be able to make it across to the summit I wanted to do a bit call out to all the great sessions that are in the schedule. The summit is a result of the massive effort that Dan Siegel has put in and the support from all the fantastic presenters.

If you scan the schedule you’ll no doubt be familiar with some of the names but with so many great sessions, how do you know where to start. I thought I’d take the opportunity to break the sessions into some groups to help you decide what’s of interest. These are of course just my groups based on what I can gather from the session description.

Getting Started / Overview

Workshops

Optimisation / Quality

Testing

Mvvm / Architecture

  • Xamarin.Forms made better with Prism – Hussain Abbasi
  • Streamline & Simplify Events with Reactive Extensions – Shane Neuville
  • Rapid Enterprise Architecture Delivery – Paul Schroeder
  • Reactive UI and Reactive Extensions for Xamarin.Forms – Michael Stonis
  • Mobile architecture with MvvmCross, are you doing it right? – Martijn van Dijk
  • Using Xamarin.Forms Shell to easily create a consistent, dynamic, customized, and feature filled UI – Shane Neuville

Security

  • Authentication and Authorization for Xamarin apps using ADB2C and MSAL – David Allen

Device

AI / ML

  • Cognitive Services in Xamarin Applications – Veronika Kolesnikova
  • Build Smarter Cross-Platform Applications Using Xamarin, Azure Cognitive Services, and ML.NET – Richard Taylor
  • How to build your modern ai app with Xamarin – Lo Kinfey

Azure

  • Crafting Real-Time Mobile Apps with SignalR – James Montemagno
  • Light up Xamarin Apps with ChatBots – Sam Basu
  • Build a mobile chatbot with Xamarin & Bot Framework – Luis Beltran
  • Build a Media Streaming App With Azure and Xamarin – Matt Soucoup
  • Create Mixed Reality Experiences with Azure Spatial Anchors and Xamarin – Sweekriti Satpathy

Data

Design

  • Let’s Make Crazy Beautiful UI With Xamarin.Forms – David Ortinau
  • Creating Consistent UI with Xamarin.Forms Visual – David Ortinau

General

DevOps

For more information on any of these topics then you should Register and bring all your learnings back to your company, community through user groups and other forums.

Good-bye HipChat, and don’t let the door hit you on the way out!

Good-bye HipChat, and don’t let the door hit you on the way out!

It was interesting to see this week that Atlassian doomed the future of HipChat and its successor, Stride, with an aggressive wrap up schedule, with the services set to be discontinued on February 15, 2019. At Built to Roam, as a consulting company, we use a number of messaging tools including Messenger, Skype, Skype for Business / Microsoft Teams, Slack, HipChat and a few others. The upshot is that none of these tools do a great job of even their primary function (i.e. chat conversation between two or more parties), as I’ve posted about previously.

As a couple of posts have indicated, the messaging market has become over populated – for a while it felt like I was installing a new messaging app every second day. When Teams first came to the market, there was a lot of criticism aimed at it because it was a primitive offering in comparison to both Slack and HipChat but it’s rapid growth has started to put pressure on other players in the market. I think a rationalisation of the market was due, and I’m not sorry to see the back of HipChat. As one of the older products in the market, it never quite understood the need for users to belong to multiple organisations and to be able to switch between them.

There are some posts that are talking up the closure of HipChat/Stride as an attempt by Slack and Atlassian to team up in the fight against Microsoft Teams. So the question is, will this make a difference? Will it slow the growth of Microsoft Teams? Will it help Slack win over the corporate space?

Recently, Microsoft Teams announced a free tier, which was one of the things that held a lot of smaller companies and teams from using Microsoft Teams. This move in itself has weakened Slack’s position in the market. However, the true hook for Microsoft Teams and in my opinion the sole reason for its wide adoption (because let’s be honest, it’s far from being a great product!), is that it allows users to sign in using their Office 365 / Microsoft 365 account. In other words, if your company has made, or is moving, to Office 365, you can use your existing credentials to sign into Microsoft Teams. And of course, once you do, you can see and communicate with all the other users in your organisation. Can do you do this with Slack? The short answer is no. The long answer is yes but you need to do a bunch of stuff, including pay a ton of money for stuff that should be out of the box (seriously like what the? https://get.slack.help/hc/en-us/categories/200122103-Workspace-Administration#configure-access-security).

The ridiculous thing is that integration into Azure Active Directory (i.e. use Office 365 and Microsoft 365 credentials) is pretty straight forward. Is there something that Slack can do to get the jump on Microsoft Teams? Yes, provide out of the box support to sign in using either G-Suite or Office 365 credentials. In the future there will be two types of organisation, those that use Office 365, and those that don’t. Most of those in the latter group will probably use some form of G-Suite, so providing out of the box support for G-Suite should be on the radar of any enterprise software.

I know this post has gone on a bit but my last point is that I wish services would stop charging a premium for improving the security of their service. Integration with Azure Active Directory and G-Suite should be include in the cheapest tier of any offering. Why would you compromise the security of your service and the data of your users by not providing this.

App or not to App

App or not to App

Following my last post there were a couple of interesting tweets that made me revisit (again) the discussion of whether building an app is the right thing to do. For example, @GeoffreyHuntley said:

Decision time:
– #0 Don’t make an app unless you absolutely have to.
– #1 React + React Native (insane productivity)
– #2 Xamarin (stagnating tbh)
– #3 Flutter (innovator – watch this space)

To be blunt, options 1-3 are all semi-painful – I’m not going to go into detail as to why, as that’s not the point of this post but needless to say that each one has their pros and cons, and none are what you’d consider an ideal development experience. Option 0 sounds like a great option and with the rapid development of Progressive Web Applications (with service workers being included by both React and Angular) it really does seem that not having to build an app is the way to go.

Ok, but in that case, when would we build an application? Before we answer this, I think it’s worth revising what the notion of an “application” or “app” actually means. If you do a search for “App” on Wikipedia you get a number of responses:

  • Mobile app, software designed to run on smartphones and other mobile devices
  • Application software that causes a computer to perform tasks for computer users
  • Web application or web app, software designed to run inside a web browser

(And particular note that the term “website” is not included here as according to Wikipedia a website is “a collection of related web pages” – personal opinion: if you still building for the web using the traditional post-back model (yes, looking at you ASP.NET) you’re building a website, not an app).

Let’s ignore for the moment the distinction between mobile, web or any other qualifier about the type of an application or the target platform and instead, let’s focus on what an application is. According to Wikipedia an Application is software that causes a computer to perform tasks for a user. This is a pretty wide definition and essentially encompasses most software, whether it be a command line application, browser or window based application. However, if you were to ask most people what they thought an “App” was today, they’d probably give an answer that relates to installing an application from the Apple, Google or Windows Store – it seems like the notion of an App is in somehow attached to the distribution model.

If we look further into this, there are a variety of distribution models:

– An application that you simply download from the Internet and just run (it might download as a Zip file but the important distinction here is that there’s no installation process and no Store managing the application). This is by far the simplest distribution model. However, these days few applications are distributed this way as most operating systems distrust downloaded files from the Internet and will refuse to run them without them being “unblocked” first.

– An application you download from the Internet and then install. For Windows and MacOS historically this was the most common way for applications to be distributed. The operating system didn’t have a built in distribution mechanism, such as a Store, but they did support a model for applications to be installed and uninstalled. The danger of this model, is that, similar to just downloading and running an application, an application that is installed could have wide-reaching access to the host operating system. Over time this model has be adapted and additional security (for example User Account Control on Windows) limited what an installed application could do

– An application you install from a Store. Whilst this model did exist prior to the iPhone, it wasn’t really until the App Store launched that the notion of a single curated Store became mainstream. Now, most platforms have a Store where you can browse, search and install apps to suit your every need. Depending on the platform, the process for submitting, certifying and publishing applications varies, with different levels of quality and policy controls imposed in order to try to maintain a high quality bar for apps. The Store also takes on responsibility for distributing updates to application as they become available, as well as providing a mechanism for developers to charge for their applications.

– An application you load in the browser. Most people don’t really consider websites that they navigate to in the browser as applications. However, websites are becoming highly functional and most no longer require a full post-back in order to load more content, improving the usability. In fact, browsers have tried to prompt web sites as pseudo-apps by allowing users to add a web site to a list of applications (for example the “Apps” icon that appears within Chrome under the address bar).

image

– An application you install via the browser. In contrast to adding a website to a list of applications within the browser, installing a website via the browser allows the website to take advantage of a lot of the benefits of applications installed via a Store. They can appear as an icon on the home screen (or list of applications installed on the device); they run without the browser chrome; they can receive push notifications and much more.

So the question is whether the distribution model is what defines what an “App” is?

When we embark on building an application do we need to lock ourselves into one of these distribution models, or can we pick multiple, or all of these distribution models. Or, is the distribution model different for each platform? To answer this we really need to consider the pros and cons of each mechanism and the corresponding audience reach it gives us, and whether it makes sense to choose a particular distribution model.