Tuesday, August 14, 2018

A Confluence of Enabling Technologies

In the years leading  up to the release of the iPhone, all the technologies that made it possible were already in existence. We had touchscreens, cell phones, GPS devices, MP3 players, smart(ish) phones and even attempts at tablets. Everything was there, but no one could figure out how to put it all together. We had separate devices for GPS, listening to music, browsing the internet, reading email and making calls. While we had all the technologies and even could use them in commercial products, no one had figured out how to best put them together in a new and innovative product that really made these technologies work.

Now we've got new technologies and devices like this one (Microsoft's Hololens):


And this one (Amazon Echo with Alexa):


This guy (Nest):


And even this on our phones:

There are many, many more examples.

It feels like we are in a place very similar to where we were prior to 2007 and the introduction of the iPhone. There are a lot of enabling technologies like machine learning, bots, augmented reality, virtual reality, IoT and other ways for increasingly intelligent devices to interact with and change the world around us.

We might think, "Sure I can do a lot of this stuff now on my Alexa and Android or iPhone and I just got an Occulus Rift." But like the world prior to 2007 it doesn't feel like the current batch of products really has this all right. Not in the way that the early PCs did for in home computers, or the way the Mac fundamentally changed how we interacted with them in 1984, or even how battery, display, processor and OS improvements led the way to the laptop. It wasn't the existence of the internet that brought us online, it was the standardization of HTML, the web browser and distribution technologies like DSL that put it all together.

I'm not saying that tomorrow there is going to be some new revolutionary device and we're all going to stop using our smart phones. But it does feel like there is increasing momentum for something new. All these new technologies are not being used to their fullest and the current standard device platforms for delivering these technologies seem clunky at best. The smart phone is no longer the revolutionary platform that it was, it hasn't been for a while. It may take several years for this to bubble over in a usable way but it's time to start preparing. If you haven't started to learn machine learning or about augmented reality, perhaps now is the time to start investigating how these technologies work.

Wednesday, April 4, 2018

Even For Small Teams, AppCenter Helps Press the Easy Button



Opening up Xcode, Android Studio, Visual Studio, Atom or whatever integrated development environment we use and starting coding away is always easy enough. Sure, we can create an application, go through the process of manually signing it and get an app in the store. This is OK if we are working alone but at some point, many of us are going to be in a situation of working on a team or have a complex enough application where more formal testing and deployment is required. Then we start putting together disparate tools to do mobile DevOps, deploy test versions of the app, handle crash reporting, analytics, etc. Getting all this to work together can be difficult, particularly the build servers for automated builds which can be time consuming to setup and maintain for groups that don't have a lot of experience in that space.

This is the space where Microsoft's App Center really shines. For small teams, who may be new to mobile, they need to know very little about setting up these processes to use App Center. One of the strengths of this is that it falls under Microsoft's new philosophy of embracing technologies outside of their stack, so it isn't just for .Net folks. If you work in Xcode on Swift, no problem, Java in Android, no problem, React Native, no problem. App Center takes a variety of infrastructure needs common to most mobile apps and presents it as a all in one solution where all the parts are easy to use, work well together or can just be taken a-la-carte.

To see how many different capabilities Microsoft has provided on a variety of platforms consider the following:

Feature
Xamarin iOS and Android
Native Android
Native iOS
UWP
React Native
iOS and Android
Cordova
iOS and Android
MacOS
Build
 X
 X
 X
 X
 X

 X
Test
 X
 X
 X

 X
 X

Distribute
 X
 X
 X
 X
 X
 X
 X
Crash Reporting
 X
 X
 X
 X
 X
 X
 X
Analytics
 X
 X
 X
 X
 X
 X
 X
Push Notifications
 X
 X
 X
 X
 X
 X
 X
Code Push




 X
 X


Microsoft has gone to great lengths to make most of the features work with many different mobile development platforms. I don't have space to get into how these features work here, but if you want more information you can watch my AppCenter class on Lynda.com or Linked-In Leaning:



Here's how I think about the good, bad and ugly parts of App Center

The Good


  • We get continuous integration and continuous deployment setup quickly without needing to know a lot about how to do it
  • There is a lot of extendability and capability to tie in other process tools with API and REST interfaces
  • It has reasonable pricing for the features that are not outright free
  • If you are you blue about managing all the devices in your Ad-Hoc provisioning profiles, AppCenter can make this easy
  • Do you only have a few devices to test on? AppCenter has thousands
  • This even offers an entire framework for live code pushing React Native and Cordova Javascript code
  • Crash reporting and analytics can be set up easily on all supported development platforms
  • There just is a lot in this box to like. With AppCenter and a public git style repository of the right type there really is no reason not to have at least a basic CI process

The Bad


  • There are limitations around customization of build process (there are three places where custom scripts can be inserted)
  • No tie in for builds to kick off custom automated testing (must use scripts and API/REST interface)
  • Appium tests can only be written in Java
  • The testing feature does not allow for manual testing, there is no direct interaction with the devices for exploratory testing
  • There are some other limitations
    • Android React Native build only looks two directory levels deep in the repository for workspaces
    • Deployment feature still not as full featured as Hockey App
    • Features like iOS store deployment that require access to the Apple store account need two factor authentication to be turned off

The Ugly


  • To use the build services, it only has Git integration, if you use another source control tool, too bad. You also better be on VSTS, BitBucket or GitHub
  • On that note, repositories cannot be on-premise either
  • Builds cannot easily be tied into a gated check-in concept
  • The REST / API to create builds is fire and forget so it is hard to kick off an AppCenter build from another tool and know when the build is done to know if it failed.
That may seem like a lot of bad and ugly, but some of this is by design. The implication of making it super easy to set up builds that almost anyone can do, is that we may loose some flexibility. But that's kind of the point of AppCenters wide feature set. While organizations of any size and complexity may be tempted to use certain features of AppCenter, AppCenter also brings more complex things like the creation of build processes to even the smallest of teams. If your build needs are super complex then Microsoft has the much more flexible VSTS build services that can be used. But if your build needs are somewhat generic and simple, boy can you get that going with AppCenter quickly. The box of features is large, the breadth of toolsets supported is wide, there just is something for everyone to be found in there.