30 October, 2016

Building a single (cloud-based) backend supporting multiple mobile apps

Being the architect as well as hands-on implementor of a real-life system supporting a number of concurrent mobile applications (in both Google Play and Apple AppStore); I’ve learned a thing or two during the development and evolution of this system (now in gen. 3). What are my take-aways from this process? And what are the pit-falls?

Before we dive into the meaty part - maybe you should ask: why are we looking for one backend-system and not a bespoke and optimized backend-system supporting each specific mobile application? Wouldn’t that be a better approach? Well - I think it goes without saying; but the cost and effort of maintaining several different systems when you can do with just one aludes to a pretty good reason seen through my set of financial eyes.

Obviously - there are limits to how different these mobile (client) applications can behave and still being supported by the same system (you can’t mix automobile apps with fitness apps, can you?), but given that most companies tend to produce applications within the same realm or domain - it does make sense in a company-setting to strive for an as simple and generic system as possible. So that’s what we are trying to realize.

Before we move on - the audience to benefit most from this post will primarily be system architects, secondly developers as it becomes rather technical as we walk through the system...


Goal

The overarching goal is to have a system that can support not only your current applications, but also new applications that you do not yet know. Furthermore, the system should be able to respect different “twists" the mobile applications can exhibit. How can you realize this goal?


Architecture

An idea of the overall picture is required before diving into the specifics. You need to be able to see that before you can appreciate the details. The overall picture looks like this:
image-105

System components

Security

The graphics above can seem like a lot of arrows, but the key concept is that there is a Token System responsible for supplying the mobile Clients with a Token provided the credentials they present are accepted. This token is next presented in every call to the WebAPI (using the HTTP Auth-header). The WebAPI in this scenario constitutes the business logic of the system and is implementation-wise; a REST-API.

Given that the token obtained is part of every call to the WebAPI, the WebAPI can remain stateless and from the Token-value itself establish which context it is being invoked (context = App A or App B or…).

As the task of validating whether a given set of credentials are valid, by design is kept away from the business logic (WebAPI), the business logic can remain indifferent as to how the User is identified. It can simply rely on the simple fact that a token is present every time it is being called. An added advantage to the separation of concerns here is that the business logic also does not care whether credentials are coming in in the form of username/password, facebook integration, Google Login or an X509-certificate. All this is the responsiblity of the Token System.


Business Logic

The business logic should be able to adapt to the mentioned deviations in the clients requirements. Maybe when the caller is App A it should return Users with first name starting with Joe, whereas when being called in the context of App B it should return Users with 5 records in the database? This is where factories and plugins are relevant. Actually normal and standard object-oriented design, but shielded behind interfaces and WebAPIs.


Notifications

Most mobile applications benefit from some form of push notifications. It has by now become an expected behaviour that Apps interact with the user by notifying him of relevant and contextual important information. Sending out notifications to Android phones or IOS phones relies on 2 different systems (FireBase by Google and Apples Push Notification Services), although the message itself is JSON in both cases. To realize a simple sub-system that is capable of sending out messages to the phones, also here - this is kept to a dedicated system with these capabilities.


Implementation

Now that we have an idea of the overall picture (how the architecture is layed out and who is responsible for what); we can move on to a more technical part of this post. The implementation in this case is built on the Microsoft stack - so the following technologies are used:
  • MEF (adaptation to various contextual changes)
  • WebAPI 2 (interface, REST API)
  • Entity Framework (database access)
  • Swagger IO (documentation of REST API)
  • SQL (standard RDBMS)
  • Azure (hosting)
  • C# (runtime 4.6)

MEF and logic adaptation

To appreciate and fully understand the choice and usage of MEF - you need to understand how that works. MEF is an injection based implementation from MS that allows you to build loosely coupled implementations. As seen below - the interface implementation is found in 3 different assemblies (one default implementations and two supporting potential overrides for each context). Loading of the implementation is performed by an ObjectFactory found in the interface assembly. It will look in the /bin directory for implementations supporting a given interface.
image-104
To allow the MEF system to determine which implementation it should load - it uses metadata found as decoration on the various implementations. By default - it will load the "DEFAULT" implementation, but if an implementation is found with specific support for a context (e.g. App A) - this is loaded instead and returned to the webapi.
image-103


