ChrisRisner.com

Open Sourcing Azure Storage Explorer for Mobile

Wed, 07 Feb 2018 09:16:00 +0000

Some time ago, I started working on a mobile version of the Azure Storage Explorer. The intent of this app was that anything you could do from the ASE app on Windows, MacOS, or Linux, you’d be able to do on Android and iOS. There were a few different reasons I wanted to build this:

I wanted to spend time building out a real application using Xamarin.
There were a few situations where I thought it would be handy to have access to my storage accounts while away from my computer.
I wanted to start auto-backing up any photos I took with my phone to Azure Storage.

Fast forward through several months of working on the app in my spare time (which is to say not very frequently) and I had a number of scenarios around Storage working. What I didn’t have, was a strong use case or motivation to release and support the app. Additionally, after talking with more people, it didn’t seem like there was a very strong use case for the mobile version of ASE. As with many other things, if there wasn’t a customer need, there probably wasn’t going to be much usage, and therefore there wouldn’t be much in the way of support. So rather than releasing an app to the App Store and Google Play and let it languish, I decided it would be better to just open source the app.

Releasing the Souce Code for ASE Mobile

Effective today, you can now access all source code and assets for Azure Storage Explorer for Android and iOS on GitHub. I think this is a great reference app as it details:

How to build a semi-sophisticated Xamarin app for Android and iOS.
How to use different UI elements depending on the platform (iOS makes use of tabs while Android uses the slide out menu).
How to access a number of different Azure Storage capabilities (see below).
How to mix usage of Azure REST APIs and libraries.

Credit to Other Devs

I couldn’t have built this without ~~stealing~~ borrowing from many other devs.

I heavily referenced the app architecture and patterns from the Xamarin Evolve 2016 Mobile App. James and Pierce did a great job with this app and made it very easy to look through and reuse.
I’ll call out James Montemagno again as I made use of a large assortment of the Xamarin plugins he builds and supports.
Developers at Realm and Rg.Plugins.Popup for their technical support.
Everyone that works on Visual Studio Team Services and Visual Studio App Center. Throughout developement, I used VSTS for continuous integration and App Center to deliver the app to test devices and track errors and analytics.

Outstanding Issues

There are a number of issues I never got around to including:

Testing against a large quantity of blobs, table rows, etc.
Editing table schema and rows.
Any sort of advanced querying of data.
Currently the app only works with Classic Storage Accounts due to how I am pulling subscriptions and storage accounts (i.e. the APIs I used). This wouldn’t be very difficult to convert over but I never got to it.

How to Build it?

In order to build and run the application, there are a few things you should do and a few things you need to do:

In the src/AzureStorageExplorer/Helpers/Constants.cs class, there are a number of API Keys that need to be set. First is the AuthClientId which is the value you get from Azure Active Directory after you create an app with appropriate permissions. Second is the MobileCenterId which is the value you get after creating an app in Visual Studio App Center (yeah it used to be called Mobile Center). You’ll note that there are different values based off of if you’re in Debug or not as well as if you’re in iOS or Android.
If you’re building and running in iOS, you’ll need to create an App ID and all the appropriate bundle identifiers, etc. Because there is certain functionality that requires iCloud access, for the App ID, you’ll need to set up iCloud access (I used iCloud.azurestorageexplorer as the container name).
I haven’t compiled against the absolute latest versions of iOS / Android / Xamarin but I don’t anticipate any issues.
One thing to keep in mind is that I pulled in the actual code for the Rg.Plugins.Popup library. This is only directly used in the iOS project and was done to alleviate an issue where popups weren’t working if you were too deep down the navigational stack. I believe they’ve fixed this in a preview version of the plugin (v1.1.0-pre1 and beyond) but haven’t tested this yet.

Would you use it?

If you see this and think you’d have use for the app if it was easily available on the App Store and Google Play, please let me know. I left this project because it didn’t seem like there was a solid enough use case for it. I’d love to be wrong about that. If you need any help getting the app built, please reach out or file an issue on the GitHub repo.

Switching Comments to StaticMan

Wed, 27 Dec 2017 09:16:00 +0000

Six years ago, when I was still using my own custom built blog engine, I switched the comment system over to using Disqus. At the time, this change made a lot of sense. With just a little bit of additional markup per page, Disqus would render all of the comments and the comment form and handle everything for me, including the ability to do moderation. Recently, when I switched over to GitHub, I kept on with Disqus as it was relatively easy and there were instructions on how to integrate. Unfortunately, one of the issues with Disqus is that it loads quite a bit of JavaScript including ads. While the JavaScript is not blocking, I wouldn’t be entirely surprised if the long time for the page to actually finish loading didn’t impact some ratings by a few certain search engines. Plus, the only way to remove the ads (which aren’t even relevant to the material of the site in anyway), is to pay.

A First Replacement: CommentIt

I’d taken a very brief look some months ago about finding a replacement that would work with GitHub pages. Since GitHub pages are generated using Jekyll there isn’t really a backend that can be used to run the comment engine. I was chatting about it with one of my teammates at work and he mentioned he’d recently setup a new site on GitHub pages and had used CommentIt to handle this comments. Once you give CommentIt access to your GitHub repo and put some markdown on your site (to display comments and to put a comment form on the page), everything works. CommentIt runs the backend javascript that actually handles processing comments. Whenever a comment is made, it creates a pull request against your repo. The one big issue both he and I had with CommentIt was that it puts comments into the Front Matter for your blog posts. I’d much rather prefer comments end up in a different file or location.

StaticMan

