I’ve been doing this blog series – 29 blog articles – since late March. In the cloud world, that’s a lifetime, so let’s take a look at what new things you need to be aware of when developing Mobile apps.
There are really three distinct technologies you need to understand. Native development uses the platform specific tools (XCode or Android Development Studio) and languages (Swift, Objective-C and Java) to develop the mobile app. These offer the highest level of compatibility with the features of the mobile phone. However, there is zero code reuse between them. A common developer theme is DRY – Don’t Repeat Yourself. I’m developing two apps – one for Android and one for iOS – that do the same thing. Why can’t I reuse the models and business logic within my code? I’m not a fan of native development for that reason.
Apache Cordova places your app in a web view. I like this when there is an associated website that is already responsive. It allows you to wrap your existing web code (which is likely a SPA these days) into an app. You get access to the same libraries as your web code and you can leverage a good chunk of the talent you have for developing web code when developing your mobile app. It does have drawbacks, though. The UI is defined inside of HTML/CSS ultimately, which means it’s relatively hard to get a platform consistent UI. The UI will either look like an Android app or like an iOS app, even on the alternate platform. In addition, the code runs inside a Web view. This is a sandboxed area that has limitations. The limitations are becoming less important. Basically, if you want to access the bleeding edge of hardware, this is not the platform for you. Finally, I find performance lags that of native apps – there is a memory and CPU overhead. This may not be important in small apps, but as the apps grow, so does the memory and CPU requirements – the ceiling is lower.
The final segment is cross-platform apps and that’s where Xamarin comes in. Xamarin allows you to write apps in a common language – C# or F# with a .NET runtime. However, the apps compile to native code. This has two advantages. Firstly, you get native performance – the CPU and memory considerations I mentioned with Hybrid Apps are at the same level as for native apps. Secondly, you get access to the entire API surface that the device offers. Unlike native apps, you can encapsulate your models and business logic in a shared library, allowing for code re-use.
In the past (pre-acquisition), I was loath to suggest Xamarin for small projects because of the cost associated with it. With the acquisition, Microsoft made the technology free. For small groups, you can use Xamarin with Visual Studio Community. For bigger groups, the various Visual Studio offerings provide the appropriate licensing. In addition, Microsoft made Xamarin Studio free for Mac users, which – in my experience – is the platform of choice for most of the mobile developers. This means you don’t have to any excuse to not use Xamarin for developing your native apps.
Those of you that have looked into Xamarin before will know that there are two “modes” for developing Xamarin apps. Xamarin.iOS and Xamarin.Android provide distinct advantages by providing access to the platform features directly, whereas Xamarin.Forms provides a cross-platform UI capability as well. I am recommending that teams use Xamarin.Forms for cross-platform enterprise apps (where differences in the look and feel of the app are less important), but using the Xamarin.iOS / Xamarin.Android for consumer apps. This allows you to tune the UI to be very platform specific.
File Sync for Node Backends
This is really recent. The team released the azure-mobile-apps-files NPM package to allow the implementation of File Sync with node backends. It’s definitely still in preview – like most of the other functionality in File Sync, but it means you don’t have to make a choice of backend based solely on features available. The Azure Mobile Apps Node SDK has been one of our most active release tracks, and I expect more features being pulled into the alternate Node implementation.
Apache Cordova Offline Sync
I believe I’ve mentioned this several times, but it bears repeating. Azure Mobile Apps development – all the server and client SDKs – are open source. All the issues are on GitHub Issues, the repositories are on GitHub and the team develops in the open. That’s why I can safely say that Apache Cordova Offline Sync is coming “Real Soon”. If you want to view any of the repositories, you can do a search on the Azure GitHub organization page. Got a bug or an idea? File an issue. We don’t bite!
RIP Azure Mobile Services
Unfortunately, I had to close down Azure Mobile Services. I’m rather sad about that since I think it was an awesome service. However, it was reliant on older technology that couldn’t easily be upgraded. As a result, we were handling customer issues dealing primarily with new libraries not working on older versions of Node. To aid the process, we’ve done two things. The first is a single-click migration of the Mobile Service to Azure App Service. It doesn’t change any of the code (and you can clone the git repository and update the code any way you see fit). My recommendation, however, is to upgrade your code to Azure Mobile Apps and utilize all the good things we’ve been doing. Upgrading also allows you to use any version of Node that you wish, which is a constant request.
To aid in upgrading your site to Azure Mobile Apps, we’ve also released a compatibility layer for node sites (which accommodates about 75% of all Mobile Services). This will take your existing mobile services site (that you have cloned after migration) and turn it into an Azure Mobile Apps site. Afterwards, your code-behind files for table controllers and APIs are all compatible with Azure App Service. Then all you have to do is publish your site, upgrade the SDK in your clients (including changing the URL to point to your new App Service) and publish those new clients to the app store. At this point you will be running both sites (the v1 site and the v2 site) in parallel.
There is a small question of database compatibility. You can fix this with Views (I mentioned the process for this in Day 19 – it needs to be adjusted for the new situation). However, once that is done, you are ready to rock the new environment.
One of the biggest gotchas I see are people running Azure Mobile Services but referencing newer SDKs & Documentation, or people running Azure Mobile Apps and referencing older SDKs and Documentation. We get it – it’s confusing. MAke sure your libraries, documentation and lingo are all in line on both the backend and frontend / client.
When Will .NET Core be supported?
I’ve lost count how many times I’ve been asked this. ASP.NET Core is an awesome technology and I’m looking forward to stability and GA for it. However, that isn’t the only technology we use in the stack. We also use Entity Framework, System.Web.OData, Automapper, and others. Until the whole stack is compatible with .NET Core, we won’t be releasing a .NET Core version of the Azure Mobile Apps Server SDK. Rest assured, we are in touch with the right teams and it’s definitely on our radar.
Contacting the team?
One of the great things about this team is how involved they are in the community. There are a multitude of methods to get in touch. If you have a problem, then the best way is to post a question on Stack Overflow. This reaches the widest possible audience. You can also reach us via the Azure Forums, on Twitter, or via comments on our documentation (although we prefer that you post on Stack Overflow if you have an issue). You can also open an issue on one of our GitHub repositories.
Finally, the App Service team has a new team blog. I’ll be publishing further Azure Mobile Apps posts there instead of here. This blog is going back to (mostly) my own side work.
I hope you’ve enjoyed reading the last two months worth of posts as much as I’ve enjoyed writing them. I’ve included an Index – take a look under Pages to your right.