I've learnt Cocoa + Objective C primarily for iPhone development, and I need to utilize this skill set to build a very basic kiosk application for OS X in a couple of days. The application is basically as follows :
The setup has two touch screen monitors, the app must be running full screen mode. The monitor on the right acts as a detail view to a list of options on the left. There are 3 options on the monitor on the left. Picking one will play a movie on the right, Picking two will take you to a quiz, Picking 3 will pull up a Webview.
The user may not use any other operations on the PC. (I've started reading about OS X application development and realized Cocoa provides a kiosk mode for these types of apps)
My questions briefly are
Firstly, any help on how to get my app running in a kiosk mode is much appreciated! I'm under a bit of a time crunch (2 days to get all this done, talk about life in startups!), so completely static content is fine, I'm slightly worried about how OS X will handle full screen mode if an app has been written in a smaller window size. (Scaling etc.)
Next, assuming there are two windows, one on each screen, how do I deal with focus? If the user suddenly gets bored with content on the right and touches the window on the left, the first touch will probably act to focus the window and the second will act as a click on the button. I'd like to avoid this scenario!)
What are the navigation paradigms in OS X ? I'm guessing it's not as simple as [navigationController pushViewController]? In short, how do I display a new view over an existing view?
Thanks,
Teja
Firstly, any help on how to get my app running in a kiosk mode is much appreciated!
http://developer.apple.com/library/mac/#technotes/KioskMode/
Next, assuming there are two windows, one on each screen, how do I deal with focus? If the user suddenly gets bored with content on the right and touches the window on the left, the first touch will probably act to focus the window and the second will act as a click on the button. I'd like to avoid this scenario!)
Click-through is the default. If you have any custom views, respond to acceptsFirstMouse: with YES to support click-through in them.
What are the navigation paradigms in OS X ?
Typically either window-based or source-list-based. Your application is atypical.
I'm guessing it's not as simple as [navigationController pushViewController]?
It's simpler and more complex at the same time. There is no stack to manage; you can have multiple windows up at the same time. It gets more complex when you want everything in one window (as in your kiosk-mode app), in which case you end up using tab views (with or without tabs) to enable the user to switch from one view to another.
In short, how do I display a new view over an existing view?
You don't. Layering one view over another in the same superview is barely supported at all in AppKit, and almost always wrong.
In a normal application, you should make multiple windows. In an app like yours, you'll need to use tab views. View controllers may help you here, although NSViewControllers are very different from UIViewControllers (as I mentioned, no view stack); they're more similar to NSWindowControllers.
Related
Is there a OSS custom control or source code sample for doing something like the iOS Picker controls on Mac OS X (the spinning barrel thingie)?
A bit of research on the web and sites like http://www.cocoacontrols.com didn't turn up anything..
I realize that the paradigm will be awkward for many scenarios however it'll be ideal in terms of screen estate (and design) for the casual app I'm working on.
Any hints appreciated.
You might want to think about customizing available controls to create a spinning barrel effect. Haven't tried, but it might be overkill. I might think of using buttons with text for the contents (or a table view with custom cells), and/or a scroll view with animation for a scroll event. It might be a useful customization for Mac OS X, without consideration for the fact that UIPickerView was meant for a touch screen.
Edit: This might be a start in the direction you want to be going. -> https://gist.github.com/1558664
I want to create a system wide minimize-in-place feature that occurs when double-clicking the title bar of any visible window in layer 0.
It seems that this would be a really simple feature to re-implement... When a title-bar is double-clicked, just draw the title bar only. That's it. The problem is implimenting it in all applications. I think it requires writting a custom framework to override the behavior in AppKit? Maybe NSApplication, NSWindow or NSView?
How can I recreate minimize-in-place?
Is a framework my only choice? If I create a framework, can I replace the behavior of minimize in 3rd party apps?
Which framework do I need to override in order to intercept and recreate the default behavior of the minimize button?
More about minimize-in-place:
I am familiar with WindowShade by Unsanity, this is exactly what I want to create. Supposedly unsanity is working on a Lion version, but their track record is bismal. Minimize-in-place was a system feature way back in the days of OS 7 or 8. I have tried other utilities that try to replace this feature, and there aren't any that do minimize-in-place at a core system level like it needs to be done. Please don't offer utitlity suggestions, I am going to build my own.
I have built an Application that recreates minimize-in-place, but it's not good enough.
My Application semi-successfully recreates minimize-in-place by putting "placeholder" windows (belonging to my app) in place of the 3rd party windows when they get minimized to dock. When my window (title bar only) gets double-clicked, I close my window and restore the real window from the dock.
My custom app works perfectly, but there is a lot of application switching going on. I have optimized the switching between apps to be nearly seamless, but the fact remains that there is application switching going on every time a window title bar is double-clicked. The result of application switching is that menu bars switch back and forth, pallets of 3rd party apps hide themselves when my app takes focus, and the list goes on.
So, although I've built a concept app, this method isn't going to work as I'd like it to. Minimize-in-place needs to be implemented using some other method than building an Application, and I need help understanding how to do it.
What I know think I need to do. Suggestions and assistance welcome.
I think I need to write a custom framework that replaces AppKit? This seems overwhelming even though I only need a super-tiny portion of the code to be overridden? i.e. the core _minimize function whatever that may be.
When a title-bar of 3rd party window is double-clicked, just clip to the title bar and let the rest of the system function as normal. On un-minimize (double click 2nd time), set clip back to full window.
Simple right?
Thanks for any assistance/suggestions,
Chris
I'm relatively new to Cocoa development. I'm developing on Snow Leopard. I have a scenario in mind and I'm curious if the API supports it. I've not been able to find anything about it, so I assume its not possible. But I'm happy to be proved wrong.
Suppose I write an application that lives at the top of the screen just below the menu bar. The window floats, so it is always on top. This can be annoying, so one thing I had in mind was constraining other windows (especially those in other applications) so that they are below my application. Is there something in the API that would allow me to do that? To specify a maximum origin for all windows (except mine)?
Thanks.
There's no real supported way to do this. You could achieve something similar using the Accessibility API. You'd have to watch for window-moved notifications and shove the window back into the visibile area.
I don't think you can do that, you see, one of the cool things of a window's based UI is that you can stack Windows on top of others, in a desktop metafore.
Now, what you can do is a always on top window, using NSScreenSaverWindowLevel as the NSWindow level. One nice trick you can do is [window setLevel: NSScreenSaverWindowLevel+1], and it set's your window above the screensaver level.
I am debating whether to hide or not to hide the system tray in a Windows Phone 7 application. I've not found any general suggestions on this issue -the official Windows Phone design guidelines don't address this issue at all - except for Jeff Wilcox's blog post who suggested that he personally likes to see the system tray in applications. I'd like some general advice on this issue from other Windows Phone developers.
Some reasons for showing the system tray are
Doesn't take up that much space
Users may want to see it at times
Reasons for hiding it are
You can't control its background: unless you're using PhoneBackgroundBrush as the background the top row will stand out
Lots of widely used / official apps already hide it: all games as well as the official Facebook and Twitter app.
I'd appreciate all advice on this.
Transparency and colors are now possible with Mango by setting its BackgroundColor and Opacity :
shell:SystemTray.IsVisible="True"
shell:SystemTray.BackgroundColor="Transparent"
shell:SystemTray.Opacity="0"
I would say by default show it unless it really gets in the way in a way you can't workaround, especially if its an app and not a game.
I would say it depends on the application/game you are writing
If the app needs a network connection or if you will be in the application for a long period of time show it so the user can keep an eye on network and battery.
If you need the extra screen space (for a game?), and you rarely need network hide it.
Or... I guess you leave it up-to the user and give them a setting to programatically hide/show it.
I think its best to use the tray in applications that are tools or utilities. Typically these users would prefer more info than less when they're using applications on the phone (battery, network, time).
Also adding the tray in there tends to make the application look more native on the phone (according to me and others I've asked), which is a big plus because the user associates your app as if it was built with the phone OS.
But if the application is a game, media, etc. type of application I recommend you take it off, especially on panorama because it takes away from the intended design. Also these types of applications focus on the content and seeing multiple little icons at the top can take away from the experience.
Really to me the space it occupies isn't really THAT much, so that shouldn't be too much of an issue. But rather the purpose of the app as stated above.
I do like the suggestions that have been given as far as giving the user the choice. Check out this code:
bool ShowTray;
//ASK USER WHAT THEY WANT
//ShowTray = true or false;
SystemTray.IsVisible = ShowTray;
I've been reluctantly hiding, at least on any view where I have a background image; otherwise it looks too strange to me. I've been considering a setting in my app that would allow the user to choose, and persisting that to isolated storage.
Also considering maybe having the top of the screen in phone background brush color and have it fade / blend into another color or background image. Not sure how well that would turn out but as long as it is not a cheesy looking gradient effect, perhaps.
I'm hoping eventually MS will soon add support for transparency in the system tray or otherwise help address this issue. As a user I wish that I could force the system tray to always be visible across all apps, but as a developer I realize that the visual effect often doesn't look good.
Perhaps if the community came up with a new UX metaphor where maybe double-tapping in the system tray area would toggle whether it is visible. A single tap could perhaps start to animate / pop / hint at the system tray...
Following up on this question: Kiosk Applications - OS X programming - Multiple monitors
I'm an iPhone programmer just starting out with OS X programming, and I'd like to know how I can present multiple views sequentially.
What I basically need to do is - Have a welcome screen with a button called "Click here to continue". Once the user clicks that button, it needs to completely replace the view with another view presenting a table view of options that the user can choose from.
I actually need to create a couple more screens, but any help on how to get this basic setup can help me get started. The problem I'm having is almost all the mac application source code available on Apple's website seems to be oriented towards single window applications popping up multiple windows for any additional tasks.
Thanks,
Teja
I enjoyed using M3NavigationView from Martin Pilkington http://www.mcubedsw.com/dev
Basically it pushes and pops NSViewControllers on a stack and allows you to animate between them. I am doing this for a quick setup wizard on an app I am working on.
Make a tabless tab view, and put each of your views into one of the tab view items. In Interface Builder, each tab view item will have a view automatically, so you just need to put all of the subviews for that tab into that view.
You can then switch tabs from code—e.g., in response to the “Next” button.