While looking around further, I stumbled upon this post on mademistakes.com about changing from Disqus or an external site to use StaticMan for comments on GitHub Pages. StaticMan functions similarly to CommentIt except it puts every comment in a separate file in your repo under the /data/comments/[slug] path. Additionally, there is support for replies, notifications, and Captchas. Getting started is quite easy and fully documented. I did go down the route of trying to further customize my rendering and interface similar to what MadeMistakes.com had done and thought it would be good to share some of the implementation details. Of particular importance, I’d look at the following files (on top of the JS and SCSS files):

One of the big things I want to call out because I ran into issues with it multiple times is the ordering of the comments. Specifically, ordering didn’t seem to be the same when running the site locally and when it was showing up in GitHub Pages. I want to share what the comments.html looks like:

{% assign count = 0 %}
{% assign comments = (site.data.comments[page.slug] | where_exp: 'item', 'item.replying_to == ""' | sort: 'date') %} 
{% assign comments = (comments | sort) %}
{% for comment in comments %}              
  {% if comment[1].replying_to == "" %}    
    {% assign index       = (forloop.index | minus: count) %}
    {% assign r           = comment[1].replying_to %}
    {% assign replying_to = r | to_integer %}
    {% assign avatar      = comment[1].avatar %}
    {% assign email       = comment[1].email %}
    {% assign name        = comment[1].name %}
    {% assign url         = comment[1].url %}
    {% assign date        = comment[1].date %}
    {% assign message     = comment[1].message %}
    {% include comment.html index=index replying_to=replying_to avatar=avatar email=email name=name url=url date=date message=message %}
    
  {% else %}
  {% assign count = count | plus: 1 %}
  {% endif %}
{% endfor %}

For some reason, the query where we’re trying to get comments that have nothing in the replying_to field doesn’t work. I’ve seen other examples where they compare against blank as in where_exp: ‘item’, ‘item.replying to == blank’ but that didn’t work for me either. The sorting was very bizarre and didn’t make very much sense as, as near as I could tell, different rebuilds of the site lead to different ordering of the comments.

Importing Disqus Comments

The next step was to export the comments from Disqus which I did with these instructions. From there, I built a program to translate the XML into YML comment files. Once that was done, I just needed to copy the comments over and push them up to my repo. Now all of my comments are showing and their in the correct order.

Running OpenWhisk on a VM in Azure

Thu, 21 Sep 2017 09:16:00 +0000

I’ve recently been doing some evaluations of open source Serverless frameworks and seeing how well they run on Azure. One of the first such projects I tried out was OpenWhisk. OpenWhisk is a project created and open sourced by IBM. You are able to run it on-prem and in the cloud, on top of IBM offering a managed service as part of their cloud. As a first step in getting OpenWhisk to run, I wanted to deploy it on to a single VM running in Azure. As I ran into a few issues, I wanted to share a walkthrough of how to get OpenWhisk running on a Linux VM in Azure.

Creating an Azure VM

Your first step should be to create a Linux VM in Azure. For this walk-through, I created an Ubuntu Server 16.04 LTS vm. I chose the DS1_V2 Standard size though you’d probably get by with something smaller if desired. In the interest of being very specific, I used the default VM settings at the time including:

No Availability Set
Managed Disks for storage
Default Virtual Network, Subnet, Public IP, Network security group
No extensions
Auto-shutdown set to Off
Boot Diagnostics turned On
Guest OS diagnostics disabled
Default storage account name

Once your VM is up and running (just a couple of minutes max), if you’ve done it in the Azure Portal, you should be taken to the blade in the portal for the VM. If you didn’t use the portal, you can open it and navigate to your VM. Clicking the Connect button at the top of that blade will give you the SSH command to use to connect which should be similar to “ssh adminUserName@publicIPAddress”. Copy that into a terminal / SSH tool and connect to your VM.

Installing and Setting Up OpenWhisk

The first step is going to be pulling down the source code for the Apache OpenWhisk project:

  git clone https://github.com/apache/incubator-openwhisk.git

They’ve provided a set up script for Ubuntu which will do a decent amount of the prep work for your VM so you should run that next:

  ./incubator-openwhisk/tools/ubuntu-setup/all.sh

This will run for a few minutes and you’ll follow it up with a few more package installs:

  pip install --upgrade pip
  sudo pip install ansible==2.3.0.0
  sudo apt-get install couchdb
  sudo apt-get install docker.io
  sudo pip install docker-py

Note that I’ve tried to minimize the need to run most of these things as root though, as near as I can tell, this is necessary for some package installs. Next, now that CouchDB (which backs OpenWhisk) is installed, we need to create an Admin user:

  curl -s -X PUT http://localhost:5984/_config/admins/username -d '"password"'

The response to that command should just be an empty set of quotes (“”). Next we need to tell CouchDB to listen on more than just 127.0.0.1 so that we can access it from the docker containers that we’ll soon be deploying.

  sudo nano /etc/couchdb/local.ini

Near the top of this file, you should see a commented out line that starts with bind_address. You’ll want to uncomment it and set the IP to all zeros:

  bind_address = 0.0.0.0

Save that file and then restart CouchDB:

  sudo systemctl restart couchdb.service

You’re now ready to output some variables that will be used during the OpenWhisk setup:

  export OW_DB=CouchDB
  export OW_DB_USERNAME=username
	export OW_DB_PASSWORD=password
	export OW_DB_PROTOCOL=http
	export OW_DB_HOST=VMHOSTNAME
	export OW_DB_PORT=5984

Now here, the username nad password should match the values you’ve used when you created the CouchDB admin user above. Also, you’ll want to replace VMHOSTNAME with the name of your actual VM. Next we’ll run our Ansible playbooks:

  cd incubator-openwhisk/ansible
  ansible-playbook setup.yml

Since we ran the earlier Ubuntu-setup/all.sh script, some default values will have been applied for the database connection info that we’ll need to override.

  nano db_local.ini