WebAPI

The interface the mobile app developer is faced with is REST based. To make it as easy to consume as possible it follows the conventions used by most REST-based API nowadays. It makes heavy use of the standard HTTP-verbs (GET, POST, PATCH, DELETE) and makes the URI part of the interaction of the resources.


Security

An attempt to invoke any method requires the Client to present a valid security token as previously mentioned. If one is not present - the system refuses to execute and terminates the request (by design). This is manifested by the WebAPI as a standard HTTP-error code = .405




As seen from the image above - the web method is decorated with metadata that suggests that this method cannot be called without presenting a AuthToken (security token).


Hosting (Azure)

This section actually could be worth an entire blogpost in its own right (and I might write one), but simply put - this is hosted in the cloud to realise the scalable nature of Azures engines.


Documentaton

The minute I see a word document "constituting" documentation on a live system; I become suspicious. How relevant and current is this "documentation"? Does it reflect what Im seeing when programming against this webAPI? To remove that problem, Swagger IO is used to document the API. Swagger is a superior reflective toolset that generates documentation when you press F5 (refresh) in your browser.





It will generate documentation like you see here:




Final thoughts and comments

Finally - before you go all "religious" on me - this is just one route to the goal. There are other ways. It just happens to be the approach I found to be the better one ;-)


Mobile Apps

PsoMentor:


RheumaBuddy:

20 September, 2016

How to remove the Dashboard on a Mac

If you are just as annoyed as I am with the useless Dashboard app on a Mac - there is one effective way of killing it.

Open a terminal window and write:

Remove:

defaults write com.apple.dashboard mcx-disabled -boolean YES && killall Dock


Enable

defaults write com.apple.dashboard mcx-disabled -boolean NO && killall Dock

14 September, 2016

Running Xcode 7.3.1 and Xcode 8.0 on the same machine

If you need to be running Xcode 7.3.1 and 8 together (as I am!); you can not install them just like that. You need to fiddle a bit with the apps to have them work together.

  • Download the Xcode 7.3.1.dmg file from apple developer portal.
  • Download the Xcode 8.xip file from apple developer portal.

Once you’ve done that, you can install version 7.3.1 into “applications”:

Xcode 7.3.1

  1. Double click the .dmg file to open the “drive” it represents.
  2. Drag the Xcode icon into “application"
  3. Rename the resulting xcode.app in “applications" to xcode_7.app


Xcode 8

Now - the turn comes to Xcode 8. You unzip the .xip file and drag into Applications the resulting xcode.app file (it’s version 8).

You now have 2 versions of Xcode on your Mac and start them independently.

  • Xcode_7.app
  • Xcode.app


The reason I’m not renaming the XC8 version is due to future updates coming from Apple. I’m not sure how they search for apps locally during an update process...

13 September, 2016

Enums in C# vs. Swift - how to

The concept of a “flagged enum” is quite a powerful one as it allows you to express multiple things with just a simple number (integer). Coming from a .NET background - the ease of flagged enums found in C# is not that easily found in Swift I’ve come to realize. The expression in Swift is somewhat different and honestly a bit difficult to grasp.

Let’s give it a try:

C#

In C# you express an enum like this:

[Flags]
public enum SecurityLevel : Int{
	case NoAccess = 0
	case Employee = 1,
	case LineManager = 2,
	case DivisionManager = 4,
	case RegionalManager = 8,
	case CountryManager = 16}


This constructed example serves a purpose like:

var person = new Person();
person.AccessLevel = 3 //meaning access as Employee AND LineManager

This will allow us to model a Person with multiple access levels (security levels) with just a single integer. An easy way to store in the backend database as well!

Swift

So - how does this look in Swift?

public struct securityLevel : OptionsSetType {
	let rawValue : Int
	static let noAccess = securityLevel (rawValue: 0)
	static let employee = securityLevel (rawValue: 1 << 0)
	static let lineManager = securityLevel (rawValue: 1 << 1)
	static let divisionManager = securityLevel (rawValue: 1 << 2)
	static let regionalManager = securityLevel (rawValue: 1 << 3)
	static let countryManager = securityLevel (rawValue: 1 << 4)
}


