PDA

View Full Version : I know you are probably getting sick of me but...




tominated
Dec 11, 2006, 11:50 PM
Can someone help me out on what steps i need to follow to make tominated browser have downloads. if possible, can you describe what all the code means/does?



robbieduncan
Dec 12, 2006, 02:33 AM
Before asking questions here did you read the documentation? At all?

You need to set a download delegate as described here in the documentation (http://developer.apple.com/documentation/Cocoa/Reference/WebKit/Classes/WebView_Class/index.html#//apple_ref/doc/uid/TP40003822).

The delegate callback methods are described in the WebDownload (http://developer.apple.com/documentation/Cocoa/Reference/WebKit/Classes/WebDownload_Class/Reference/Reference.html#//apple_ref/occ/cl/WebDownload) class reference. Remember to check it's superclass too as that's where the meat of the methods are in this case.

caveman_uk
Dec 12, 2006, 03:12 AM
Basically you probably need a queue type structure to handle multiple downloads and handle the call backs for each download as Robbie says. The main problem is that downloads are asynchronous so you can't just call method that says download this and get the file back as a return value. You say, start this download, you go off and do something else and the OS sends your code messages saying download failed, done this much, download finished etc.

This stuff isn't complicated to do but it is done almost entirely in code. I feel you may find it rather hard to do this at this stage given your current level of knowledge.

Only allowing one download at a time is obviously easier as you won't need the queue...but sucks as a design decision.

tominated
Dec 12, 2006, 03:39 AM
Basically you probably need a queue type structure to handle multiple downloads and handle the call backs for each download as Robbie says. The main problem is that downloads are asynchronous so you can't just call method that says download this and get the file back as a return value. You say, start this download, you go off and do something else and the OS sends your code messages saying download failed, done this much, download finished etc.

This stuff isn't complicated to do but it is done almost entirely in code. I feel you may find it rather hard to do this at this stage given your current level of knowledge.

Only allowing one download at a time is obviously easier as you won't need the queue...but sucks as a design decision.

ok. i will have a read of the aaron hillegass book (found it at this massive book store) and maybe see if i can figure it out myself.

robbieduncan
Dec 12, 2006, 04:43 AM
Basically you probably need a queue type structure to handle multiple downloads and handle the call backs for each download as Robbie says. The main problem is that downloads are asynchronous so you can't just call method that says download this and get the file back as a return value. You say, start this download, you go off and do something else and the OS sends your code messages saying download failed, done this much, download finished etc.

This stuff isn't complicated to do but it is done almost entirely in code. I feel you may find it rather hard to do this at this stage given your current level of knowledge.

Only allowing one download at a time is obviously easier as you won't need the queue...but sucks as a design decision.

You don't need to maintain a very complicated queue. The messages the delegate receives are all setout here (http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSURLDownload_Class/Reference/Reference.html#//apple_ref/occ/cl/NSURLDownload) under the Class Description. All of them pass an NSURLDownload object that is unique per download. To begin with most of the delegate methods are probably not needed (or at least you can provide an implementation that does as close to nothing as will work). Most of the methods are there to let you control redirections and user authentication and to update progress bars etc. None of which are required to just get up and running.

Probably the only one you actually need to do much with to start with is - (void)download:(NSURLDownload *)download decideDestinationWithSuggestedFilename:(NSString *)filename without which the file won't save anywhere!

My understanding is that the NSURLDownload objects handle the asynchronous background downloading for you, probably by doing something every time through the run loop.

If I'm bored tonight I might try and put together a simple demo project showing how to get the basics of downloads running...

tominated
Dec 12, 2006, 04:49 AM
You don't need to maintain a very complicated queue. The messages the delegate receives are all setout here (http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSURLDownload_Class/Reference/Reference.html#//apple_ref/occ/cl/NSURLDownload) under the Class Description. All of them pass an NSURLDownload object that is unique per download. To begin with most of the delegate methods are probably not needed (or at least you can provide an implementation that does as close to nothing as will work). Most of the methods are there to let you control redirections and user authentication and to update progress bars etc. None of which are required to just get up and running.

Probably the only one you actually need to do much with to start with is - (void)download:(NSURLDownload *)download decideDestinationWithSuggestedFilename:(NSString *)filename without which the file won't save anywhere!

My understanding is that the NSURLDownload objects handle the asynchronous background downloading for you, probably by doing something every time through the run loop.

If I'm bored tonight I might try and put together a simple demo project showing how to get the basics of downloads running...
hold your horses, i only just started with cocoa. all that was german to me

robbieduncan
Dec 12, 2006, 05:01 AM
hold your horses, i only just started with cocoa. all that was german to me

Entshuldigung (which, if I remember school properly is German for sorry).

Basically you need to a new class with will be your download delegate. This will implement the delegate methods listed for both WebDownload and it's superclass NSURLDownload. When you click on a link that should start a download WebKit should automatically create a WebDownload object (which is of course also a NSURLDownload) object. It will set the delegate of that object to the instance of your class that you set as the WebFrame download delegate (note that there will be once instance of this class, it will not create a new instance for each download).

The WebDownload object will deal with the actual low level nitty gritty of downloading the data. You don't have to worry about receiving a stream of data and writing it to file as it arrives.

The WebDownload object will send your delegate object a message whenever anything "interesting happens". To start with you don't want to do anything with most of these messages, simply do nothing if the return type is void, always return Yes or No (depends on the message) if the return type is bool or return the passed object of the same type for all other messages. The only message you need to do anything with should be the one where you need to set a filename. When you receive this you should show a save panel and then call - (void)setDestination:(NSString *)path allowOverwrite:(BOOL)allowOverwrite on the WebDownload object passed in the message to set the filename to save to.

Later when you want to be able to show progress, cancel in progress downloads, respond to authentication challenges (i.e. login requests) etc you will need to maintain some sort list of in progress downloads. As all the messages pass an NSURLDownload object you should probably key your inprogress store off this to enable you to find them quickly.

robbieduncan
Dec 12, 2006, 02:13 PM
So here you go. I've written my own browser too. It's taken me an hour reading the documentation to get this working as I want. It can't do much, but it can download files!

It's up to you to pretty this up with progress indicators and the like. This is the minimal stuff to support downloads.

Edit to add some stuff: the reason it took an hour is that it took me a while to work out where to start the download from. The Policy Delegate is the key! Then you need the download delegate as above to set the path to save to. I assumed the default policy would be to download if the file can't be displayed but it appears the default is to ignore it!

gekko513
Dec 12, 2006, 02:20 PM
If I'm bored tonight I might try and put together a simple demo project showing how to get the basics of downloads running...
Can I have some of that motivation to tinker around with programming projects? I'm all void of programming motivation. :(

robbieduncan
Dec 12, 2006, 02:22 PM
Can I have some of that motivation to tinker around with programming projects? I'm all void of programming motivation. :(

Demos are easy. I'm struggling to get the motivation up to finish off the next release of Poster Paint. It's like 90% done, the last 10% is the nasty bug fixing and tidying for release that I'm not too excited about!

gekko513
Dec 12, 2006, 02:29 PM
Demos are easy. I'm struggling to get the motivation up to finish off the next release of Poster Paint. It's like 90% done, the last 10% is the nasty bug fixing and tidying for release that I'm not too excited about!
I know the feeling. Good luck. What are the highlights of the new version?

robbieduncan
Dec 12, 2006, 02:38 PM
I know the feeling. Good luck. What are the highlights of the new version?

Added quick access to grid via button beside zoom menu at bottom right of window.
Drawing tools (Pencil, Brush, Spray) show custom cursors giving feedback on the area that will be changed, other tools use crosshair curson.
Generic bundle loaded added to allow for arbitrary plugins.
Added a new bundle to test the above that allows for image resizing (scaling) and canvas resizing.
Ability to drop folders on the Dock Icon added with an extensible architecture. Can currently open all images or add the images as backgrounds.
Some minor UI tidying up that no-one will notice like preventing the entry of non-numbers on the new document sheet in the width and height fields.

tominated
Dec 12, 2006, 02:45 PM
do you mind if i borrow some of the code for the next beta of tominated?
EDIT: whivh connection between the webview and the appcontroller is needed for just donloading. i have already got a different method for that fetch thing and i don't know which files to copy over...
...or...
...if you have the time, can you put the downloading stuff in the source of tominated? i don't mean to be annoying, it's just, i wanna get this to version 1 as fast as possible. you can get the source from the tominated software link in my signiture

gekko513
Dec 12, 2006, 02:48 PM
robbieduncan: Sounds good.

robbieduncan
Dec 12, 2006, 02:49 PM
do you mind if i borrow some of the code for the next beta of tominated?

As I put in the header of each file. Anyone who downloads it can do whatever they want with it. Consider it public domain.

tominated
Dec 12, 2006, 03:25 PM
As I put in the header of each file. Anyone who downloads it can do whatever they want with it. Consider it public domain.

awesome! thanks

MarkCollette
Dec 12, 2006, 04:52 PM
As a side note, for the source code .zip download of your tominated browser download, try doing a "make clean" or whatever equivalent that your IDE uses, so that there aren't any temporary build files in there.

robbieduncan
Dec 12, 2006, 04:56 PM
As a side note, for the source code .zip download of your tominated browser download, try doing a "make clean" or whatever equivalent that your IDE uses, so that there aren't any temporary build files in there.

Or setup XCode the way I have: all built products and temp files for all projects go into a separate directory. Keeps the source dirs clean and makes it easy to clean down if I need to :D

robbieduncan
Dec 12, 2006, 04:59 PM
EDIT: whivh connection between the webview and the appcontroller is needed for just donloading. i have already got a different method for that fetch thing and i don't know which files to copy over...
...or...
...if you have the time, can you put the downloading stuff in the source of tominated? i don't mean to be annoying, it's just, i wanna get this to version 1 as fast as possible. you can get the source from the tominated software link in my signiture

You need the DownloadDelegate and PolicyDelegates linked up to the to the WebView. I've no idea if you can connect this in Interface Builder. I simply did it using two lines of code in the awakeFromNib method of the AppController. Assuming that you have a document-based app you would do this in your NSDocument subclass when the new document (window) gets created.

Edit to add: I'm not about to write your app for you. If you want to take any sort of credit for this you have to read the examples and then write the code yourself, not keep begging others to do it for you. I know your only young and trying to learn, but if we write the actual browser instead of showing you ultra simple learning examples then by the end you won't have learnt anything.

Second edit to add: you can connect these in IB. Just instantiate the objects and connect them to the appropriately named outlets.

jeremy.king
Dec 12, 2006, 05:02 PM
So when does Duncanated v1.0 come out?

robbieduncan
Dec 12, 2006, 05:05 PM
So when does Duncanated v1.0 come out?

That's the source for it up above. I'm hoping it's the least well featured browser on the market :D

Eraserhead
Dec 12, 2006, 05:11 PM
btw, have you got your windows sorted? You haven't sent me the other source files I asked for.