Cross-platform mobile development

This post is about my thoughts on C#, Xamarin and cross-platform mobile programming in general. Originally, I wanted to talk exclusively about C# and it’s significance in modern mobile programming however I couldn’t resist covering the topic from the beginning. If you are only interested in C# and Xamarin , click here.

Cross-platform mobile development

So you love technology, you enjoy your iPhone/Android/Windows device, you know how to program and you have a ground-breaking-kick-ass-never-seen-before-will-turn-the-world-upside-down idea for a mobile app, what next? Answer is simple: go make it!! But make it how? Isn’t your idea worth sharing with the whole world? or is it worth only sharing with someone who owns an iPhone (assuming you do swift/objective-c) or an Android phone (Assuming the you breath Java like most of the world) ? Do you write it for one platform first then rinse and repeat every single ounce of effort for the next platform? IMO, once you start pondering these questions, you are getting really serious. And once you start getting really serious, you will either wish you have an endless supply of time and developer friends or you start researching cross-platform mobile development. For me, obviously the solution was to take a stab at cross-platform mobile development.

read more

A Class Factory in Golang (Google Go)

Do you know what a class factory is and why is it useful?  Ever considered implementing a class factory in Golang (Google Go) even though Go is not considered fully object oriented in nature? Are you curious about some awesome features in Go other than it’s impressive concurrency capabilities? If any of the these questions interests you, then reading on may be worth your while. This article covers implementing the factory design pattern in Go.

If that’s not your first time visiting my site, then you probably know by now that the Go programming language is a personal favorite of mine and here’s why. I love software design and I love Go. Because I love software design, I had to learn about design patterns. And one of the most popular design patterns is the concept of factory design patterns. In the OOP world, that translates to class factories. To make diving through the tutorial easier, here are the links to the main sections:

read more

A practical guide to protocol buffers (Protobuf) in Go (Golang)

The following article targets an audience with interest in software design, protocol buffers or computer programming in general, the article is fairly technical and assumes some knowledge in programming concepts.

Protocol buffers and Golang are two very recent fascinations of mine ever since I saw them in action. As an engineer, I can see a lot of power that can be harvested by leveraging either or both technologies which is probably why they are all over the place in Google’s infrastructure. This article serves as a practical tutorial into how to use protocol buffers in Go with some diving into the language features. Because this article is rather long, I decided to divide it into different sections:

Why Protocol Buffers?

Put very simply, a protocol buffer or protobuf encodes and decodes data so that multiple applications written in different programming languages can exchange a large number of messages quickly and reliably without overloading the network. From my experience, the beautiful thing about Protocol buffers is that the more data you tend to send, the more performance you’d get if you compare with other methods of sending the same data load, which can be really helpful if you have a lot of data that you need to send across the network between two nodes. In practice what protocol buffer libraries do is that they compress the messages to send in a serialized binary format by providing you the tools to encode the messages at the source and decode the messages at the destination. Protocol buffers currently are supported in multiple programming languages as outlined in however the level of support varies.

Since protobuf is only concerned with the encoding, compression, decompression and decoding of a data, you need to take care of how to send it. Of course, The most obvious choice is using sockets which I will cover here, however you can get more creative and try a more fancy transport method like zeromq for example.

Why Go?

Go (or Golang) is a relatively new programming language developed by Google to replace some complex C/C++ components utilized in Google’s application layer. What sets Go apart; is the fact that it was built from the grounds up to provide performance that is destined in the future to compete with very powerful languages like C/C++ while supporting a relatively simple syntax that resembles dynamic languages but at the same time not as confusing as languages like Haskell or Ocaml. Go is garbage collected, however it doesn’t rely on virtual machines to achieve that. It compiles everything down to the machine level, you simply choose the type of platform (Windows, Mac..etc) that you’d like the binary to run on when you build, and then the compiler will produce a single binary that works on that platform which makes it native and cross platform at the same time. The way Go approaches common topics like OOP and threading is different than its predecessors, which makes it a testimony on how the future programing language should be like. Personally, I like to view Go as a magic tool to obtain super powers, and I am sure we all love super powers. The fact that I can write a piece of code that is simple in syntax, and deploy it anywhere without having to install any libraries, virtual machines or frameworks on the target machine is like how the green lantern has the ability to do anything anywhere whenever he feels like it using a mere green ring.