Quite a different beast, ey? How can this be the same you are thinking?
The strange << operator is called a bitwise left shift operator and and actually does what it says - it moves all bits in the array to the left by the number specified.

Looking at the securityLevel struct again, we have:

setting the value to noAccess:
0|0|0|0|0|0 = 0
setting the value employee:
0|0|0|0|0|1 = 1
setting the value lineManager:
0|0|0|0|1|0 = 2

combining the values (employee AND lineManager)
0|0|0|0|1|1 = 3


So the left shift stuff is actually initializing the struct with the value of 1, and then it moves all bits a number of slots to the left to end up with a whole new number. In our example with the combined employee and lineManager - we will see first the employee being set (rawValue:1 <<0)

  • init with 1 -> 0|0|0|0|0|1
  • next move it 0 places to the left -> 0|0|0|0|0|1
  • end result = 1

Next is the lineManager value (rawValue: 1 << 1):

  • init with 1 -> 0|0|0|0|0|1
  • next move it 1 places to the left -> 0|0|0|0|1|0
  • end result = 2


When combining the operations (employee AND lineManager) you are actually just performing the above operations in sequence ending up with the value 3.

Easy to understand? Not so much ;-)

23 August, 2016

Essential (developer) tools: A biased list – 2016 Mac version

I have been doing a collection of tools relevant to a life as a developer on .NET, but having recently swiched to Mac - here is the same (current) list as an XCode developer.
Development tools:

Quite a short list, but life in Mac world is simple (remember: simple != easy)

Publishing from Mac Sierra to TestFlight: problems

If you have jumped onto the band wagon that says beta on the side; you have also signed the certificate with a title that says “problems ahead”! I have indeed been on that wagon for some time as I’m currently running XCode 7.3.1 + XCode 8.0 at the same time on a Mac Sierrra OS (which is in beta for the time being).

Apple appearently only accept software that is built on a release version of their OS (El Capitan for now). This means, that you cannot build apps using (XCode 8.x or Mac Sierra) and expect the publishing process to go smoothly. You need to fiddle with stuff to make Apple believe you are indeed using a released OS (i.e. El Capitan).

So to downgrade the OS without uninstalling it - you need to “change the OS" to something that resembles a released OS as this value is presented to Apples servers during the submission process. Where do you change this OS version to publishing can function without problems? And where do you find a valid value for this setting?

Here is how:
You change the value here: /system/library/……/coreservices/systemversion.plist


What value is accepted (at the time of writing)?
If you log in to the developer portal - you will find the build number of the latest released OS here (the value us: 15G31)

To sum up the process:

  • Change the system version in the systemversion.plist file to a valid value (15G31)
  • Build your app using a valid XCode version (i.e. 7.3.1)
  • Archive the app and export the .ipa to your local disk
  • Here is the fun thing: I could only make the publishing process work if I published the app using the Application Loader coming with XCode 8.0!

This is what it takes to be allowed to publish your app to TestFlight using a mix of beta and release software.

Update: It turns out that also every single xib file (which is .xml) carries this very number embedded. Man, they are really keeping track of everything!

10 April, 2016

Using VSTS from SourceTree on a Mac

Using Visual Studio Team Services is a great joy. It is a seamless experience when on Windows, but does require one extra step when using it from a Mac. As is the case when using VSTS from XCode (see http://blog.clauskonrad.net/2016/03/using-visual-studio-team-services-git.html) you also here need to establish an alternative representation of yourself that can work as authentication.

Here is how to use the SourceTree application on a Mac against VSTS:

  1. Log into VSTS (website)
  2. Select your name (top right)
  3. Select My Profile
  4. Select Security
  5. Select Add
    image
  6. Copy the generated Token (it will show only once) into a text file on disk
  7. Open SourceTree
  8. Press Repositories
  9. Select Clone from Url
  10. Enter the SourceControl Endpoint (https://<nameofcollection>.visualstudio.com)
  11. When prompted for Username/password – enter the Token instead of your username
  12. Enter your normal password
  13. You are in!
Screen Shot 2016-04-08 at 10.27.01


Screen Shot 2016-04-08 at 10.23.49