Flexible layout managers are available everywhere, they are not what makes Apple's position challenging. The real problem is pixel independence and the fact that so far, they've been able to get away with using integer multiples of resolutions. Unsurprisingly, they have already hit a wall and experts seem to agree that doubling the iPad's resolution on both axes is not technically feasible in 2011.
Apple simply can't escape the fact that they will have to introduce fractional increases in resolutions and densities, something that Android decided to tackle since day one. Here is a great article giving more details about the whole thing, and calling BS in particular on people who say that fractional increases will produce crappy results (e.g. John Gruber): http://blog.yafla.com/Apples_Embarrassing_Predicament/ -- Cédric On Fri, Jan 21, 2011 at 5:07 PM, Chris Adamson <[email protected]>wrote: > To expand on this and draw some comparisons… > > In Leopard, Apple was pushing developers to some resolution- > independence APIs, but not all of these made the move to iOS. The > foundations are there, but not all the details. In iOS, you're > supposed to think in terms of points, not pixels. On early iPhones, > iPods, and the iPad, one point equals one pixel. On the iPhone 4 and > 4th gen touch, one point equals four pixels. For bit-mapped assets, > you append @2x to your file names and the higher resolution version > gets used as appropriate. > > But that's not the whole story. For anything that involves text or > graphics drawn in code, you pick up resolution independence from Core > Graphics, as you'd expect. A lot of the basic classes that Apple > provides draws stuff in code, so most apps scale up pretty nicely > (perhaps worth noting here that Cocoa prefers direct use of its > classes, with custom code provided via delegation, rather than > subclassing as you'd tend to do in Java frameworks like Swing). I did > a maintenance gig on the PGA Championship app last Summer, and in one > case, they opted to replace a PNG graphic of a score card with a > version drawn in code, since it would scale up and down easily (plus, > replacing year-old graphic assets is sometimes more of a hassle than > just stroke-and-filling it once and for good). > > One of the things that really came out of Dick and Joe's discussion > has to do with layouts. In AWT and Swing, we had LayoutManager > classes to do layout, while from what I can gather, Android uses XML > files to describe layouts. I think the idea is similar though: you > describe view objects' relative positions to one another, their > stretch behaviors, and so on. This has the advantage of working at a > lot of different sizes and shapes, or across platfoms where UI > elements and fonts may have different metrics, with the disadvantage > that it's hard to get things looking just the way you want. Jack of > all form factors, master of none. Or, like the guy in the cartoon > said: "Grid Bag" > > Since iOS devices operate with known screen sizes and consistent > widget metrics, its tools allow you to place widgets at specific > coordinates. On iOS, you don't have to defend against the screen being > 500 pixels (um, I mean points) bigger or smaller than you expected. > Widgets, or views, do get a bitmask of "autosizing" behavior that > controls what they do when their superview resizes, though it's just a > matter of growing or shrinking on each axis, and mantaining a fixed > distance from one or more sides of the parent (you can also tell a > view not to resize its subviews). Another difference is that the Java > layout managers don't typically allow for overlapping, short of > explicitly using multiple overlapping containers (glass pane, > anyone?), while it's very natural on iOS. > > I think this is what came up with Dick and Joe. Any Android app would > have to use dynamic layout, so dealing with a huge tablet screen would > be no sweat. The question is whether the resulting layout uses the > space appropriately: I can easily imagine ending up with oddly large > spacing between components, or a huge swath of wasted space at the > bottom of the screen. On iOS, you either run as an unmodified iPhone > app and pixel double, or use a completely different view for iPad, > which of course encourages you to rethink your UI. The latter is much > preferred. In fact, there are a number of UI elements that only work > on one platform or the other: iPhones cannot use the UISplitView (it > wouldn't fit), while iPads are not supposed to make the whole UI > subject to a UINavigtionController (with all that space, you should be > able to use menus and popovers to make selections and perform > actions). > > -Chris > > On Jan 21, 1:32 pm, phil swenson <[email protected]> wrote: > > I believe the only thing you have to do for iOS is include double sized > > resources (suffix @2x on resources). The widgets are not bitmaps so they > > auto-scale. iOS also has layout managers for handling align > > top/left/right/bottom.... > > > > here is a link describing the issues with going to a non-integer multiple > on > > higher resolutions: > > > > http://www.tipb.com/2011/01/19/problem-2x-ipad-2-retina-display/ > > > > <http://www.tipb.com/2011/01/19/problem-2x-ipad-2-retina-display/> > > > > > > > > On Fri, Jan 21, 2011 at 4:59 AM, Moandji Ezana <[email protected]> wrote: > > > Tor and Joe debated this for a while during #336. I think we covered it > in > > > another thread, but maybe it deserves its own. > > > > > My impression, gathered from my dabbling in Android dev and from what > > > Karsten said in that other thread, is that Android has a more logical > and > > > extensible system than iOS. > > > > > In Android, you have folders with special names into which you put > various > > > resources and the runtime then decides which version to use. These > > > resources can be layouts, images, text, color codes, binary assets, > almost > > > anything. The codes you can use to compose the folder names are things > like > > > ldpi, mdpi and hdpi for screen densities, portrait and land for > orientation > > > and locales. You can combine those three any way you want. That's an > > > extensible system, as Google could add new codes to handle whatever new > > > hardware situation arises. > > > > > Can someone contrast that with the iOS system? I got the impression you > had > > > to put checks in your code. > > > > > The one thing I wonder about Android's system is if all those resources > are > > > downloaded, even if they're never going to be used. If so, that could > be a > > > lot of bloat, when a lot of devices don't have even all that much space > to > > > install apps. > > > > > Moandji > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "The Java Posse" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<javaposse%[email protected]> > <javaposse%2Bunsubscribe@googlegroups .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
