3 ms·

A lot of the more recent iOS core apps and APIs seem either poorly conceived or implemented, or both. Auto Layout is a train wreck. Storyboards seem like a nice

A lot of the more recent iOS core apps and APIs seem either poorly conceived or implemented, or both. Auto Layout is a train wreck. Storyboards seem like a nice idea until you really start using them, Core Data + iCloud horror stories abound. Maps was a fiasco etc. Cocoa Touch + Obj-C is a very nice platform in a lot of ways but I'm losing faith in Apple's software architects. Contrast this with Android and even though I think Java is a poor choice for mobile development their engineering teams really seem to know what they're doing.

fpgeek 14y ago
Java was a great choice for the technical goals the Android engineering team was trying to achieve (cross-architecture portability, easier transition for non-mobile developers, etc.). The problem was that those technical goals turned out to be not very helpful in terms of meeting Android's strategic goals, given the way the mobile OS/device market has evolved. That's a mistake at a level above engineers and software architects (or at least a mistake so far - if, hypothetically, Intel managed to crack their mobile CPU problem the choice of Java would turn out to be very smart). This is the dual of Apple's situation with iCloud. The strategic choice to start building out cloud services to support their ecosystem is clearly the right one, it is the implementation that has missed the mark (so far).
- cageface 14y ago
  I understand the short-term reasoning for choosing Java. Unfortunately mobile is one platform where transparent access to native code is a huge advantage and Java/JNI puts Android at a huge disadvantage here compared to Obj-C/C++. This is why writing something like a Twitter client is actually much easier in Android but doing something really interesting like realtime multimedia or highly responsive, complex UIs is difficult to the point of impossible in some cases.
