iPad: UI Implications
After having written a couple of simple iPad apps to investigate certain features, I'm now close to being feature-complete on my first serious application. I'm finding that the lack of a standard menu for centralizing actions is the hardest thing to get used to. As a result of that, I've adopted the seemingly reasonable policy of having custom controls or control subclasses respond to gestures and behave accordingly. This leads to a couple of design difficulties: 1) It's not always obvious what kind of UI element or gesture is appropriate (or available) for enabling a specific action, and 2) Any desired gesture has some chance -- not necessarily documented -- of conflict with one used by a standard UI element. (The iOS Human Interface Guidelines are a partial solution but they are incomplete and, by necessity, can't provide fine detail. ) At the coding level, I'm noticing that I'm using notifications far more than I would in a Mac application. In the Mac world, it's likely that an application-specific action will be recognized first by a controller (in the MVC) sense which will coordinate data and view updates in some way. With the iPad, I'm finding it more likely that a lower level object will be the natural recipient of the action and will then need to broadcast its interpretation of that. Not that there's anything wrong with that, though debugging session tend to be less intuitive, but it has required some revisions to my thinking. So far, I've resisted the temptation to replicate Mac menus using UIBarButtonItems and UIPopoverControllers. :-) I don't have any specific questions or problems associated with this but I'm curious about attitudes, techniques, patterns, or tools that others have found helpful going from Mac to iOS.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iPad: UI Implications
On Nov 26, 2010, at 9:02 AM, Phillip Mills wrote: I don't have any specific questions or problems associated with this but I'm curious about attitudes, techniques, patterns, or tools that others have found helpful going from Mac to iOS. At a high level, you don't go from Mac to iOS. i.e. you don't attempt to port, clone the UI, etc. Start with a mission statement of what you want to do with the iOS app. Keep it simple. Perhaps start with the mission statement of your Mac version, then trim it down to what makes sense to have in a mobile environment. Then, storyboard your app. Do not even reference your Mac version; think about the best possible ways to provide your features. Trust me, don't get hung up on how the Mac version presents itself. Rethink everything. There is room to share though, but leave that to your business logic. FWIW, here's my setup for all my apps: (1) A set of foundation classes (utilities, common models, etc.). These are shared* between all apps for Mac OS X and iOS. (2) A shell app. There's one for Mac OS X and one for iOS. All apps I write sit upon one or both of these. (3) Business logic for each individual app. These are shared between Mac OS X and iOS. (4) Individual projects for Mac OS X vs. iOS. Here, they sit upon the appropriate shell and reference all common code. Graphical assets, nibs, etc. are then unique to each individual project. * sharing has had its downsides. The original Mac version was baselined to Mac OS X 10.4 (pre Objective-C 2.0). Thus, that set of code isn't yet using things like the newer property syntax. My newer individual projects though do. Also, know that in iOS, there is no GC. So either create dual code to handle both cases (you can then drive things with compile-time macros), or stick with non-GC code everywhere. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iPad: UI Implications
On 2010-11-26, at 11:34 AM, Ricky Sharp wrote: At a high level, you don't go from Mac to iOS. i.e. you don't attempt to port, clone the UI, etc. Actually, I'm going from Mac to iOS at an even higher level: programming style and patterns of object interaction. In other words, this application has no existing Mac equivalent, so porting is a non-starter. :-) Thanks for the tips, tough. If I ever try to create parallel applications, I'll keep those in mind. (No worries about GC. Many years of commercial development using Java has convinced me that GC invites a generally sloppy attitude...or maybe it's just Java that does that. [shrug]) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
