5 ms·

This article is comparing a complex SMS/MMS app with custom popup window functionality on Android to a relatively simple standalone IM client on iPhone (no popu

This article is comparing a complex SMS/MMS app with custom popup window functionality on Android to a relatively simple standalone IM client on iPhone (no popup windows nor SMS/MMS integration since neither are supported on iOS) and drawing conclusions from the experience. If they built the same standalone IM client with no popup windows on Android, I'd wager their experience would be quite different.

ericmsimons 13y ago
I share the same sentiment. I'm also pretty confused why he was surprised regarding the complexity of hijacking the phone's SMS/MMS messages. As a non-android dev, if I were told to do that, I would assume that it would be hell. It's just not a common use case for devs, so therefore Google probably has spent their time polishing up other APIs.
threeseed 13y ago
Custom popup windows are fine on iOS. Just need to display your own view. And generally the iOS APIs are an order of polish above what I've experienced developing for Android.
- mirsadm 13y ago
  iOS doesn't support custom pop up windows outside of your app. Which means for an IM app you need to be running it for a popup to appear (sort of making the whole popup window pretty useless IMO). On Android you can display a custom pop up window even if the user is not in your app.
gcb0 13y ago
well, it was from someone who designed the yahoo IM (the client so sucky that not even yahoo employees use) and redesign tech crunch... i dont know why those credentials give him any credibility as a developer. not being troll. really. just see how he had to limit to api 4.0 an app that is basically a list. ...unless it is still dealing with sms on android, which would be silly since now they have the IM backend for the IOS version...
mncolinlee 13y ago
I rarely ever see apples-to-apples comparisons in Android-iOS development discussions. It's tempting to say that his TechCrunch credentials bias him, but I actually chalk it up to his wanting to write a dev blog with a link-bait title. I don't think the lesson learned has anything to do with Android first at all.
- madeofpalk 13y ago
  If you read through the article and ignore all the 'We fucked up by using SMS/MMS' stuff, you'll find the crux of why Android didn't work for him: * APIs are not well-documented, and Google has changed them over time * Carriers modify the OS to support their particular [...] idiosyncrasies. * ...we need to ask the user to go into Settings and send us the details. Since manufacturers and carriers often modify Android’s Settings app, we can’t always tell the user where (or whether) she might find them. * On some Galaxy Nexus phones, when you’re listening to Pandora and get a notification sound from Emu, Pandora’s volume drops. This doesn’t happen with other apps’ notifications, nor does it happen with streaming apps other than Pandora, nor does it happen on any other device. * Several text-layout and view-layout bugs created situations where a seemingly harmless visual change would create significant UI bugs. * Poor, inconsistent and conflicting documentation
  - jobu 13y ago
    The market share bit seems pretty huge too: By building for two years’ worth of Android (as we did originally with 4.0+), you’ll support about 40 percent of the U.S. smartphone install base. Removing 4.0-4.1 support leaves you with one year’s worth of OS compatibility, and that number drops to 12.5 percent. By building for iOS 7 only, you’ll support 32 percent of the U.S. smartphone install base.
    - tonfa 13y ago
      That is if you only care about the us. Just including Europe will give you a different story.
schvenk 13y ago
(This is the author of the original post.) My comments about the relative difficulty of building on top of SMS/MMS were somewhat of an aside. That difficulty did take us by surprise, but as you say, wasn't reason enough to leave Android on its own. Once we'd decided to abandon the SMS/MMS approach, we were then building our functionality on top of a more straightforward messaging channel, and had to decide whether to proceed on Android or iOS. At that point we chose iOS for the reasons described.
- codeka 13y ago
  Apart from the SMS/MMS issue, the rest of the article is about how you shouldn't used inexperienced developers to draw conclusions about a platform. This quote is very telling: "We discarded the iPhone prototype we had been working on for a few weeks, polished our rusty Java skills and had an Android alpha out by February 2013." If you'd said "we abandoned out Android prototype, polished our rusty Objective C skills, and released an alpha on iPhone" I'm certain you'd be saying exactly the same things, just about iOS development instead of Android.
  - archagon 13y ago
    I don't know about that. 2 years ago, when I was first trying my hand at iOS development, I found it remarkably easy to get things working. The documentation, to my eyes, was simply excellent. I still find that to be the case.
    - WWLink 13y ago
      I'm not sure if they've changed this, but I had a hard time finding good documentation for using autolayout constraints in code for a layout that was mostly created in code due to it changing depending on what the situation demanded. But I will agree Google's documentation is usually pretty short sighted and made by people that don't like writing documentation.
      - sh1989 13y ago
        I struggled for a long time trying to understand how Relative Layouts work. It just didn't gel with me and I found the documentation lacking. One day it clicked, but I very nearly gave up on the whole platform. That said, the quality of the Android documentation has vastly improved since then. The training guides are excellent and the design section is good (although I much prefer the more practical Android Design in Action Youtube series).

ericmsimons 13y ago

I share the same sentiment. I'm also pretty confused why he was surprised regarding the complexity of hijacking the phone's SMS/MMS messages. As a non-android dev, if I were told to do that, I would assume that it would be hell. It's just not a common use case for devs, so therefore Google probably has spent their time polishing up other APIs.

threeseed 13y ago

Custom popup windows are fine on iOS. Just need to display your own view. And generally the iOS APIs are an order of polish above what I've experienced developing for Android.

mirsadm 13y ago
iOS doesn't support custom pop up windows outside of your app. Which means for an IM app you need to be running it for a popup to appear (sort of making the whole popup window pretty useless IMO). On Android you can display a custom pop up window even if the user is not in your app.

gcb0 13y ago

well, it was from someone who designed the yahoo IM (the client so sucky that not even yahoo employees use) and redesign tech crunch... i dont know why those credentials give him any credibility as a developer. not being troll. really. just see how he had to limit to api 4.0 an app that is basically a list. ...unless it is still dealing with sms on android, which would be silly since now they have the IM backend for the IOS version...

mncolinlee 13y ago

I rarely ever see apples-to-apples comparisons in Android-iOS development discussions. It's tempting to say that his TechCrunch credentials bias him, but I actually chalk it up to his wanting to write a dev blog with a link-bait title. I don't think the lesson learned has anything to do with Android first at all.

madeofpalk 13y ago
If you read through the article and ignore all the 'We fucked up by using SMS/MMS' stuff, you'll find the crux of why Android didn't work for him: * APIs are not well-documented, and Google has changed them over time * Carriers modify the OS to support their particular [...] idiosyncrasies. * ...we need to ask the user to go into Settings and send us the details. Since manufacturers and carriers often modify Android’s Settings app, we can’t always tell the user where (or whether) she might find them. * On some Galaxy Nexus phones, when you’re listening to Pandora and get a notification sound from Emu, Pandora’s volume drops. This doesn’t happen with other apps’ notifications, nor does it happen with streaming apps other than Pandora, nor does it happen on any other device. * Several text-layout and view-layout bugs created situations where a seemingly harmless visual change would create significant UI bugs. * Poor, inconsistent and conflicting documentation
- jobu 13y ago
  The market share bit seems pretty huge too: By building for two years’ worth of Android (as we did originally with 4.0+), you’ll support about 40 percent of the U.S. smartphone install base. Removing 4.0-4.1 support leaves you with one year’s worth of OS compatibility, and that number drops to 12.5 percent. By building for iOS 7 only, you’ll support 32 percent of the U.S. smartphone install base.
  - tonfa 13y ago
    That is if you only care about the us. Just including Europe will give you a different story.

schvenk 13y ago

(This is the author of the original post.) My comments about the relative difficulty of building on top of SMS/MMS were somewhat of an aside. That difficulty did take us by surprise, but as you say, wasn't reason enough to leave Android on its own. Once we'd decided to abandon the SMS/MMS approach, we were then building our functionality on top of a more straightforward messaging channel, and had to decide whether to proceed on Android or iOS. At that point we chose iOS for the reasons described.

codeka 13y ago
Apart from the SMS/MMS issue, the rest of the article is about how you shouldn't used inexperienced developers to draw conclusions about a platform. This quote is very telling: "We discarded the iPhone prototype we had been working on for a few weeks, polished our rusty Java skills and had an Android alpha out by February 2013." If you'd said "we abandoned out Android prototype, polished our rusty Objective C skills, and released an alpha on iPhone" I'm certain you'd be saying exactly the same things, just about iOS development instead of Android.
- archagon 13y ago
  I don't know about that. 2 years ago, when I was first trying my hand at iOS development, I found it remarkably easy to get things working. The documentation, to my eyes, was simply excellent. I still find that to be the case.
  - WWLink 13y ago
    I'm not sure if they've changed this, but I had a hard time finding good documentation for using autolayout constraints in code for a layout that was mostly created in code due to it changing depending on what the situation demanded. But I will agree Google's documentation is usually pretty short sighted and made by people that don't like writing documentation.
    - sh1989 13y ago
      I struggled for a long time trying to understand how Relative Layouts work. It just didn't gel with me and I found the documentation lacking. One day it clicked, but I very nearly gave up on the whole platform. That said, the quality of the Android documentation has vastly improved since then. The training guides are excellent and the design section is good (although I much prefer the more practical Android Design in Action Youtube series).