HTTPService does not seem to allow modification of certain headers, amongst them the "Accept" header (it was "Cookie" last time for URLRequest). Specific need: to call a RESTful webservice with "application/json" before "text/html" in the list (otherwise, I get back HTML!).
URLRequestHeader's documentation semi-explains about one only being able to change certain headers when in a certain sandbox/ApplicationDomain. Curiously, HTTPService doesn't mention -- just doesn't do!
Ahha, thanks to good doc in URLRequestHeader (the class that let me down for my "Cookie" need last time), I find URLRequest does support a "requestHeader" property. Perhaps there is light.
<time passes...>
Yup, that seems to work. Switched from HTTPService to use of a URLLoader and things now behave. This brings the function size and scope up radically so time to refactor into a JSONCallHelper class (yes, possible name refactoring pending).
An aside: I checked AdobeTed/Ted Patrick's FDOT library (here, here and here) and it seems pretty similar goal -- albeit without the header specification but it looks reasonable to retrofit for an offered commit. Will puruse this slightly before then.
Next, that my FlexUnit4 Test(async,timeout=2000) doesn't actually wait 2 seconds to see whether my method wants to do anything else. Reckon I must be misunderstanding its intent (or else those Async.proceedOnEvent() family of methods need using?!). This article's mention of proceedOnEvent() indicates the answer -- one does need to call one of the Async methods so the framework knows (this recipe also looked handy but might be out of date.) I ended up with the following kludge while still exposing the asynchronicity of the tested method:
const timer:Timer = new Timer(5000); timer.start(); Async.proceedOnEvent(this, timer, TimerEvent.TIMER_COMPLETE, 8000, function(event:TimerEvent):void{ trace("timer done"); });
Well, looks like I've overcome it for now.
No comments:
Post a Comment