Now you’ll need to replace db_username, db_password, and db_host with the same values you used up above. Save your changes to that file.

Now we need to grant our user Docker access so we don’t need to run future playbooks as root:

  sudo usermod -aG docker cloudadmin

We need to make this change take affect and as near as I can tell, just disconnecting and reconnecting won’t do it. To be safe, I have gone in and restarted the VM from the Azure Portal and then reconnected. Next we’ll run a nice long gradle build:

  cd ~/incubator-openwhisk
  ./gradlew distDocker

Now we can execute the rest of the playbooks:

  cd ansible
  ansible-playbook initdb.yml
  ansible-playbook wipe.yml
  ansible-playbook apigateway.yml
  ansible-playbook openwhisk.yml
  ansible-playbook postdeploy.yml

Testing OpenWhisk

With all of our Ansible playbooks run, we can now use the wsk command line tool to talk to execute functions on OpenWhisk. In order to do so, we need to either pass, or set, the API Host and Auth values for the command line. We’ll do the latter:

  cd ../bin
  ./wsk property set --apihost http://172.17.0.1:10001

In order to get the auth value out, we’ll print out the value from the auth.guest file:

  cat ../ansible/files/auth.guest

Copy that value into this command:

  ./wsk property set --auth AUTHVALUE

Now finally, we can invoke something:

  ./wsk action invoke /whisk.system/utils/echo -p message hello --result

If all goes well, your output should look like this:

  {
    "message": "hello"
  }

And now you’re running OpenWhisk. From here you might expand by running on a Kubernetes cluster, deploying applications that also run on-prem, etc.

Xamarin iOS Error Confusion

Mon, 06 Mar 2017 09:16:00 +0000

As I’ve continued working on the Xamarin.Forms application I’ve been building, I’ve learned a lot. One of the issues I ran into was an error in the iOS version of my application and as I didn’t find an easy to understand solution, I thought I would document it here. I’ll list the error first then explain the scenario and how to fix it.

AX Exchange error: Error Domain=Accessibility Code=0 “Remote service does not respond to _accessibilityMachPort” UserInfo={NSLocalizedDescription=Remote service does not respond to _accessibilityMachPort}

Part of the application revolves around uploading files. For Android this isn’t very difficult and it even makes sense as Android has a file system you can access and external storage in the form of SD cards. With iOS you can store files for your own app but not others (for the most part). However, you can access a user’s iCloud if they grant you permission. To this end, I started looking at the FilePicker Plugin for Xamarin and Windows.

In theory what this plugin would do is with one call open up a file picker connected to iCloud on iOS and to the disk on Android (and who knows on Windows). This plugin works great for Android. However, for iOS calling the PickFile method results in this error:

This functionality is not implemented in the portable version of this assembly. You should reference the NuGet package from your main application project in order to reference the platform-specific implementation.

At the time of writing, it appears the author knows about the issue but hasn’t yet pushed a fix out to NuGet. So instead, I took that code and baked it into my app for Android and iOS and it worked for both. However, when the picker pops up to let you pick a file from iCloud, it comes along with the error being printed out to Application Output over and over and over again:

AX Exchange error: Error Domain=Accessibility Code=0 “Remote service does not respond to _accessibilityMachPort” UserInfo={NSLocalizedDescription=Remote service does not respond to _accessibilityMachPort}

I did a bit of searching and didn’t find anything DIRECTLY related to the FilePicker but I did find something about custom keyboards and external testing frameworks.
Xamarin.iOS apps are wired to use Calabash for testing with Xamarin Test Cloud and you will find this in the AppDelegate:

#if ENABLE_TEST_CLOUD
			Xamarin.Calabash.Start();
#endif

Commenting that out led to the error no longer occurring. I’m not 100% sure what the is causing this issue but at least there is a quick fix.

Getting Realm to Build Xamarin Apps with VSTS

Wed, 14 Dec 2016 09:16:00 +0000

I’ve recently been working on a Xamarin.Forms project for Android and iOS and recently came across an issue that took some experimenting to get fixed so I thought I would share it for anyone else that might run into it.

Realm is a database designed for mobile applications and offers a safe, easy, non-ORM replacement for SQLite. The intent is that you can, for the most part, mark your data model objects as RealmObjects and Realm will handle all of the persistence for you. As with anything, it gets more complicated than that but so far it’s still much better for what I’m doing than SQLite. If I needed the ability to do offline synchronization with an online data source, I’d be looking at Azure Mobile Apps , but as I don’t I’m fine with what Realm will do for me.

Adding Realm to your Xamarin.Forms application just requires adding the Realm NuGet package to your projects. From there, you should be able to compile your projects without any issues.

However, if you have Continuous Integration set up to auto-build your projects and run tests with every build, it’s possible to run into an issue. I use Visual Studio Team Services to build all of my mobile projects and then deliver them to HockeyApp for beta testing. I’ll have to post more about setting up the Build Definition (the steps for building and uploading my compiled applications) but want to focus on the issue that having Realm in your projects has with the build process.

When you add Realm to your projects, it adds a Target as part of the package.
That step, called CopyRealmWeaver which copies RealmWeaver.Fody.dll as part of the build process. I won’t get into what Fody is but it’s a necessary part of using Realm. The XML found in the Realm.targets has the following inside of it:

<Target Name="CopyRealmWeaver" BeforeTargets="FodyTarget">
  <Message Text="CopyRealmWeaver" />
  <Error 
    Text="Solution directory was not set. If you are building via xbuild, specify by adding a /p:SolutionDir=/path/to/solution/folder argument. See github.com/realm/realm-dotnet/issues/656"
    Condition="'$(SolutionDir)' == ''" />
  <Copy SourceFiles="$(MSBuildThisFileDirectory)../tools/RealmWeaver.Fody.dll" DestinationFolder="$(SolutionDir)/Tools" />
