Showing posts with label Mobile. Show all posts
Showing posts with label Mobile. Show all posts

Wednesday, 22 October 2014

iOS and Xamarin

Deciding between native iOS and Xamarin (MonoTouch)

An old friend of mine, who I worked with back when I was a .NET developer, emailed me recently. He was looking for some advice on which platform to use for creating iOS software, mostly focusing on native versus Xamarin (MonoTouch). My answer does not delve into specifics about Xamarin, because it’s been years since I used their platform in earnest. It does, however, express my opinion on native vs. non-native. He left out other options, such as PhoneGap, perhaps because he simply was not yet aware that they exist.
Below is his email, followed by my reply. I don’t expect this to settle the matter once and for all (where’s the fun in that?!) but perhaps it will give others a new perspective on the topic.
His Question
Since I have started playing around with iOS, two questions that came to my mind and I thought I should ask you.
To be or not to be native iOS?
Xamarin or not to Xamarin?
My real purpose is
  • to create some productivity apps for handheld devices and
  • to create some re-usable control libraries.
It will be great if you can share your expertise on this :-)
My Reply
Your question is a good one, which I’ve discussed with many people. So far my answer is broken down into three considerations:
  1. Reach – Is getting the same codebase onto as many devices as possible a high priority, or are you more interested in keeping the app on one operating system for the first launch (in order to create the best app possible – no compromises)?
  2. User Experience – Are you willing to make sacrifices in the user experience to use a non-native layer (ex. building HTML-based UI via PhoneGap)?
  3. Budget – Can you afford to build a separate app for each platform? If so, that’s probably the best route since you won’t need to rely on lowest common denominator solutions that bring their own bugs and limitations to the table.
In your particular case, the re-usable control libraries should be native because I doubt that such performance-sensitive, low-level rendering code would be reusable via Xamarin’s platform across different OS’s. You can always wrap your native libs with their runtime wrapping API, which I read about a while back, and use them from Xamarin apps if necessary.
Regarding the productivity apps, I don’t know enough details about your situation to say anything definite. Using Xamarin for those apps might make sense, and you will probably have a temporary advantage of avoiding the learning curve associated with native iOS programming (note: I wrote temporary). Truth be told, learning native iOS programming isn’t all that difficult, it just takes time and a little brain rewiring. Also, when working with Xamarin, or PhoneGap, you often end up dealing with Objective-C code anyways (plug-ins, StackOverflow examples, etc).
I have a bias toward native since it is inherently better than any 3rd party layer, and I’m not interested in dealing with the bugs of Apple and another company as well. Unfortunately, technical preferences don’t usually drive business decisions!

Tuesday, 30 September 2014

Secure Mobile Banking App with Windows Azure



One of my clients is based in Indonesia. The company had achieved dramatic success in the mobile field
Having built IT integration products for the business-to-business sector since 2006, a 70-strong developer team recently turned their attention to mobile apps developing a secure instant messaging service called EMASS (Encrypted Messaging and Secured Services). 
Their objective was to create a platform that enables customers or employees to use messaging for secure transactions. They planned to market EMASS to banks and phone companies, so their customers could make payments and buy top-ups using a single log-on from their cell phones.
To launch EMASS as a service, my client needed a cost-effective way to host the EMASS backend systems for each mobile app. They also expected that customers would want to use EMASS from overseas, but this presented a dilemma.

“Deploying EMASS on overseas servers would have been prohibitively expensive...” 
Hosted EMASS servers in Indonesia, the client would also  face speed and bandwidth issues.
They are after all a software-development company, not a service provider. They needed a partner (hence my role) to host EMASS for them, but their service had to be reliable, easy to work with and affordable. For financial institutions to trust them, it also had to be 100 percent secure.

The cloud solution

A cloud service that worked with EMASS was my brief and I was able to use a wide mix of technologies. These included Java and Linux for core server messaging, and C# for satellite modules attached to the core servers. On the client side, we used C#/XAML for the Windows Phone app, and C# for the iOS and Android apps, with the latest version of Xamarin on Visual Studio.
I evaluated several options, including a managed, on-premise deployment with data network firm, an infrastructure as a service (IaaS) solution from local cloud provider, Biznet Network; and two cloud platform services on Windows Azure.
The on-premise solution required a large capital investment, because the client would have to purchase and install servers. The IaaS option would also be costly, because staff would have to manage the operating system and scale the apps.

The solution

We had to deliver the easiest cloud platform to work with, Security and patching be already taken care of, so it is less labour-intensive. Although we used Linux and Java to create our payments messaging system, Azure can easily handle them because of its open architecture.
I also advised about deploying EMASS, which included migrating the backend database to MSSQL. With over 15 cloud apps running on 30 virtual machines on Windows Azure, the client began offering EMASS to banks. The service became an instant success after it was published to the cloud and tested.
With Windows Azure, I was able to provide the client with support of all open source technologies used in EMASS. Azure has proved secure and reliable, so financial institutions trust my client to create new services for their own customers.

The bottom line

Azure saved the client these capital and operational expenses, in return for a predictable and transparent monthly charge.
Minimal IT support required
The Windows Azure service also reduces costs, because it needs minimal IT support. With Azure, you can forget about managing a rack of servers, the network, security and patching.
Moreover, we can empower clients to easily manage scalability from their own PC. If they had hosted it themselves it would need at least five system administrators; with Windows Azure they only needed one.
Fast deployment times for mobile appsMy solution used the Mobile Push Service feature within Windows Azure Mobile Services to build the backend services for each app. 
With Azure Mobile Services, we can develop our mobile apps very fast. And it’s very easy to deploy on Windows Azure: the interface is very good, and the result is perfect. 

Last thoughts...

With Windows Azure, companies can turn its technology into a commercial service, while still focusing on software development. By using Azure, save on the infrastructure and management costs of deploying the software ourselves—that’s a huge strategic win.