Use of network proxies in a Mac OS X application - cocoa

As someone new to developing for macs I was wondering if I could gather some advice on dealing with network proxies. Currently the software makes use of:
NSURLRequest
NSURLDownload
[NSString initWithContentsOfURL:]
WebKit / WebView
I had a little search on google and found Apple's page on CFProxySupport although I haven't looked too deeply into implementation with the above. I also see that you can configure proxies in Mac OS X's System Preferences - do the above automatically use the values set here?
Also, in terms of user interface, what is usually expected when it comes to proxies? Is it acceptable to simply require the user to set the details in the System Preferences or should I really be providing the ability to set the details separately in my own application?
Thank you.

NSURL, WebKit etc. automatically uses the appropriate proxy set in OS X's System Preferences.
On the other hand it's difficult to set the proxy which is different from that in the System preferences if you use these APIs.
For a normal app, it's expected that you don't set proxies in your app ... E.g. my dad and mom dread internet configurations. They ask me to set up the internet for them for their Mac. I don't think they're willing to set the preference separately for separate apps.
Of course if your app is a download assistant, file uploader, or maybe a completely independent browser as FireFox, you might want to implement a separate proxy setting for your app, to suit the need of the geeks and nerds like me who uses your app!

Related

Is +[NSUserDefaults standardUserDefaults] shared across apps?

I have two questions regarding Apple's +[NSUserDefaults standardUserDefaults]:
1) Does this object represent preferences that are shared across all apps?
2) If not, and it has preferences for the current app only, what is the behavior in case I use it in a library that is embedded into two different apps? Will it be shared across these apps or not?
No, it is an object only used by the running application.
It will return the user defaults for whatever application is linked to the library or framework, and each application will still have their own object.
Although mipadi is absolutely right, I'd like to add some value here.
If you explicitly want to share preferences across apps, there's "App Suites" for you.
NSUserDefaults documentation

Elevating my Mac application in XCode

I have some basic skills in Xcode (Obj-C and Swift) and I want to write a single application for doing some administration stuff on client Macs. (For example: setting the Software Update Server ULR, switching on Remote Administration, showing network traffic etc.) What is the proper way to gain administrator privileges? I'd just like to avoid repeating password prompts. Can/should the whole application be elevated?
I prefer Swift, but cannot find a good tutorial or any up-to-date documentation. As I will be the only person to use this application, the security concerns may be different.

Providing web services through XCode

All,
I'm writing an extensive iPad application with a Core Data based data model. Because the app requires a lot of user input / typing, I would also want to make the functionality available as a web page, so that users can use standard PCs to key in some of the data.
I'm not particularly worried about the UI for that web app, but I do want to re-use the application logic and Core Data model that I'm using for the iOS app, so my preferred approach would be to expose the functionality as web services on a Mac (using the built-in Apache web server, most likely), using XCode for MacOS.
(1) Are there any existing XCode-based frameworks that simplify the generation of web services?
(2) Am I missing something obvious i.e. is there a better approach to tackle the problem "exposing iOS functionality through a web environment"? Obviously, I could've immediately focused on writing the app in HTML5, but I did want to leverage all the goodies that come with iOS/Cocoa.
(3) Alternatively, I could write a native Mac OS app. That facilitates the re-use of Core Data, etc., but I heard it takes a lot of work to port iOS apps to Mac OS. The question then is what's more work - exposing the functionality as web services or porting it to Mac OS... in both cases, I would need to rewrite the UI.
thanks everyone,
Fabian
If you want iPhone/iPad users to be able to access the App through the PC web browser to send data/files to the App then take a look # this one:
http://blogs.oreilly.com/iphone/2008/09/creating-an-iphone-based-web-s.html
Check this question too:
https://apple.stackexchange.com/questions/9012/has-anyone-ever-tried-to-use-an-iphone-as-web-server
I did some more research and came across the WebAppKit framework. It allows you to easily set up a web server capability and handle requests and responses. It's lightweight, easy to understand - exactly what I wanted.

Advantages/disadvantages of browser-based interface vs. graphics

I'm in the design phase for a desktop-based application. Because of the nature of this particular application, I believe it would benefit greatly from a web-based approach (i.e., allowing a user to interface with the application through a browser running in kiosk mode) in order to leverage the simplicity of HTML/CSS/JS and the availability of many great JS interface plugins. Does taking this approach (rather than coding in a native or cross-platform graphics library) come with any gotchas?
Well, your access to the OS and other domains are going to be limited.
What about using something like Adobe AIR that lets you use HTML/CSS/JS and compile it into a proper desktop app?
Please look at http://www.terrainformatica.com/htmlayout/ - the library which was designed to create desktop GUI using html and css.
The main "gotcha" to doing a web GUI is that you are going to need to set up a web server of some kind. A gui app can be just a single executable. You allso (probably) will need some GCI coding to get information back from the user to your program. In general, it is liable to be a whole lot more work.
Balancing against that is the fact that any user networked to your webserver anywhere in the world using the OS and browser of their choice should be able to operate your program.