</Target>

What this does is check to make sure $(SolutionDir) has been specified as part of the call to xbuild, or in the case of VSTS, msbuild. Provided that value has been specified, it then copies the RealmWeaver.Fody.dll from a tools directory in the packages folder into the Solution directory.

What’s wrong here

The problem here is that when compiling with VSTS, there is some step that changes the SolutionDir value to *undefined*. When I ran into this, it was especially weird as I couldn’t seem to find a reference to VSTS, build, and *undefined* anywhere. I did find a Stack Overflow post about Visual Studio replacing $(SolutionDir) with *undefined* which wasn’t the solution to my problem exactly but did get me on the right path. From there, I took a look at the call to MSBuild to see what was showing up:

2016-12-13T19:23:38.1392477Z ##[command]"C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe" "C:\a\1\s\src\Droid\MyApp.Android.csproj" /nologo /nr:false /dl:CentralLogger,"C:\a\_tasks\XamarinAndroid_27edd013-36fd-43aa-96a3-7d73e1e35285\1.1.1\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=39592de0-fb1c-4156-a73e-b2e8ee77129e|SolutionDir=C:\a\1\s\src\Droid"*ForwardingLogger,"C:\a\_tasks\XamarinAndroid_27edd013-36fd-43aa-96a3-7d73e1e35285\1.1.1\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"  /p:configuration="Release" /p:_MSDeployUserAgent="VSTS_db204fe6-401b-4488-b9c9-02229bdeafd2_build_25_317" /t:PackageForAndroid /p:OutputPath="C:\a\1\b/Release" /p:JavaSdkDirectory=" C:\Program Files (x86)\Java\jdk1.8.0_102"

What I want to highlight from that call to msbuild is SolutionDir=C:\a\1\s\src\Droid. It seems like we’re specifying a Solution Directory, but the error shows us that somehow, that is being overwritten. So we need to override that overwrite and ensure a value is in fact being passed in.

Thankfully, the Build Xamarin project build step has a spot for Additional Arguments at the bottom. In this case, I set the solution directory to the directory of my overall solution file and where the tools directory containing the RealmWeaver.Fody.dll is at. The format of the argument is important so this is what you should be using (adjusting the path for your) tools folder location of course:

/p:SolutionDir=”src”

With that done, I was able to run builds without any issue. This seem to be an Android only issue so you shouldn’t need to change anything on your iOS build.

Update 2-16-2017: A new error

After a recent update (to my code base), I found that my workaround was no longer working. The new error I was seeing was:

FodyTarget:
  Fody: Fody (version 1.29.4.0) Executing
  Fody: ProjectDirectory: 'D:\a\1\s\src\MyApp\MyApp.PCL\'.
  Fody: AssemblyPath: 'D:\a\1\s\src\MyApp\MyApp.PCL\obj\Release\MyApp.PCL.dll'
  Fody: Found path to weavers file 'D:\a\1\s\src\MyApp\MyApp.PCL\FodyWeavers.xml'.
##[error]Fody: SolutionDir "D:\a\1\s\src\MyApp\MyApp.PCL\src" does not exist.

What this appears to be doing is adding the SolutionDir that I specified above to the end of the PCL’s path. I was able to fix this once again by changing my Additional Arguments to:

/p:SolutionDir=”/”

I suspect this was due to a change in the Realm.targets XML file for the newer version of Realm that I updated to when I updated NuGets.

Announcing the Azure Usage and Billing Portal

Thu, 14 Jul 2016 09:16:00 +0000

Today I’m excited to announce that we’ve released the Azure Usage and Billing Portal as an open source project on GitHub. The Azure Usage and Billing Portal is a solution which enables you to review the usage and resulting billing information across multiple subscriptions. Currently, if you are an Azure consumer using multiple subscriptions, you’re options for viewing all of the usage over any given time period aren’t that great. The Azure Portal enables you to view usage and billing for individual subscriptions one at a time (both a breakdown of current charges, cost by service, and cost by resource) but if you’re using multiple subscriptions, trying to review all of the information there is inefficient. Furthermore, you are able to download a CSV file of Azure consumption for each subscription, but that is a manual process and would require processing afterwards.

Last year, Microsoft announced new APIs to provide a way to programmatically pull information on usage and rate cards for your subscriptions. Included in that announcement were a number of samples demonstrating how you can pull information for your own subscriptions. When this announcment came out, we had already been seeing requests from customers we were working with for a way to visualize and track their spend. This spurred my team into action to build something which would make consuming and seeing this data easier.

Once deployed, you can now register any subscriptions you want so that the daily usage will be polled and displayed in an easy to use Power BI dashboard. This dashboard enables you to slice data in many ways including by subscription, by resource type, by resource name, by geo, by date, and more. Furthermore, you can use the SQL Database that stores the usage and billing to build any sort of interface / alerting on top of the data you want.

Mustafa Kasap, the lead engineer on this project, wrote up a great blog post describing the project a bit more including some helpful images.

We’ve got a lot of plans for future feature additions and already a few issues to fix. We welcome any contributions or feedback on the project either on the blog posts or as issues on the GitHub site.

Going from Mobile Services to Mobile Apps

Fri, 04 Mar 2016 20:16:00 +0000

I’ve held off on updating my blog to really talk about Azure Mobile Apps as I was waiting for the .NET and Node.js backends for Mobile Apps to GA. Now that they have, I think it’s time to point every one in that direction. I’ve posted quite a lot on using Azure Mobile Services as the backend for Android, iOS, Windows, Xamarin, and PhoneGap apps, and many of the things I’ve talked about are still important, but people should be thinking about using Azure Mobile Apps instead of Mobile Services to backend their mobile apps going forward. I’ve put a link in all of my posts directing people here so that I can explain what’s new with Azure Mobile Apps and why you should look at them.

