How can we add new features .. will we flood apple with radars? :) about quickradar HOT 8 CLOSED

You mean how do we test it?

I've just been asking around my workplace for all the radars people have been meaning to file, and writing them down. Each time I need to test something, I take one off the list. It's a bit flood-y, but since Apple are always asking us to file more radars then I don't think it's too bad.

I'm certainly not filing ones that are just test data, that would be bad.

from quickradar.

@amyworrall I wonder how to do it. Id like to work on some 'lower level' stuff :)

oh and please tell me what I should/could do then .. or at least try :D

from quickradar.

mhm maybe ill ask them if can have a sandbox :D

from quickradar.

Regarding the lower level stuff, I have an idea for a better architecture which I was hoping to get to this week. Here's a brain dump of what I'm intending to do:

Currently the web scraper is one big monolithic method. I'm planning to make a new class, PageScraper or something, which takes a URL, a dictionary of POST parameters, a method, and then a dictionary of keys and Xpaths. You then set it going, and it fetches the page then outputs a dictionary with the keys and the results of the Xpaths (or it returns an error parameter). Probably it'll still be synchronous and we just execute everything in the background queue like presently.

Once that's in place, the big method of doom will be much simpler, because it'll be four or five page loads chained together. At that point, it'll be easier to add error handling, and then start adding new features. With that in mind, if you could wait a few more days until I've got this architecture in place, it'll be much easier to work on the internals.

So, features to add could include file handling: I know some Radar types require file uploads. As an example, here's how I'd approach that:

The way I start out doing some web scraping stuff is start up a copy of Charles (web debugging proxy), and go through the process of filing an actual radar that meets the criteria. For the file uploading ones, you'll need a crash or something that requires an upload. In Charles, take a note of what request is made when you submit the radar: you need the keys and values that are filled in, and the order which they're included. One of those will be the file data, but there will probably be other fields we have to take into account too: Radar is a tricky beast and uses Javascript to change the values of hidden fields.

After you've got the keys/values it's submitting, then you need to work out where it gets the keys from. A lot of them are numbers separated by dots. This is a side effect of the way WebObjects works. What I do is work out which one means what, and then come up with an Xpath that will find the name of the equivalent form field for me. This step probably won't be needed as I think I've got most of them already.

At that point you'd be ready to hook up some UI and give it a file. I guess we'd need a file well in the UI, and an NSData property on the RadarSubmission class, and then some code in the RadarWindowController to populate the NSData. The other change required for file handling is changing my SuperURLConnection to be able to deal with files as part of a multipart form data upload. That'll be pretty easy to do, most of the hooks are there, it just needs a couple of lines to make it actually put the file into the request.

Anyway, that's how I'd approach adding a feature like that. Currently I'm working on the new architecture for web scraping, and also OpenRadar integration (I'm talking with Tim who runs it, so that we can work on an API format).

In terms of low level things I'd like to see in QuickRadar but am not working on yet, essentially anything to do with submitting bug reports. For example, I haven't done anything towards file uploads and configuration information: for the latter, I think on Apple's site you have the option to enter the info either by a file upload, by selecting an existing one, or by entering text. We'd need to think about the best UI for doing that in QuickRadar.

In terms of things I don't want to put in QuickRadar: at the moment, anything that isn't to do with its primary purpose (which is to submit radars with as little setup and faff as possible), with the exception of OpenRadar integration which I do want to do for this version. Things like browsing your existing radars would be nice, but are too broad in scope: the app will be all the better for being really narrowly focussed especially at the beginning. I'm going to do a binary release on the quickradar.com website when I think it's ready to be 1.0, and for that I'd like something that works well but doesn't over-reach.

Anyway, this was probably more than you wanted to know about where I see the project going! Once I've got the new web scraping architecture in place I'll try and get a bit of documentation in place so that other people find it easier to dip into the internals.

from quickradar.

Oh, and if you can manage to get Apple to give you a sandbox in Radar, I'll eat my hat :)

I've recently filed radar 11707942, asking for a REST API for submitting radars (which would mean we no longer had to web scrape). You should probably file radars asking for both of those things :)

from quickradar.

Oh, and if you can manage to get Apple to give you a sandbox in Radar, I'll eat my hat :)
:D

In terms of things I don't want to put in QuickRadar: at the moment, anything that isn't to do with its primary purpose.
Ill look into file attaching. Shouldnt be too hard I hope. :D

from quickradar.

today I moved a lot of code around (didn't change much and eager for your update to the model)

• we now have an iOS app and an OSX app both using a COMMON core
  (as a side effect I splir up the mega method because I had to debug it for iOS.)

now iOS is working fine, as is OSX. Ill make a pull request later

from quickradar.

btw: I read your braindump before I started. I didn't modify much.
I guess this is resolved now

from quickradar.