Using the browser for desktop UI

How can I use the browser as a UI for a desktop app? The ways I have come up with so far are...
Use all HTML/Javascript. Problem: Can't access filesystem or just about anything else.
Run a local webserver while the application is in use. Problem: How do I kill it when the user is done? My users are not technical enough to Ctrl+C.
Embed a browser component in a regular GUI. Problem: Embedded browser components tend to be glitchy at best. The support for Javascript/CSS is never as good as it is in a real browser.
...?
The ideal solution would work with any technology. I know there are options like writing Firefox extensions, but I want to have complete freedom in the backend technology and browser independence.
Please note that if you choose to run a local webserver, you're creating a security risk.
Any webpage running on the same machine that knows about your app can send requests to your server using Javascript, and you have no simple and reliable way of knowing what the request came from. (Don't trust the referer header)
Google Desktop, which uses a similar approach, has had several real-world vulnerabilities that allow any webpage to read any file on disk.
There are several ways to protect against this; I would recommend requiring each request to have a auth key which is randomly generated per-machine (and expires at some point), which you could put in the source for the actual pages. XHR protection would prevent malicious websites from reading the auth key, rendering them powerless.
If you are looking for a python Web Server with a Kill link, you could always check CherryPy.
import webbrowser
import cherrypy
import threading
class MyApp:
""" Sample request handler class. """
#cherrypy.expose
def index(self):
return """<html><head><title>An example application</title></head>
<body>
<h1>This is my sample application</h1>
Put the content here...
<hr>
Quit
</body></html>"""
#cherrypy.expose
def exit(self):
raise SystemExit(0)
class MyBGThread(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
self.start()
def run(self):
cherrypy.tree.mount(MyApp())
cherrypy.quickstart()
myThread = MyBGThread()
webbrowser.open("http://127.0.0.1:8080")
This code is based on the sample from the SingleClickAndRun on the cherrypy website:
http://tools.cherrypy.org/wiki/SingleClickAndRun
Note than in a normal WebApp you would probably use a templating engine and load templates from methods like main.
Something that would be nice would be to embbed a browser control in a gui window and close the server when the app exits.
For the security, you could possibly add an authentication scheme. There are a few that are supported by cherrypy, but you possibly could implement your own too, using tool modules.
I am looking to do the exact same thing (desktop app that uses an up to date HTML5 / CSS3 browser as the desktop app's GUI), only with Ruby (various reasons why I decided to work with Ruby). Its amazing the number of cross platform libraries people have come up with. But yet, few to no one, has done any work on trying to get a web browser to be a desktop app UI. Cross platform issue... well I won't say solved, but I will say several steps in the right direction taken.
To me this would be perfect with the new HTML5 / CSS3 standards coming out. I know it can be done with a web server running locally.
Another way might be like how the guys from “280 North” are doing what they do. They developed Objective-J (an extension of regular JavaScript that mimics how Objective-C extends regular C) and Cappuccino (the Objective-J equivalent of Objective-C’s Cocoa frame work on the MAC). They also developed “Atlas” which is 280 North’s version of Apple’s “Interface Builder” from Xcode, for their Objective-J and Cappuccino frameworks to build Internet Applications. Atlas is actually a Cappuccino web app running on your desktop as a desktop app. In this case they use the Narwhal… a cross platform, general purpose, JavaScript platform for developing JS apps outside of the browser (basically a specialized web server).
If any one can come up with an idea to make “Browser, direct connect to Desktop App” work without the need of a web server co-existing and still get to manipulate the local FS, I to would be very interested… Hmmm... Now that I think about it, I wonder if the new Google Chrome project “Native Client” can be used to do that. NaCL is much like Active X except you are not limited to a windows platform (but will be limited to the Google Chrome browser, at least for now). Only there is added security via Sandboxing, but you can manipulate the local FS… The more I think about it, the more I am beginning to suspect that it can be done.
Any thoughts?
In Windows, you could embed the IE ActiveX control, which uses the same rendering engine as IE. (That's a plus and a minus) You can set the ScriptObject property in your host code and access it in Javascript as window.external to do things that Javascript cannot do.
If you run a local webserver, you could have an exit link in the app that kills the websever.
You did not mention the OS you will need to target. But you might be able to create a program statared web server, then launced the default browser. Wait until the browser is terminated by the user and then shut down the web server.
So for example on windows you can use CreateProcess() to spawn the process
then MsgWaitForMultipleObjects() to wait until it is finished executing.
HTML Applications (HTA, for short) have been around for a while. You can read all about them here. They are basically HTML and Javascript with some extra options to create a window and with access to the local file system. They seem to be exactly what you want. It is Microsoft technology, so this will only work with IE on Windows systems. I've successfully used this as a front-end for a CD-ROM which was used to distribute software to first year students
Another option would be to use Adobe Air. I'm not all that familiar with the technology, but it seems to provide a framework to deploy web pages as desktop applications. I can't post a second link as a guest, but just google it and you'll find it soon enough.
Today, in 2023, you can simply use any installed web browser as GUI using the WebUI library.

Resources