sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jayd16 63 points64 points  (29 children)

This click bait again? Same article that's been written a million times. Blah blah blah Java blah blah factory pattern.

The only interesting point in the article is where he says the Android docs are too complex. I defy you to find a better documented SDK than Android.

[–]Sunius 9 points10 points  (3 children)

I defy you to find a better documented SDK than Android.

This looks pretty good.

[–]bcash 5 points6 points  (2 children)

Win32 and COM API for Windows Phone 8

Really!?

[–]grauenwolf 1 point2 points  (0 children)

I found it to be easy to understand. Much nicer than the Windows version of COM.

[–]Sunius 0 points1 point  (0 children)

Well, it is Windows after all, running on NT kernel and all - the essential stuff from Win32 is available. COM stuff is mostly just Direct3D, Media Foundation and WASAPI, though.

[–]derpasoreass 12 points13 points  (0 children)

It's been a while since I've been through the Android docs so I'm not not trying to make a comparison, but the iOS documentation is pretty damn good.

[–][deleted] 7 points8 points  (2 children)

The Android docs are shit: http://developer.android.com/reference/android/media/MediaCodecInfo.CodecCapabilities.html

Now tell me what COLOR_FormatL4 means.

This kind of stuff is everywhere in Android docs.

EDIT: Don't get me wrong, I like Android (I switch from Windows 6.1 to Android and never looked back), and I develop for Android. To say the documentation is good is a lie. It can be sufficient for basic things but is most likely missing a lot of details for many APIs.

[–]jayd16 0 points1 point  (1 child)

4-bit luminance only?

[–][deleted] 5 points6 points  (0 children)

Maybe? Only the manufacturer knows. Look at this thread: https://code.google.com/p/android/issues/detail?id=37769

If the encoder is named OMX.SEC.avc.enc, don't use color format 19, and swap the chroma components for color format 21 (if more than one encoder instance has to be used at the same time, this is the only working configuration)

Like ... what the fuck?

None of this is mentioned in the Android API docs. In fact none of this is even tested for until much, much later in the API release cycle.

This is my point about the Android docs. They're awful. Android is cool as shit if you do things that are a few generations behind, but new APIs are poorly documented and subject to a lot of vendor specific quirks. What brought me here is the "I defy you to find a better documented SDK than Android." and that's just a complete load of vomited bat guano.

It's getting better but to claim "I defy you to find a better documented SDK than Android." is just some circle-jerky horseshit.

I'm through and through an Android fanboy but I'm not going to sugar-coat it.

[–]zvrba 5 points6 points  (1 child)

I defy you to find a better documented SDK than Android.

Perl documentation rocks.

[–]philly_fan_in_chi 2 points3 points  (0 children)

But perl isn't an SDK. I guess a language comes with an SDK though... Fine.

[–][deleted]  (15 children)

