A MapKit for Mac OS X? - cocoa

on the iPhone we have the Apple's amazing MapKit. There is something similar for Mac OS X?
If possible something more advanced than a simple WebView, because I need that it manage automatically at least:
annotations
the user interaction
the zoom in/out
an overlay view
(Even if the maps are not from Google is ok.)
Thank you very much!

Update 2
MapKit is available in OS X 10.9 Mavericks : Map Kit Framework Reference.
Update - pulled from my comment below
The situation has changed and there now exists a third party MapKit for Mac OS X. Find it at http://github.com/Oomph/MacMapKit and a small writeup at http://rickfillion.tumblr.com/post/1134987954/pretroducing-mapkit-for-mac
Orginal Answer
There is no such API from Apple on Mac OS X. You should file a bug request at bugreporter.apple.com.
The best alternative is to use the Google Maps JavaScript API embedded in a WebKit view. Visit the Google Maps JavaScript API V3 Documentation to understand the API.
I realize that you asked for more then a simple WebView, but perhaps you're unaware of some of the more advance functionality a WebKit view allows.
Webkit provides means for bridging between the JavaScript scripting environment in your WebKit view and the rest of your Cocoa application.
To call a Javascript function from Objective-C, use your WebKit view's WebScriptObject. "Using Javascript From Objective-C" from the "WebKit Objective-C Programming Guide" is a great place to start learning.
If you need to call back into your Cocoa application from Javascript, "Calling Objective-C Methods From JavaScript" in the "WebKit DOM Programming Topics" provides examples and explanation.
These technologies used carefully together should provide the functionality you require.

Related

How to best author a Apple Helpbook for a macOS app?