vor_ 14y ago
Auto Layout has been a godsend for me. What trouble are you having with it? In particular, I use the 10.8 NSSplitView support to manage resizing behavior without any code.
- cageface 14y ago
  For simple things it's fine but it's a real nuisance to work with in IB or in code and complex layouts get out of hand very quickly. The shorthand layout language is cryptic enough to impress a Perl programmer. I think Android and WP's XML-based structural layouts are far, far easier to work with, understand, modularize, and reuse.
  - ridiculous_fish 14y ago
    I don't know much about Android's layout, but from what I have seen, it looks rather ad-hoc. For example, LinearLayout (http://developer.android.com/reference/android/widget/LinearLayout.html http://developer.android.com/reference/android/widget/Linear...) looks to be a core layout class. It has boolean properties like "baselineAligned" and "measureWithLargestChild;" these appear to have been added as needs arose, instead of being part of a general layout theory. Autolayout, on the other hand, has a more general approach of establishing relationships between properties of views. Baseline alignment then just falls out: make view1.baseline = view2.baseline, or view1.top = view2.top for top alignment if you prefer. Equal widths fall out too: view1.width = view2.width. If you want a vertical stack you can write view1.bottom = view2.top. If you want a fixed aspect ratio (say, 4/3), you can write view1.width = view1.height * 4/3. The result is that it's possible to directly express complex layout ideas. For example, "make three buttons baseline aligned, 10 pixels apart, all of them equal width, none of them clipping their labels. If they cannot fit, then in turn: shrink the padding down to 4 pixels, don't require them to be equal width, truncate the first button's label, or lastly then grow the window / make the view scrollable, until they fit." That's an unrealistically elaborate example, but with autolayout it can be done entirely in IB, without any code at all. I am guessing with Android it would take a fair amount of manual work. So my view from a distance is that the autolayout approach is more general and elegant, while the Android approach may handle simple cases easily, but is more ad-hoc and random.
    - cageface 14y ago
      You should try actually building some complex Android UIs. You might find it eye-opening after working with iOS for a long time. I certainly did. It's true that AutoLayout's systems of interdependent linear equations are strictly more powerful than Android's structural layouts but they're a far more awkward solution to the vast majority of common UI layout problems. In practice Android UIs are far, far easier to write and maintain. Debugging the kind of complex AutoLayout schemes you describe can quickly become a nightmare. The structural approach taken by Android and WP is far more natural for the kinds of UIs you actually find in the field. Also, Android's CSS-like style system makes it far easier to define app-wide constants like grid spacing, margins, button padding etc and to change them in one place.

fpgeek 14y ago

Java was a great choice for the technical goals the Android engineering team was trying to achieve (cross-architecture portability, easier transition for non-mobile developers, etc.). The problem was that those technical goals turned out to be not very helpful in terms of meeting Android's strategic goals, given the way the mobile OS/device market has evolved. That's a mistake at a level above engineers and software architects (or at least a mistake so far - if, hypothetically, Intel managed to crack their mobile CPU problem the choice of Java would turn out to be very smart). This is the dual of Apple's situation with iCloud. The strategic choice to start building out cloud services to support their ecosystem is clearly the right one, it is the implementation that has missed the mark (so far).

cageface 14y ago
I understand the short-term reasoning for choosing Java. Unfortunately mobile is one platform where transparent access to native code is a huge advantage and Java/JNI puts Android at a huge disadvantage here compared to Obj-C/C++. This is why writing something like a Twitter client is actually much easier in Android but doing something really interesting like realtime multimedia or highly responsive, complex UIs is difficult to the point of impossible in some cases.

vor_ 14y ago

Auto Layout has been a godsend for me. What trouble are you having with it? In particular, I use the 10.8 NSSplitView support to manage resizing behavior without any code.

cageface 14y ago
For simple things it's fine but it's a real nuisance to work with in IB or in code and complex layouts get out of hand very quickly. The shorthand layout language is cryptic enough to impress a Perl programmer. I think Android and WP's XML-based structural layouts are far, far easier to work with, understand, modularize, and reuse.
- ridiculous_fish 14y ago
  I don't know much about Android's layout, but from what I have seen, it looks rather ad-hoc. For example, LinearLayout (http://developer.android.com/reference/android/widget/LinearLayout.html http://developer.android.com/reference/android/widget/Linear...) looks to be a core layout class. It has boolean properties like "baselineAligned" and "measureWithLargestChild;" these appear to have been added as needs arose, instead of being part of a general layout theory. Autolayout, on the other hand, has a more general approach of establishing relationships between properties of views. Baseline alignment then just falls out: make view1.baseline = view2.baseline, or view1.top = view2.top for top alignment if you prefer. Equal widths fall out too: view1.width = view2.width. If you want a vertical stack you can write view1.bottom = view2.top. If you want a fixed aspect ratio (say, 4/3), you can write view1.width = view1.height * 4/3. The result is that it's possible to directly express complex layout ideas. For example, "make three buttons baseline aligned, 10 pixels apart, all of them equal width, none of them clipping their labels. If they cannot fit, then in turn: shrink the padding down to 4 pixels, don't require them to be equal width, truncate the first button's label, or lastly then grow the window / make the view scrollable, until they fit." That's an unrealistically elaborate example, but with autolayout it can be done entirely in IB, without any code at all. I am guessing with Android it would take a fair amount of manual work. So my view from a distance is that the autolayout approach is more general and elegant, while the Android approach may handle simple cases easily, but is more ad-hoc and random.
  - cageface 14y ago
    You should try actually building some complex Android UIs. You might find it eye-opening after working with iOS for a long time. I certainly did. It's true that AutoLayout's systems of interdependent linear equations are strictly more powerful than Android's structural layouts but they're a far more awkward solution to the vast majority of common UI layout problems. In practice Android UIs are far, far easier to write and maintain. Debugging the kind of complex AutoLayout schemes you describe can quickly become a nightmare. The structural approach taken by Android and WP is far more natural for the kinds of UIs you actually find in the field. Also, Android's CSS-like style system makes it far easier to define app-wide constants like grid spacing, margins, button padding etc and to change them in one place.