For many app developers android fragmentation could be a real pain. Theoretically app written on one version of android should run on same version and forward. And, that include all different brand and model. But for many cases this is not right. There are so many situations where app written on one version crashes on another. This thing gets critical when app crashes on same Android version but on different brands and some time on same brands but on different models. Yep! This can happen, on same Android build/version/SDK.
I spent quite some time in mobile start-up at Midtown Manhattan. Work in start-up is challenging interesting and fun. At the end of the day we used go for after work drink. It was really fun and very warm work environment. But there is one big catch of working in start-up. And that is, you always out of money and right people. At work, we used to sit together come up with cool ideas and developed new apps based on that on almost every other day. When we published all these apps on market, people start giving us review. Some were good some were bad. Oh! god I hated those bad reviews. Anyways, we were always getting reviews like that, I bought this app, spent money and now it is crashing on my blah blah device. So whenever we got this type of comments we try to recreate the scenario and most of the cases we couldn’t able to generate the error coz we do not have that device and we do not have enough money to get that device. So owner of the startup did like many other people he purchased a new device from the market hoping to return when we done with the testing. But deices were to many. So after doing this couple of times he got upset and told me minhaz leave those comments focus on new apps. All of our cool cool apps end up with bad reviews and eventually making poor revenue. Android phones are so many and it is hard for a start-up to purchase all the devices and test on them. On the other side owner was quite happy with iPhone apps coz it has less variation of devices and OS versions and for that it was always returning good revenue.
Theoretically fragmentation affects “write once run anywhere” functionality. Fragmentation can cause from many different reason such as:
Hardware: variation in the processor or hardware’s like camera, memory etc. Consider the scenario if you develop an apps which is depend on a particular sensor to work. Like, Motorola XOOM which come with a barometer. So a barometer app developed and tested on XOOM will not work on Samsung Galaxy tab 10.1.
During my day with start-up I remember one particular issue HTC my touch and HTC G2. What happened that our app was depended on Android TTS api. On my touch app able to get speech correctly I will say 97% time where as on G2 percentage was around 50 percent. I spent some time investigate the whole issue and at the end give up blaming MIC. My touch was kind of bulky and so I assumed that it has better MIC then G2. But anyway, when we put that app on the market, it’s ended up with bad reviews and making poor revenues from market.
Changes on Software/Operating System is one good reason for fragmentation. Different manufacture changes OS code base in order to suit their need. Some time android device manufacturers customize android code-base to fit their need. And, also some time developers of this device manufactures believe they do not need some modules and changes some OS features. For example on Motorola XOOM action bar is fixed and you cannot move it. So if any of your app strictly design for full screen tablet mode and tested on different device probably you will be very disappointed to see the output on XOOM. This type of things could get worse when customization has done on core level or some changes have been done without a complete dependency analysis.
Localization is one big reason for fragmentation. There are cases when app crashes on different mobile operators. And, probably we all aware of issues with languages especially on Asian, and indic languages. Once I was working with Samsung Galaxy S and I tested my apps of course on its US version. But after first release, I got complain from our South Korean office that app is crashing on their phones. So after hearing about it, like many other developer I tried to reproduce the bug just sitting my on my ass in Mountain View. Unfortunately I wasn’t that lucky and after spending couple of hours when I couldn’t able to recreate the issue on my side I asked for the device. After couple of days a galaxy S devices shipped to me from Korea. I was so excited and thought that today I will be able to fix this strange bug. Unfortunately after spending couple of hours I couldn’t able to reproduce the error. I followed all the reproducing steps but couldn’t able to figure out what really happen. On my end app passes with flying color. So I mail back and asked our Korean engineer to test the app on another device. This time they purchased a new device from fine Korean market and guess what bug still exist in Korea. After that I close the bug commenting that this is happening due to network operator and we cannot do anything. Really!!!!!!? So whatever the error reason was we couldn’t ship our apps to hundred thousand Koreans who ware subscribed to that particular mobile network.
Writing defensive coding is a very good way to deal with fragmentation. Your program should die gracefully instead of throwing null pointer exception. cautious, be over cautious few extra line of checking on your code probably will take some few extra time but, at the end it will help you make stable apps and to get some extra revenue from the android market. Always think that something not going to work. Someone will screw up. For example a “new” will not return object instance. if possible use some extra check.
On Android manifest file you can provide hardware configuration to limit the user viewing capabilities. For example I can say user with this following hardware configuration will be able to see my app. Also limit the SDK version if you can. Right now, I am having strange problem with one my current app. this app run perfectly fine on Android 2.1 update 1 but throws null pointer exception on Android 2.3.X series. With SDK version 3.x series my code base even do not compile. What I am doing that not very important but i tried to work around like any other lazy programmer suppose to do, without investigating whole issue and spend to much time on this I just create three separate code base for three different Android series. Not so smart right?
Try to stick with standard SDK. I saw lot of people try to use internal or unpublished API's and later act genius because he just hacked Google code but it is basically kind of stupid. those are unpublished for a reason. probably they are not stable. And, if device manufacturer want to customize SDK probably those code will be the first to go.
So I believe on Android world it is better to be little paranoid. It is always better to be extra cautious. Devices are too many, and variation on platforms are also too many. Every single build is different. From platform to platform, version to version, device to device, or model to model. And, it doesn’t matter if you see same information on phone about field.
I spent quite some time in mobile start-up at Midtown Manhattan. Work in start-up is challenging interesting and fun. At the end of the day we used go for after work drink. It was really fun and very warm work environment. But there is one big catch of working in start-up. And that is, you always out of money and right people. At work, we used to sit together come up with cool ideas and developed new apps based on that on almost every other day. When we published all these apps on market, people start giving us review. Some were good some were bad. Oh! god I hated those bad reviews. Anyways, we were always getting reviews like that, I bought this app, spent money and now it is crashing on my blah blah device. So whenever we got this type of comments we try to recreate the scenario and most of the cases we couldn’t able to generate the error coz we do not have that device and we do not have enough money to get that device. So owner of the startup did like many other people he purchased a new device from the market hoping to return when we done with the testing. But deices were to many. So after doing this couple of times he got upset and told me minhaz leave those comments focus on new apps. All of our cool cool apps end up with bad reviews and eventually making poor revenue. Android phones are so many and it is hard for a start-up to purchase all the devices and test on them. On the other side owner was quite happy with iPhone apps coz it has less variation of devices and OS versions and for that it was always returning good revenue.
Theoretically fragmentation affects “write once run anywhere” functionality. Fragmentation can cause from many different reason such as:
Hardware: variation in the processor or hardware’s like camera, memory etc. Consider the scenario if you develop an apps which is depend on a particular sensor to work. Like, Motorola XOOM which come with a barometer. So a barometer app developed and tested on XOOM will not work on Samsung Galaxy tab 10.1.
During my day with start-up I remember one particular issue HTC my touch and HTC G2. What happened that our app was depended on Android TTS api. On my touch app able to get speech correctly I will say 97% time where as on G2 percentage was around 50 percent. I spent some time investigate the whole issue and at the end give up blaming MIC. My touch was kind of bulky and so I assumed that it has better MIC then G2. But anyway, when we put that app on the market, it’s ended up with bad reviews and making poor revenues from market.
Changes on Software/Operating System is one good reason for fragmentation. Different manufacture changes OS code base in order to suit their need. Some time android device manufacturers customize android code-base to fit their need. And, also some time developers of this device manufactures believe they do not need some modules and changes some OS features. For example on Motorola XOOM action bar is fixed and you cannot move it. So if any of your app strictly design for full screen tablet mode and tested on different device probably you will be very disappointed to see the output on XOOM. This type of things could get worse when customization has done on core level or some changes have been done without a complete dependency analysis.
Localization is one big reason for fragmentation. There are cases when app crashes on different mobile operators. And, probably we all aware of issues with languages especially on Asian, and indic languages. Once I was working with Samsung Galaxy S and I tested my apps of course on its US version. But after first release, I got complain from our South Korean office that app is crashing on their phones. So after hearing about it, like many other developer I tried to reproduce the bug just sitting my on my ass in Mountain View. Unfortunately I wasn’t that lucky and after spending couple of hours when I couldn’t able to recreate the issue on my side I asked for the device. After couple of days a galaxy S devices shipped to me from Korea. I was so excited and thought that today I will be able to fix this strange bug. Unfortunately after spending couple of hours I couldn’t able to reproduce the error. I followed all the reproducing steps but couldn’t able to figure out what really happen. On my end app passes with flying color. So I mail back and asked our Korean engineer to test the app on another device. This time they purchased a new device from fine Korean market and guess what bug still exist in Korea. After that I close the bug commenting that this is happening due to network operator and we cannot do anything. Really!!!!!!? So whatever the error reason was we couldn’t ship our apps to hundred thousand Koreans who ware subscribed to that particular mobile network.
Writing defensive coding is a very good way to deal with fragmentation. Your program should die gracefully instead of throwing null pointer exception. cautious, be over cautious few extra line of checking on your code probably will take some few extra time but, at the end it will help you make stable apps and to get some extra revenue from the android market. Always think that something not going to work. Someone will screw up. For example a “new” will not return object instance. if possible use some extra check.
On Android manifest file you can provide hardware configuration to limit the user viewing capabilities. For example I can say user with this following hardware configuration will be able to see my app. Also limit the SDK version if you can. Right now, I am having strange problem with one my current app. this app run perfectly fine on Android 2.1 update 1 but throws null pointer exception on Android 2.3.X series. With SDK version 3.x series my code base even do not compile. What I am doing that not very important but i tried to work around like any other lazy programmer suppose to do, without investigating whole issue and spend to much time on this I just create three separate code base for three different Android series. Not so smart right?
Try to stick with standard SDK. I saw lot of people try to use internal or unpublished API's and later act genius because he just hacked Google code but it is basically kind of stupid. those are unpublished for a reason. probably they are not stable. And, if device manufacturer want to customize SDK probably those code will be the first to go.
So I believe on Android world it is better to be little paranoid. It is always better to be extra cautious. Devices are too many, and variation on platforms are also too many. Every single build is different. From platform to platform, version to version, device to device, or model to model. And, it doesn’t matter if you see same information on phone about field.
1 comment:
Really nice article !!! Hope to see some of your experience with Localization. Specially indic languages. In my opinion, it's hard get them working without rooting a phone. May be you can describe some of your experience.
Post a Comment