Azure Mobile Apps

Azure Mobile Apps is a Platform-as-a-Service that exist to provide an easy way to set up a backend for mobile applications (running on any OS). These backends support several features out of the box including: easy data storage, user authentication and authorization, push notifications, backend job processing, and much more. Using something like Mobile Apps enables you to have a powerful backend that you don’t have to spend valuable time building so that you can focus on building the best client applications you can. Several years ago, Microsoft released a service named Azure Mobile Services. This was effectively the first version of a backend service inside Azure. That means that Azure Mobile Apps is version 2. In addition to all of the features that Mobile Services provided, Mobile Apps provides additional funcationlity including easy and more powerful scaling, deployment slots, traffic routing and management, VPN support, and much more.

Going forward, anyone looking at using a backend service in Azure for their mobile applications should be looking at the Azure Mobile Apps service. I’ll be posting more about using Azure Mobile Apps soon, but wanted to point people in the right direction. You can find below a number of links relevant to Azure Mobile Apps and converting from Mobile Services:

Creating a Node.js Azure Mobile App from OS X or Linux

Fri, 04 Mar 2016 20:16:00 +0000

In today’s post, I’m going to walk through how you can set up a new Azure Mobile App backend running Node.js entirely from OS X or Linux. To do this we’ll use the following tools:

I won’t go through installation steps for each of those pieces, you can find that at the accompanying link. Instead we’ll focus on what to do once you have everything installed.

Connecting to you Azure account from the CLI

The first step is to turn on Azure Resource Management mode using the following command:

azure config mode arm

Next, authenticate to your Azure account. Open a Terminal window and enter

azure login

You will be prompted to open a web browser and given a URL like http://aka.ms/devicelogin and a code to enter. After entering the code and logging in with your Azure account, return to the terminal.

All subscriptions available to your account will be added to your local account and you’ll be connected to the first Azure subscription as the default. If you have multiple subscriptions and want to change to a different subscription, you can first list them off with

azure account list

and then change subscriptions with

azure account set <subscriptionNameOrId>

Creating a Resource Group

Within Azure, instances of any services you create are done so as part of a Resource Group. This is a logical container that holds related resources for an application. What matters here is that we need to create a Resource Group before we can create any resources. You can read more about Resource Groups and Azure Resource Manager (which we’ll mention a bit more delow) here. To create our group, we run this command:

azure group create -n <ResourceGroupName> -l "<Location>"

So for my group, I ran this command:

azure group create -n MyMobileAppResourceGroup -l "West US"

Shortly there after, you’ll get the output of that command:

info:    Executing command group create
+ Getting resource group MyMobileAppResourceGroup                              
+ Creating resource group MyMobileAppResourceGroup                             
info:    Created resource group MyMobileAppResourceGroup
data:    Id:                  /subscriptions/<SubscriptionID>/resourceGroups/MyMobileAppResourceGroup
data:    Name:                MyMobileAppResourceGroup
data:    Location:            westus
data:    Provisioning State:  Succeeded
data:    Tags: null
data:    
info:    group create command OK

Now we’re ready to create our Mobile App.

Creating our Mobile App (and SQL DB)

Many resources in Azure have specific sections under them for manipulation of those resources. You can see a full list by just running

azure

at the command line. As of writing, that includes resources such as webapps, vms, storage accounts,and many more. What it currently doesn’t include is anything for Mobile Apps. This means that we have to handle the creation of our Mobile App a bit differently. Thankfully, Azure Resource Manager has support for templates (JSON files) which declaritively define a deployment. Put planely, these are JSON files that detail the pieces involved in a deployment such as what services to create (a SQL DB and Mobile App) along with any information needed to create those resources (i.e. names, locations, usernames, passwords, etc). You can take an existing architecture and get a template from it, or you can start with the many pre-created templates available on GitHub to start your deployment. Today we’re specifcially going to make use of a template for a Mobile App. Within that repository there are two JSON files: azuredeploy.json and azuredeploy.parameters.json. You’ll want to download both of those files locally to your computer.

Before we can deploy the template, you’ll need to edit the azuredeploy.parameters.json file to specify the name of your Mobile App, the SQL Server username and password, and the location:

{
  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "appName": {
      "value": "mobileappfromthecli"
    },
    "location": {
      "value": "West US"
    },
    "sqlServerAdminLogin": {
      "value": "NewAdmin"
    },
    "sqlServerAdminPassword": {
      "value": "My$up3rPassWERD"
    }
  }
}

With that done, we can now deploy to Azure with this command:

azure group deployment create -f azuredeploy.json -e azuredeploy.parameters.json -g MyMobileAppResourceGroup -n MyMobileAppDeployment

Here we’re specifying the template file, the parameters file, the group to deploy to, and the name of the deployment. This command will take a few minutes to complete but when it’s done, you should see something like this:

info:    Executing command group deployment create
+ Initializing template configurations and parameters                          
+ Creating a deployment                                                        
info:    Created template deployment "MyMobileAppDeployment"
+ Waiting for deployment to complete                                           
data:    DeploymentName     : MyMobileAppDeployment
data:    ResourceGroupName  : MyMobileAppResourceGroup
data:    ProvisioningState  : Succeeded
data:    Timestamp          : 2016-03-04T06:25:53.9360068Z
data:    Mode               : Incremental
data:    Name                     Type          Value                       
data:    -----------------------  ------------  ----------------------------
data:    appName                  String        mobileappfromthecli         
data:    location                 String        West US                     
data:    hostingPlanSettings      Object        [object Object]             
data:    sqlServerAdminLogin      String        NewAdmin                    
data:    sqlServerAdminPassword   SecureString  undefined                   
data:    sqlDatabaseEdition       String        Basic                       
data:    sqlDatabaseCollation     String        SQL_Latin1_General_CP1_CI_AS
data:    sqlDatabaseMaxSizeBytes  String        1073741824                  
info:    group deployment create command OK

