Tag Archives: android

Xamarin – Migration Journey (Part 3 – Legacy code integration)

This is actually the hard part, and the failure at this point actually prevents us from moving towards with Xamarin.

We have been developing with native iOS and Android for 6 years, with lots of legacy code and libraries. Our libraries in both iOS and Android can have up to 20-30,000 lines of code. To migrate all of them to Xamarin would be a huge deal. The only solution is to connect Xamarin with those libraries.

We have libraries in 3 languages: Objective-C, Swift and Java. The first trouble came up when Xamarin could not connect with Swift framework. In our experiment, we took the risk and port 1 of our library into Objective-C. The Swift framework issue should have signaled us that something was not going right.

Anyways, we move forward with our intention to write a real project, working on both iOS and Android, and connect with 5 of our libraries and use 3 cocoapods frameworks/libraries.

For the libraries we wrote, there was not much problem, except the Swift issue mentioned above. However, with cocoapods, when people write code in all shapes and forms, the API definition kept having weird issues that we could not comprehend. We spent 3-4 man days on this, and still wasn’t sure that if the code would work or not.

We will discuss more about what binding issues we have with Xamarin that forced us to change the direction: to try to at least make a workable app with missing elements and libraries working in Xamarin


Xamarin Migration Journey (Part 1 – Introduction)

We are trying Xamarin as our cross platform approach. And we have learnt many things along the way, some of them were the old approach of Static Library, the API definition and how the code structure and the API design of Xamarin and iOS are somehow different.

We have quite a big codebase (more than 100 thousand lines of code) in iOS and Android in native, mainly because we deal mostly with Video Processing and some native features. We use frameworks a lot to share code between different apps. I have been looking for ways to port the code from iOS to Android in a smooth and cost saving way.

There are multiple steps that I plan to go through when adapting Cross Platform:

- Same or similar architecture between iOS and Android codebase

- Prepare the library in correct format to be reused in the Cross Platform

- Prepare the Binding

- Prepare the team with C# knowledge to migrate the codebase

- Design the module and how best the app will be separated between Shared Module and iOS Module

Controls Android New Site



I am so excited to announce my new site: ControlsAndroid.com where I show my collection of all android controls that I find on the internet. We are still updating it everyday, so please spend time visiting the website, download and use the controls for your cool app. Leave my any comments or suggestions on how to improve the site much better for the community.

For a better Android Interface

Improve your Android emulator performance

Want to supercharge your Android emulator in Eclipse/IntelliJ, use the following, excellent tip from Stackoverflow

IMPORTANT NOTE : Please first refer to Intel list about VT to make sure your CPU support Intel VT.

HAXM Speeds Up the Slow Android Emulator

HAXM stands for - “Intel Hardware Accelerated Execution Manager”

Currently it supports only Intel® VT [Intel Virtualization Technology]

The Android emulator is based on QEMU; The interface between QEMU and the HAXM driver on the host system is designed to be vendor-agnostic.


Steps for Configuring Your Android Development Environment for HAXM

  1. Update Eclipse: Make sure your Eclipse installation and the ADT plug-in are fully up to date.
  2. Update your Android Tools: After each Eclipse plug-in update, it is important to update your Android SDK Tools. To do this, launch the Android SDK Manager and update all the Android SDK components. To take advantage of HAXM, you must be on at least release version 17.

enter image description here

  • Download the x86 Atom System Images and the Intel Hardware Accelerated Execution Manager Driver: Follow the image below:

enter image description here

  • Install the HAXM Driver by running “IntelHaxm.exe”.
    It will be located in one of following locations:

    • C:\Program Files\Android\android-sdk\extras\intel\Hardware_Accelerated_Execution_Manager
    • C:\Users\<user>\adt-bundle-windows-x86_64\sdk\extras\intel\Hardware_Accelerated_Execution_Manager

    If the installer fails with message that Intel VT must be turned on, you need to enable this in BIOS. See description for how to do this here.

Install .exe or .dmg

  • Create a New x86 AVD: Follow the image below:

Create AVD

  • Or as for new SDK, enter image description here

Windows Phone Potential?

I normally hear from Windows developer to say that their Windows market share is much bigger than the total of iOS and Android together. And the sales of Windows 8 has bypassed all the sales of iOS and Android from the beginning to now.

Windows Phone 8

Windows Phone 8

It is quite unfair to compare the whole Windows 8 with iOS or Android. And if we do take that demand into PCs and laptops, then why the hell we do not compare the supply side? It is very clear that if Windows 8 could be a shared platform between PCs, tablets and phones, then all the old software, all the old games would have beome compatible to the Windows 8 system in the short amount of time. And many apps for tablets and phones would be quite different than the ones in PC. No, I don’t mean technology, I am talking about the business model, the purpose of the software.

I don’t mean that iOS and Android is a better market than Windows Phone for indie business. These markets have become very competitive and continue being so. You either have to figure out a market niche or be very lucky.

Openess v.s closeness

Open v.s close

Open v.s close

I have a long support for open source system, the open standard, a more open and shared data in the web. 3 years ago, I thought that the win of Android is obvious and the reality has proven me right. I was confident with my knowledge and guessing until I read a long fan boy of Apple. Yes, he is a fan boy of Apple, and the article has really favoured Apple. But he made an important point great product wins. Not the great product in terms of technology, nor in terms of openess. It is a great product in users’ minds, either by its value provision or by good marketing.

By opening the platform, Android opens the door for more hardware suppliers. But that openess means nothing if the operating system sucks, it means nothing if the compatibility and the user interface are not good. Looking at Linux and all the free open source operating system. They are more opened, easier to adopt into the hardware by the suppliers, but they suck. Either the UI, the lack of applications and features, but they suck.