Go , in my opinion, is perfect for microservice architectures which we will be seeing a lot of in the future. A microservice architecture is an architecture at which you divide the responsibilities of your application to smaller services that only focus on specific tasks. These services can then communicate between themselves to obtain the information they need to produce results.

Source Code

Tutorial Overview

This tutorial is my effort to learn and share how to use protocol buffers in Go. I will try to cover some of the Go language interesting features in the process, however an awesome place to start learning Go is here . We’ll do that by building the following pieces:

1- A Go TCP client that can read data from a csv file then sends it to a TCP server using protocol buffers

2- A Go TCP server that can accept messages from multiple clients and then utilizes Protobuf libraries to decipher the messages before writing them to a CSV file

In order to demo protocol buffer support for another programming language, I included a Python client that uses protocol buffers which can also send data to the Go server.

Let’s start.

Preparing your development environment

First step is to setup your development environment. In order to do that, we need to:

1- Install Go =>

a. Go to

b. Pick the file that corresponds to your development environment operating system

c. Ensure that a GOPATH environmental variable is defined to point to your Go workspace ( the folder at which you will save your Go code)

d. Ensure that your GOPATH root has three main folders: bin, pkg and src.

e. If you are confused about how to setup your Go environment, check the following article:

2- Install Python 2.7.6 (For Windows users only) =>

a. Go to

b. Pick the file that corresponds to your operating system

c. Ensure that your PATH environmental variable points to the Python.exe file.

3- Get Protobuf =>

a. Install both protobuf compiler and source files from

b. Install hg Mercurial at

c. To get the Go protocol buffer libraries, type go get -u… from your command console.

d. To get  and build the Python Protobuf libraries, check the README.txt file in the Python folder included in the Protobuf for build and install instructions. Typically it involves typing Python install

Preparing your Protobuf message

Before you write any code, you need to first define the Protobuf message that will include the data you need to be serialized and sent. Here is what you need to do:

1- Design the shape and structure of the message based on the data that you need serialized

2- Write a proto file that describes your message

3- Use the Protocol Buffer compiler file (Protoc) to convert the Proto file to a library specific to your programming language of choice so that you can include it in your code

4- For a practical example about how to go about Preparing your Protobuf message, check the section below. Otherwise for detailed information about how to write the Proto file, check

Creating and using the Proto file for our project

Let’s illustrate preparing a Protobuf message by preparing a message for our project:

Imagine that I need to serialize and send a message called “TestMessage” ,which includes information identifying the client that sent it. The client information needed is the client name, the client ID and the client type. I also want my message to include a list of items, such that each item has an ID, a name, a value and a type. Now for the purpose of of this tutorial, I want the package or library name that includes all of this to be called “ProtobufTest”.

Here’s a sketch for how the TestMessage looked like inside my head, let’s assume 5 items are included in the message for now:


1- To define a message called “TestMessage” in a proto file, it’s as simple as typing

message TestMessage{
    //add your message body here

2- We agreed that the package or library name is to be called “ProtobufTest”, this can be defined by using the “package” keyword in the Proto file, and don’t forget the semicolon:

package ProtobufTest;

message TestMessage    {
   //add your message body here

3- Let’s say that the item type can only be one of three types: TypeX, TypeY or TypeZ. This can be achieved by using an enum type as follows:

enum ItemType {
  TypeX = 0;
  TypeY = 1;
  TypeZ = 2;

4- Now assuming that the only fields that must be filled in the message are the client ID, the client name , and each item ID. The Proto file will end up looking like this:

package ProtobufTest;

message TestMessage {
  required string clientName = 1;
  required int32 clientId = 2;
  optional string description = 3 [default = "NONE"];
  repeated MsgItem messageitems = 4;

  enum ItemType {
    TypeX = 0;
    TypeY = 1;
    TypeZ = 2;

   message MsgItem {
    required int32 id = 1;
    optional string itemName = 2;
    optional int32 itemValue = 3;
    optional ItemType itemType = 4;

read more