Here we get a lot of details back indicating that everything was provisioned successfully. This means that we’ve succesfully created a Mobile App, a SQL Server, a SQL Database, and a Notification Hub. Today we’re just focusing on the Mobile App.

Setting up a Git repo

Unfortunately, we’ve reached an impasse as far as what can be done from the command line. We can (and will) generate our app backend using the command line, but we can’t really set up a way to deploy that code to our Mobile App. Instead, we’ll go to the Azure Portal to star the next step.

Open up the Azure Portal and look for App Services on the left navigation (if it isn’t showing up, look for Browse at the bottom and then find App Services from there). Find your App Service in the list (if this is the first thing you’ve created, there will only be one listed). We’re focusing on doing as much as possible from the command line today, but everything we’ve done so far (create our App Service and connected services) can be done from the portal along with MANY things that can’t (like what we’re about to do). When oyu first open your App Service, the Settings blade should be open by default, but if not, at the top of your App Service’s blade, you should see Settings with the familiar gear image. Click that and then in the Settings blade (to the right of your App Service), look for Continuous Deployment underneath PUBLISHING.

Here we’ll need to choose Choose Source to configure deployment. There are many (7 at writing) different options for deployment, to make things easy today, we’ll just choose Local Git Repository. This will create a Git repository within Azure which we can push and pull from to deploy changes to our Mobile App backend. After a few moments, the process will complete and the body should change to say “No deployments found.”

Next we need to set up credentials. Under Continuous Deployment you should see Deployment credentials. Once you’ve gone into that blade you can enter a username and password for Git and FTP.

The last thing we’ll do in the portal for now is get our Git URL. Return to the Settings blade and scroll up to Properties. Within that blade you’ll see Git URL. Grab that for later.

Creating a Node backend

You should have already installed Yeoman (listed in the tools at the top). I left out one tool that plugs into Yeoman. If you haven’t used Yeoman before, it’s a tool for scaffolding out projects. If you’ve used something like Visual Studio, Eclipse, or Xcode before, you’ve almost certainly had the File -> New Project experience. When it comes to developing in Visual Studio Code (or sublime text, atom, etc), trying to create a new project type wizard for each editor would be a bit excessive. For that reason, ther are thousands of generators that can be installed into Yeoman to help scaffold our projects of all types (Node, wordpress, jeykll, asp.net, etc). For today, you’ll need to install the azure-mobile-apps generator with this command:

sudo npm install -g yo generator-azure-mobile-apps

Note that you may not need to use sudo but I did so I’ve included it. Next we create our backend:

yo azure-mobile-apps

NOTE that this drops files into the directory you’re in so create a directory for your app first. That will generate a bunch of files including a fully functioning backend for our apps.

Deploying to Azure

First we need to setup git locally in the directory you just created your mobile app in:

git init

Now we add the remote using the Git URL that you got above:

git remote add origin https://username@MyMobileApp.scm.azurewebsites.net:443/MyMobileApp.git

Now we can add, commit our files, and push to Azure:

git add .
git commit -m "Initial check-in"
git push origin master

You’ll be prompted for the password which you entered in the credentials blade above. It will take a few minutes to push the code up to the server and restart your site. If you now browse to the site (you can do so easily by returning to the portal and clicking the Browse button in the blade for your App Service) you’ll be taken to a page which says:

You’ve encountered an Azure Mobile Apps Site

That is our default homepage. The next step is to test out the Tables and APIs functionality provided by our Mobile App. Currently, the mobile app generator creates one table and one API, though both of them require authenticated clients. We’ll turn off authentication in order to properly test things out (in an easier manner).

Turning off Auth and adding Todo Items

Open up Visual Studio Code (or your editor of choice) and open the directory for your Mobile App. Inside of hte server folder, you’ll see the folders api and tables. Start by opening api/example.js. Near the bottom, you’ll see:

api.get.access = 'authenticated';

You’ll need to change that to anonymous like so:

api.get.access = 'anonymous';

If you haven’t played with Mobile Apps / Services before, changing from authenticated to anonymous means we don’t have to send over a Mobile Apps Auth Token in order to call the API. Since we’re just going to test out our APIs and tables from the command line (without a real app) we aren’t going to authenticate today.

Next open up tables/example.js and edit:

table.access = 'disabled';

To be:

table.access = 'anonymous';

The last thing we’ll do is add a new table for Todo Items. Create a new file within the tables directory and name it todoitem.js and put in the following contents:

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Defines the list of columns
table.columns = {
    "text": "string",
    "complete": "boolean"
};
// Turns off dynamic schema
table.dynamicSchema = false;

module.exports = table;

Now you can push all of your changes back up to Azure:

git add .
git commit -m "Updating tables and APIs"
git push origin master

Testing from the command line

Normally, the next step would be to create an iOS, Android, or Windows app to start hitting your Mobile App backend. That’s outside the scope of today (but if you want to get started quickly, you can go to the Quick Start option under the Settings for your Mobile App to generate clients quickly). Today we’re going to test wiht CURL which is a command line tool for creating HTTP requests. We’ll start simple and just pull down the home page. Go to the command line and enter this (make sure you change the URL to match your app’s):

curl http://<YourMobileApp>.azurewebsites.net/

This should output the HTMl for your web page. Next let’s try hitting our APIs:

