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 <phil.swen...@gmail.com> 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 <mwa...@gmail.com> 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 javaposse@googlegroups.com. > > To unsubscribe from this group, send email to > > javaposse+unsubscr...@googlegroups.com<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 javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