I think this article gives a very good point of view as well.

5 things to know about cross-platform development for iOS/Android

Cross Platform App

Cross Platform App

People love the idea of cross-platform development for iOS/Android or try to use a familiar language to develop apps for either or both platforms. There are many solutions and platforms out there and each of them has pros and cons, here we will try to name a few and analyse them: MonoTouch, Appcelerator, RubyMotion, PhoneGap, HTML5, Java2ObjC…

The pro is quite clear, it supports both platforms at the same time, you only need 1 guy with 1 skill (either it is C#/Javascript/HTML5 or Ruby) to learn and quickly produce apps for both platforms at the same time.

The cons are quite depending on which you choose to go with, but we will analyse them in some aspects: easy for maintenance, native performance, delay for update, community support, pricing/bankrupt, talent hiring

1. Easy for Maintenance

I found some of the platforms are challenging to maintain, just to name a few: appcelerator and phone gap… With javascript and not available debugger, when it comes to debugging, you will spend as twice/three times as much to debug. Other platforms do support debugging well like MonoTouch or RubyMotion…

One thing that most cross-platform framework has problem is that it adds another layer of complexity into your system. If some bug happens or something does not run as intended, you have three times of works. You have to check if the bug is your bug, is your framework’s bug, the interaction between the framework and the iOS/Android platform, and finally, if that is a bug of iOS/Android. Let’s take a simple example:
iOS had an old bug with rotation and I encountered that bug when I tried to use Appcelerator to build my simple project. It took me the whole day to find that bug was an Apple bug, there is a work around in Apple way but that is not well supported by Appcelerator….

2. Native Performance
When it comes to native performance, I can say that most of the third-party frameworks do well in this area. However, HTML5 is not an excel when it comes to this, or at least, not yet. Facebook has shown us an important lesson with its decision to be back to native to improve its performance. I think that in the future, when the WebKit, the hardware and the requirement for a good app has matched each other, more and more apps will be developed using HTML5 and other open web technologies. Simply, because it is open.

So, if you are building something simple and may grow well over a long time, you may consider the hybrid approach to combine HTML5 and native code. This could work well with if you can integrate it with the web service at your backend.

3. Delay for update/community support/pricing
All of them come to the same problem of third-party frameworks, that middle complexity layer that you add into your project. Most of the frameworks will update quite fast when Apple release a new version, except many minor bugs. I used to have code that is working well with Apple in the iOS4 release and stop working when iOS5 is released. The problem gets worse when most iOS5 beta still works well with my apps. So, when I try to run our app on iOS5 final release, I get panic. I don’t know what is wrong with my code, is it the middle framework, is it just Apple’s release has changed something. I finally figure out that Apple has changed some rules in their API and that affects the old way the middle framework is working. I need to wait for their update to get it work.

Most of the middle framework has their premium supports but you either have to pay more or you have to wait a hell long of time. And most of the communities are a fraction of either the iOS/Objc communities or Android communities. At there, at least somebody has worked with your problem, somebody tested and figured a work around.

4. Bankrupt?
There are quite a lot of third-party frameworks around, and I am quite sure many of them will go bankrupt or stop working after a while. Or the price can go up, or the support rate gets slow down. You don’t know what the hell is waiting for you there. If your product is very important, be careful, you don’t want to throw tens of thousands of lines of code away and start all over again. These middle frameworks code, unfortunately, are not much reusable. You can generate Objective-C/Java code from them and then continue working from that. But, believe me, reading, understanding and maintaining those generated code are as twice as hard as you write it from the beginning. I don’t say all of them may have problems, but be careful which framework you pick, how long your project will last, and make sure there is a good match. If your project is pretty longer than 3-5 years, maybe thinking deep about it…

5. Talent Hiring
This is a people management, a project management issue. I remember 3 years ago, finding a good iOS developer is as hard as hell. Although it is easier now, it may not make sense to have a whole team of engineers in Ruby/C# and 1 guy in iOS and 1 guy in Android (or 1 guy for both iOS/Android). That means you have to feed 2 more guys, training them with company’s culture, to understand the domain knowledge that you have. And when things grow, each of these 3 teams grows. Another solution is that 1 of the web guy need to learn both iOS and Android development. That’s why it may make sense for you to reuse your team’s talent. It is also a good thing to consider to have a guy with HTML5 to approach the app in hybrid (HTML5+native code) model.

iPhone v.s Android

The smartphone game is over. The tablet game will be finished soon, within 2 years.

iPhone versus Android

iPhone versus Android



Android wins, iPhone loses. 75% v.s 15%, soon will become 85% v.s 5%. But that doesn’t matter much for Apple. Apple is a brand for high-end products. They don’t aim to gain all market share. To gain market share, Apple has to attack more of the low-end market, which means they have to lower their price. However, matching other supplier’s price may be harmful for Apple’s brand, although they may achieve it by more efficient supply chain and factories.  To become a high-end brand, Apple spends a significant amount of money on their brand and will not scarify it for the market share.

But in this ecosystem war, the bigger ecosystem leads to a win by monopoly. When 75, 80 or 85% of the market is using Android, app developers will flock to there, and make the ecosystem become much more valuable for customer. To continue earning a lot of money, Apple has to continue what it has done best under Steve Jobs’s empire. New product, new market, new value, or new software that people are willing to purchase with high-price.

What will be the next Apple’s product? Probably Apple TV, I am not even sure about that.

And the important questions for most of us, as app developers, what should we do? Should we all move to Android yet, should we change our strategy of iOS first, Android second? Or should we start discussing about Mobile Web App?

I am writing more on the Mobile Web App v.s Mobile Native App in the next post, catch it soon.