curl --header "ZUMO-API-VERSION:2.0.0" http://<YourMobileApp>.azurewebsites.net/api/example

If you took a look at the api/example.js you’ll know when you do a GET request against it, it just take a data object with one value in it and returns it as JSON. So when we make the above request, we get the following:

{"example":20}

Next up, let’s call the tables:

curl --header "ZUMO-API-VERSION:2.0.0" http://mobileappfromthecli-n3ajngt3gbvjs.azurewebsites.net/tables/example

This will just return [] because the example table isn’t set up to really do anything. The Todo Item table will be much better:

url --header "ZUMO-API-VERSION:2.0.0" http://mobileappfromthecli-n3ajngt3gbvjs.azurewebsites.net/tables/todoitem

Right now, this will also return [] becuase there is no data in our table. Let’s add some:

curl --data '{"text":"test","complete":false}' --header "Content-Type: application/json" -X POST --header "ZUMO-API-VERSION:2.0.0" http://mobileappfromthecli-n3ajngt3gbvjs.azurewebsites.net/tables/todoitem

Here, we’re doing a similar request as before but we’re passing in data, changing the Content-Type with an additional header, and lastly we’re changing the request type with the -X parameter so we can do a POST instead of a GET. When we post that item, we’ll get back the updated item which includes the content of what we sent up in addition to the following field: id, version, createdAt, updatedAt, and deleted.

Now that we’ve inserted data, let’s pull the data again and see what comes out:

url --header "ZUMO-API-VERSION:2.0.0" http://mobileappfromthecli-n3ajngt3gbvjs.azurewebsites.net/tables/todoitem

We should get back a list of all items we’ve saved so far (so in our case one item):

[{"id":"427a9e3d-32a6-483f-9e51-9c4a82349d96","version":"AAAAAAAAB9I=","createdAt":"2016-03-04T17:48:04.368Z","updatedAt":"2016-03-04T17:48:04.384Z","deleted":false,"text":"test","complete":false}]

Summary

Today we walked through how you can create an Azure Mobile App from the command line using open source tools like Yeoman, the Azure CLI, Node.js, and Visual Studio Code. The Azure Portal provides a great experience for doing all of this as well, in addition to even more features that Azure Web Apps provides.

Codemash 2016

Thu, 07 Jan 2016 20:16:00 +0000

I just finished giving my presentation at Codemash 2016 and thought it went great. I presented on running .NET on Linux and OS X and had a nearly full room of very engaged people. My presentation focused on ASP.NET 5 and .NET Core, their recent status as a Release Candidate, and how developers can use, run, and deploy them on Linux and OS X. People were super excited to see how fast you could get up to speed on running .NET on Linux. If you’re interested in checking out my slides, you can find them here. Thanks to all who attended and reach out to me if you have questions.

Using Fragments with the Navigation Drawer Activity

Mon, 07 Dec 2015 20:16:00 +0000

TLDR: If you want to grab the sample code, it’s available on GitHub.

I’ve been working on a new Android application and just recently ran into a problem that I was surprised didn’t have a clearer solution. The primary means of navigation in the app was going to be a Navigation Drawer. If you’ve used an Android device, you’ve almost certainly seen and used this design pattern:

The Navigation Drawer is a slide out menu that enables users to navigate around the different areas of the application. Typically, when the user taps one of the items on the menu, the content page is reloaded. Instead of starting a new activity where the user has to go back (via the back button or a back button in the top left of the screen), the navigation drawer (usually via the familiar hamburger button) stays available as you go from one area of the app to others (it seems like it’s common for a few pages to launch and require the back button such as Settings and Help).

If you go into Android Studio right now and create a new application and base it off the Navigation Drawer Activity, you’ll get a very basic app with a single activity and the nav drawer will be set up fairly similarly to what you see above. What you won’t see though, is how to actually navigate between different “content pages” when you tap the different menu options in the nav drawer! If you are familiar with some Android development, this might be a bit surprising. In earlier days of Android development the way you got from one page to another was to have several Activities and to use an intent to launch each new activity. This doesn’t really mesh with the nav drawer though as you’d have to have the same nav drawer on several activities

Enter the Fragment

When Android moved from 2.X to 3.X, they were moving from only focusing on phone form factors to also tablets. 3.X was never officially released to run on phones, but they started thinking about how to make page constructs that weren’t just in the form of activities tied to layouts. The solution they came up with was Fragments. A fragment is a way of composing a part of an activity. It has it’s own life cycle, deals with it’s own inputs, and each activity can contain multiple fragments. The easiest way to see fragments in action is to create a new application and use the Master / Detail Flow. This creates an application that works on both tablets and phones and shows how you can show multiple fragments at once (on the tablet) or a single fragment (on the phone). The bulk of the code is the same regardless of if you’re showing one fragment or both which is part of the reason you use fragments, so you don’t have to reproduce code in multiple places.

The Problem

The problem I ran into with the Navigation Drawer sample is again that it doesn’t really demonstrate how you should do navigation inside of it. As I said before, you can always use the old route of launching new activities. However, you’ll need to then reuse the navigation drawer everywhere. This can be done and someone I was tweeting with about this issue even put together a sample of it on GitHub. Unfortunately, if you run that, you’ll see that the navigation between different activities isn’t as smooth as I’d like it to be. Namely, the nav drawer doesn’t slide back before showing the new activities content. What I want to happen is when the user taps an item on the nav drawer, the content page should already be loading / loaded while the drawer slides back to be closed. As far as I’ve seen so far, this can’t be done with multiple activities. But it can with fragments. One thing to note is that I believe you could also do custom view inflation and deflation though you’d be wrapping everything in one activity.