macOS apps, e.g. Photos.app, provide a help panel to the user
Is there a way to author such a Help Book in your own macOS app?
Is there a way to at least provide a toolbar to be used for a table of contents?
I am asking specifically about the UI and all the user interactions. Not how to generally create and register a helpbook.
Update
Here is what I’ve been able to find/gather/learn from others. A Help Book appears to run on a separate app/process called “HelpViewer”. Any Apple macOS app displaying a help makes use of a DDMViewerController that isn’t public.
There is an “app.css” and an “app.js” being used by the Apple macOS app “index.html” of the Apple Help Book. The Javascript one manipulates the DOM to create the “show-hide” link that toggles the Sidebar. Haven’t been able to find how to instruct HelpViewer to use a sidebar.
There is a WWDC talk from back in 2014, “Introducing the Modern WebKit API” that talks about “User Scripts” and “Script Messages” which allow communication between a Webview and Cocoa. https://developer.apple.com/videos/play/wwdc2014/206/
AFAICS, there is no way to have HelpViewer display a custom view or have a sidebar. My guess is that you would have to implement everything yourself. That is an NSSplitViewController, NSToolbar, NSOutlineView, any Javascript alongside the “app.css” to get the look and feel.
Currently it's not possible to implement the sidebar as shown in the Maps and other built-in macOS applications from 10.13 onward.
Versions of macOS from 10.10 (built-in applications) implement sidebar navigation with HTML and JavaScript, and Apple Help Viewer itself offers a window.HelpViewer object with some hooks that enable/disable the Help Viewer's table of contents button. Once enabled, it will callback into your own JavaScript where you can show/hide TOC via CSS or JS.
From approximately 10.10, Apple's non-built-in applications have also been using this technique. For example, iTunes and Xcode help both do this.
From 10.13, macOS has a newer version of Help Viewer that provides an actual Cocoa-native table of contents and windows splitter, as well as some new properties on window.HelpViewer; presumably these can be used to enable/disable the Cocoa sidebar and populate the TOC, but these are undocumented and I'm not sure anyone outside of Apple has been able to reverse-engineer this functionality yet.
And in any case, it wouldn't work if you offer Help Books to pre-10.13 users, and the use of undocumented API's restricts applications from the App Store (although, I'm not certain that Apple scans Help Book JavaScripts for API usage as part of their review).
(There are also a lot of other changes to how Apple's built-in application Help works now, too, but that's another topic entirely.)
Thus the answer for now is we can't, or shouldn't, or just don't know how. Alternatives include using something like using jekyll-apple-help (no affiliation) or Middlemac 3 (my project), or just rolling your own.
For those interested in knowing how Apple does it, I've documented a lot of it here (disclosure: link to my own website).
I'm not sure whether Apple's current applications still use it, but there is a very old API on macOS for Help Books. Apple has documentation on how to create them and some introduction. In short: Help books are standard HTML files with additional proprietary anchors. Those anchors are accessible via the class NSHelpManager, e.g. to open the help book at a specific page.
See also this question.

WebView vs WKWebView on OSX

Apple's documentation suggests using WkWebView for new development, although it seems to have a typo where it recommends WKWebView over UIWebView in the mac developer library.
For new development, employ this class instead of the older UIWebView class.
The typo is probably because they are trying to unify the OSX and iOS interface to the web view by using the same header for both.
However, WKWebView doesn't have all the functionality that WebView has in OSX. For example, you can get access to DOM nodes in the native interface in WebView but I don't see any way of doing this from Swift/Objective-C in WKWebView.
For my purposes, it seems like WebView is what I need, but I'm weary of starting a project that relies on an API that will be removed. However, I don't see any mention of intent to deprecate WebView anywhere in the headers or the documentation.
What makes this even more confusing is the WebKit Framework Reference makes reference to both WK and older web view APIs without clarifying anything.
WKWebView
A WKWebView object displays interactive web content, such as for an in-app browser.
WebView
WebView is the core view class in the WebKit framework that manages interactions between the WebFrame and WebFrameView classes.
Is WebView going away in OSX?
Its not a false alarm. Apple moved Safari off of UIWebView/WebView in 6.0, so security fixes simply aren't happening in the old class as much. For that reason alone you should not use it for new stuff. Apple has been incrementally improving it with every OS release so much is now do-able with private extensions (file:// access, downloads, etc)
That being said, it won't be fully equivalent to old WebView. You can't directly access the DOM anymore because the Network/Rendering/UI processes were split up and you create locks by making element references like that. Use the postMessage() message handler and wkwebview.evaluateJavaScript() and callback-ish/promisy JS code between those two pillars to deal with web<>native interaction asynchronously.
Important
Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app.
Do not use UIWebView or WebView.
https://developer.apple.com/documentation/webkit/wkwebview

What's that app or library that allows one to add functionality to cocoa apps?

I recall reading about an application or library that allows to add some functionality to Cocoa apps.
I found it when searching for an application for using mouse gestures in Finder and applications other than browsers, but I didn't pay too much attention to it because I didn't know Objective-C or Cocoa at the time.
Do you have any idea of which one could it be?
Perhaps you're thinking of SIMBL?

How does the Mac Web Dash board app work?

Would like to understand how to build a tool like the mac os dash board widget (web clip). Am looking at trying to build it with webkit but not sure if thats the right way to go.
Some thoughts were to using webkit and some DOM to display only the viewport that a user requests.
While this works so well on mac os, am trying to build it on windows with .Net.
Dashboard just uses webkit to display some HTML and JavaScript for the dynamic parts, but there are a couple of extensions. Apple have developer documentation on Dashboard.

How to use Mac OS X Cocoa events for multitouch gestures

I'm writing a program that has an NSView embedded in an NSScrollView which user can zoom. I'd love to set it up so the user can zoom the view using the multitouch pinch gesture supported on MacBook Air and the new unibody MacBooks/MacBooks Pro and in applications like Safari and iPhoto. I've hunted through Apple's documentation and can't figure out how do to this.
Is this supported using publicly available APIs on Mac OS X 10.5 Leopard?
If not, how "bad" are the private APIs (e.g. is it just an undeclared constant or a whole new set of methods)?
Edit: Snow Leopard adds supported APIs for gestures and multi-touch. See the AppKit release notes for Snow Leopard; ⌘F for “gesture” and “MultiTouch” (sic). They'll look pretty familiar if you've used ones below, but there probably are some fine differences, so read the new documentation anyway.
Is this supported using publicly available APIs on Mac OS X 10.5 Leopard?
No. 10.5.0 doesn't support it at all, and 10.5.1 through 10.5.6 make you implement undocumented methods.
If not, how "bad" are the private APIs (e.g. is it just an undeclared constant or a whole new set of methods)?
Not bad at all. You have to implement some undocumented event methods in your view. Since you're the one implementing the methods, you shouldn't crash if Apple changes the methods; all that will happen is the feature will stop working.
However, if you'll be retrieving the absolute (not delta) magnification or rotation from the event, then those are as-yet-undocumented methods of the event, so you should guard those messages with respondsToSelector: messages and perform careful range-checking on the methods' return values.

Resources