4 ms·

Going back and forth between Android's SDK and docs and Apple's for iOS is like alternating between navigating a labyrinth with a floor of hot coals and, somewh

by ashark 9y ago

Going back and forth between Android's SDK and docs and Apple's for iOS is like alternating between navigating a labyrinth with a floor of hot coals and, somewhere, the howls of wolves, and relaxing in a nice warm bath with a glass of wine and a good book.

mercer 9y ago
As someone about to take the plunge into mobile development (and slightly leaning towards iOS over Android), I'd love to hear some elaboration on your experiences.
- ashark 9y ago
  iOS: docs are so good you'll find yourself reading way past what you actually need, just for fun. They're great. APIs generally well thought out. Examples current. Xcode's sometimes frustrating, but not that bad. Worst part's the signing process which remains prone to breaking for mysterious reasons (this is probably less true if you have just one project that's always current, but if you have historical projects that need upkeep and you bounce between different apps it's bad) and I still have to look up again how to get all the parts working if I go more than a few months without messing with it, because I can't seem to keep it in my head. Android: most docs amount to half-assed Javadoc output. Longer-form sections frequently contain bad advice and outdated examples. When the examples aren't outdated they always seem to avoid demonstrating the particular use you need them to, as if by magic. APIs themselves sometimes weirdly bad (see, at least as of ~6 months ago, the Android google maps address search API being significantly worse than the Javascript one). New UI elements are frequently a duct-tape-heavy veneer over existing UI elements that lacks customization you'd expect to exist, unless you resort to reflection, and generally feel like something the summer interns threw together. Support for all that pretty Material UI stuff is laughable. And while I know there isn't an iOS public bugtracker to compare it to and that that's also kind of a bad situation, the Android bugtracker is mostly useful as a source of either comedy or suicidal ideation, depending on your demeanor. You'll learn what I mean if you spend much time with Android. For Android your best bet is to read everything Square (yes, that Square) has written about it, and follow their patterns and use their libraries wherever possible. See: https://github.com/square/flow https://github.com/square/flow https://github.com/square/retrofit https://github.com/square/retrofit https://medium.com/square-corner-blog/simpler-android-apps-with-flow-and-mortar-5beafcd83761 https://medium.com/square-corner-blog/simpler-android-apps-w... and so on.
esrauch 9y ago
The converse side of this is when you do hit something that isn't covered by the iOS documentation (and also can't find some random WWDC talk) you are completely stuck with no avenue to find out the answer, whereas with Android you can pull up the AOSP source and often find the answer to the question yourself.
izacus 9y ago
Really? Because as an Android developer I have the exact opposite experience - navigating around Apple's iOS documentation feels like digging through obsolete webpages where bunch of parameters and methods aren't documented at all (especially around bitmap processing and some other older APIs).

by ashark 9y ago

mercer 9y ago

As someone about to take the plunge into mobile development (and slightly leaning towards iOS over Android), I'd love to hear some elaboration on your experiences.

ashark 9y ago
iOS: docs are so good you'll find yourself reading way past what you actually need, just for fun. They're great. APIs generally well thought out. Examples current. Xcode's sometimes frustrating, but not that bad. Worst part's the signing process which remains prone to breaking for mysterious reasons (this is probably less true if you have just one project that's always current, but if you have historical projects that need upkeep and you bounce between different apps it's bad) and I still have to look up again how to get all the parts working if I go more than a few months without messing with it, because I can't seem to keep it in my head. Android: most docs amount to half-assed Javadoc output. Longer-form sections frequently contain bad advice and outdated examples. When the examples aren't outdated they always seem to avoid demonstrating the particular use you need them to, as if by magic. APIs themselves sometimes weirdly bad (see, at least as of ~6 months ago, the Android google maps address search API being significantly worse than the Javascript one). New UI elements are frequently a duct-tape-heavy veneer over existing UI elements that lacks customization you'd expect to exist, unless you resort to reflection, and generally feel like something the summer interns threw together. Support for all that pretty Material UI stuff is laughable. And while I know there isn't an iOS public bugtracker to compare it to and that that's also kind of a bad situation, the Android bugtracker is mostly useful as a source of either comedy or suicidal ideation, depending on your demeanor. You'll learn what I mean if you spend much time with Android. For Android your best bet is to read everything Square (yes, that Square) has written about it, and follow their patterns and use their libraries wherever possible. See: https://github.com/square/flow https://github.com/square/flow https://github.com/square/retrofit https://github.com/square/retrofit https://medium.com/square-corner-blog/simpler-android-apps-with-flow-and-mortar-5beafcd83761 https://medium.com/square-corner-blog/simpler-android-apps-w... and so on.

esrauch 9y ago

The converse side of this is when you do hit something that isn't covered by the iOS documentation (and also can't find some random WWDC talk) you are completely stuck with no avenue to find out the answer, whereas with Android you can pull up the AOSP source and often find the answer to the question yourself.

izacus 9y ago

Really? Because as an Android developer I have the exact opposite experience - navigating around Apple's iOS documentation feels like digging through obsolete webpages where bunch of parameters and methods aren't documented at all (especially around bitmap processing and some other older APIs).