NOTE: After I’d already started this post, karnamsupreeth updated his code sample to provide a brief delay after tapping a nav item and launching the new activity. This was MUCH closer to what I originally thought of and is a valid way of handling things if you want to use Activities. I’ll continue to post the fragment solution but I’d definitely consider using his example as well. It still doesn’t actually load the new activity until after the delay so you’re note sliding the drawer back to reveal the new content that has been loaded.

What’s wrong with Fragments

Before I get into the specifics of adding fragments to the nav drawer sample, I just want to say that I don’t hate fragments, I just don’t like them. Just a few searches online will yield a lot of conversations about whether fragments are good or bad. Because fragments live inside of an activity, and both the activity and fragment have life cycle and event handling, things can be overly complex. Additionally there are memory implications and other concerns you might run into. Suffice to say, I’m going forward with fragments in my solution though that doesn’t mean I’m sold on them being the best solution.

The Initial Layout

When you first create the Navigation Drawer Activity, there are 5 files we’ll look at:

MainActivity.java - this is the code behind for everything in our app.
activity_main.xml - this is the layout for the app including the nav drawer and an include for the app_bar_main.
app_bar_main.xml - this is the layout with the toolbar (at the top), a floating action button (at the bottom right), and an include for content_main.
content_main.xml - this is the layout for the content of the main page.
nav_header_main.xml - this is the UI for the top part of the nav drawer.

Now I’ve already said that I don’t think this is the best example of how to do navigation because it doesn’t show you what to do when you tap an item in the nav drawer (it only demonstrates how to get the event when an item is tapped in the onNavigationItemSelected method). Furthermore, from looking at how it displays the content, it’s not clear what to do. In the MainActivity’s onCreate method there is a call to:

setContentView(R.layout.activity_main);

This is what you typically see in an Activity and binds the UI of a layout file to the Activity code. In this case, the activity_main layout contains the nav drawer and an include statement for the app_bar_main. The app_bar_main in turn contains the toolbar at the top and does an include on the content_main. It would seem like the solution is to replace the content of the second include whenever the user taps an item on the menu. However, you can’t really replace an include like that. We could use custom views and inflate and replace them whenever we want, but that might require a significant amount of additional work (or maybe not, hopefully someone can provide a solution that does that). Adding fragments ends up being relatively easy.

Adding Fragments to the Sample

First, open up the app_bar_main.xml, comment out the include and add a new FrameLayout:

<!--<include layout="@layout/content_main" />-->

<FrameLayout
  android:id="@+id/flContent"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  android:layout_marginTop="?attr/actionBarSize"/>

This FrameLayout is what we’ll use to load our fragments into. Next, you’ll want to add a few fragments. To do so, right click on your project, or go to File –> New and from the Fragment list choose Fragment (Blank). Add at least two fragments to your project so you can demonstrate moving between them. The next step is to load a fragment when the app first launches. Go to the MainActivity’s onCreate method and put the following in after the call to setSupportActionBar:

Fragment fragment = null;
Class fragmentClass = null;
fragmentClass = FragmentOne.class;
try {
    fragment = (Fragment) fragmentClass.newInstance();
} catch (Exception e) {
    e.printStackTrace();
}

FragmentManager fragmentManager = getSupportFragmentManager();
fragmentManager.beginTransaction().replace(R.id.flContent, fragment).commit();

You’ll then need to add OnFragmentInteractionListener to the interfaces your MainActivity implements and also implement the onFragmentInteraction method. Finally, in the onNavigationItemSelected method, you can add the ability to load different fragments when menu items are tapped:

public boolean onNavigationItemSelected(MenuItem item) {
    // Handle navigation view item clicks here.
    int id = item.getItemId();
    Fragment fragment = null;
    Class fragmentClass = null;
    if (id == R.id.nav_camera) {
        fragmentClass = FragmentOne.class;
    } else if (id == R.id.nav_gallery) {
        fragmentClass = FragmentTwo.class;
    } else if (id == R.id.nav_slideshow) {
        fragmentClass = FragmentOne.class;
    } else if (id == R.id.nav_manage) {
        fragmentClass = FragmentTwo.class;
    } else if (id == R.id.nav_share) {
        fragmentClass = FragmentOne.class;
    } else if (id == R.id.nav_send) {
        fragmentClass = FragmentTwo.class;
    }
    try {
        fragment = (Fragment) fragmentClass.newInstance();
    } catch (Exception e) {
        e.printStackTrace();
    }
    FragmentManager fragmentManager = getSupportFragmentManager();
    fragmentManager.beginTransaction().replace(R.id.flContent, fragment).commit();

    DrawerLayout drawer = (DrawerLayout) findViewById(R.id.drawer_layout);
    drawer.closeDrawer(GravityCompat.START);
    return true;
}

Here I’m just loading one of the two fragments I’ve added to my app. Note that because I have two different fragments, I had to implement the interfaces for both FragmentOne.OnFragmentInteractionListener and FragmentTwo.OnFragmentInteractionListener.

That’s all you need to do to implement fragment loading in your Navigation Drawer. What the user taps a menu item, the drawer will slide back in smoothly and the new fragment will have already started / finished loading. This also prevents any possible jankiness that you could see when launching a new activity. One last thing to note is that if you switch to a different fragment and then rotate the device or cause another recreation of the activity, the code above will cause the first fragment to be reloaded. One easy way to deal with that is to wrap the fragment block in the onCreate method in a check to see if the savedInstanceState is not null like this:

protected void onCreate(Bundle savedInstanceState) {
    ...
    if (savedInstanceState == null) {
        //Fragment load code
    }
    ...
}

One actual last thing is that there are definitely optimizations you could make on the code and event handling here but this is a good start. You can grab the source code from this demo on GitHub.