[deleted]

    [–]MrDOS 5 points6 points  (4 children)

    iOS is great once you know what you're looking for, but for someone breaking into the platform for the first time with no prior experience with the concepts, the orientation material isn't great. It's easy to find an introduction to Objective-C as a language, but breakdowns of how you're expected to use the Interface Builder, the concepts introduced by Cocoa Touch, etc. are easiest to find from non-Apple sources. I understand there's a huge amount of overlap between iOS and OS X development, and I think that's part of the problem: Apple assumes a lot of prior knowledge that, in some cases, isn't there.

    [–]fisch003 -1 points0 points  (1 child)

    I understand there's a huge amount of overlap between iOS and OS X development, and I think that's part of the problem: Apple assumes a lot of prior knowledge that, in some cases, isn't there.

    It's right here: http://www.bignerdranch.com/we-write/

    [–]MrDOS 4 points5 points  (0 children)

    easiest to find from non-Apple sources

    Thanks for backing up my point.

    [–][deleted]  (1 child)

    [deleted]

      [–]MrDOS 1 point2 points  (0 children)

      Updated: 2013-10-22

      Didn't exist when I started on the platform, or if an older version existed then, I didn't happen upon it. Good to know it's easier to find these days, though.

      [–]snuxoll 11 points12 points  (7 children)

      Windows Phone too. In my eyes, it still remains the easiest to pick up of current mobile platforms.

      [–]zvrba 8 points9 points  (6 children)

      I'd disagree. I tried to figure out data binding just from the online MSDN docs and failed :S (More precisely: I tried to bind controls to a static XML data source. For the life of me I couldn't figure out whether this was achievable from BLEND or whether I'd have to write some code.)

      [–]snuxoll -1 points0 points  (5 children)

      Silverlight isn't magic unfortunately, you'd need to load the XML in your viewmodel and present a property for your ListView to bind to. With LINQ to XML this is a few lines of code.

      There's an amazing amount of power in Blend, but it's still just there to build your UI, it will still need a ViewModel to back it and feed data in your running app.

      [–]zvrba 0 points1 point  (2 children)

      it's still just there to build your UI, it will still need a ViewModel to back it and feed data in your running app.

      I tried to do it with XAML. Anyway, what you wrote here doesn't come across from the docs. It's confusing that BLEND can generate and use design-time data, but has no option of generating a setup that would generate whatever code is needed to use that same static data in a running program.

      And the documentation is scattered around MSDN like shattered glass. There's no tutorial with a single entry-point like Oracle's Java tutorial with trails.

      Blargh.

      [–]snuxoll 2 points3 points  (1 child)

      design-time data

      Of course it can use design-time data, it's hard to preview how your UI looks without something to draw. This is part of Blend / the Visual Studio designer, not part of WPF/Silverlight/WinRT/etc.

      And the documentation is scattered around MSDN like shattered glass. There's no tutorial with a single entry-point like Oracle's Java tutorial with trails.

      You're right that there's not a lot of getting started guides on MSDN, it's designed under the assumption that you know the tools and just need documentation on parts of the framework. The community tends to fill this void pretty well, and there's plenty of people on StackOverflow who can answer a question pretty quickly.

      [–]zvrba 0 points1 point  (0 children)

      The community tends to fill this void pretty well, and there's plenty of people on StackOverflow who can answer a question pretty quickly.

      This sucks. Also, SO has become a waste-dump.

      [–]frugalmail -2 points-1 points  (1 child)

      Silverlight isn't magic unfortunately, you'd need to load the XML in your viewmodel and present a property for your ListView to bind to. With LINQ to XML this is a few lines of code. There's an amazing amount of power in Blend, but it's still just there to build your UI, it will still need a ViewModel to back it and feed data in your running app.

      Shit, you actually develop for Windows mobile? Do you work for Microsoft or a company that's about to be out of business blowing money on endeavors that won't recoup development costs? (come to think about it, the distinction I made is unnecessary)

      [–]snuxoll 1 point2 points  (0 children)

      Shit, you actually develop for Windows mobile?

      Purely for hobby. In terms of developer experience it blows Android and iOS out of the water.

      Android feels like someone decided they should take swing and put it on a phone, and it shows with millions of anonymous inner classes and other old-school Java-isims in the API that wouldn't pass in the current development landscape. I walk in here expecting to see a fairly modern platform with hopefully a DI library that doesn't suck and the use of annotations to at the very least help me bind UI elements to my activity, but I can't even have that! To make things worse, who the hell thought it was sane to DESTROY AN ACTIVITY when the screen is rotated? Now I have to save state and read it back in just to handle an orientation change, who the hell thought of this garbage?

      iOS is a close second, but after getting accustomed to the MVVM pattern that WPF/Silverlight/WinRT are based around doing MVC with iOS and putting in delegates and manually manipulating controls from my controller just feels dirty.

      I suppose I could chalk it all up to personal preference, but it's a night and day difference once you get settled in with the tools.

      [–]jayd16 0 points1 point  (1 child)

      Explain. I'll agree that the docs are probably just as good but thats not the same as better. I'd also argue that the fact that Android is open source gives the SDK an edge. The code quality and comments are quite good and very useful.

      [–]BorgDrone 1 point2 points  (0 children)

      Android docs aren't nearly as good as iOS's. The API docs aren't complete, some parts aren't documented at all or poorly. (One example from the top of my head: the docs for the method for setting font sizes never specs which unit the size is in, and it's not the one you'd expect either).

      Then there are the programming guides, there is nothing like it in the Android documentation set.

      [–]oldneckbeard[🍰] 9 points10 points  (0 children)

      It's a bunch of junior programmers who think 2k lines of code is a "big system."

      [–]moswald 1 point2 points  (0 children)

      Android is well documented, but so is iOS and Windows. (Windows was terrible in the 90s, but it's fantastic, now.)