Another way to think about it: It would be awesome if, as a customer used a code coverage tool to test their app, that the code coverage of the framework code in their app reached 100% as the customer's code coverage reached 100%. Such a thing is generally never going to happen for regular Flex apps.
-Alex On 4/9/17, 11:14 PM, "Alex Harui" <aha...@adobe.com> wrote: >At the highest level, the reason for beads and PAYG is not just for SWF >code, it is for JS code as well. And the net result should be that code >you didn't in your app, isn't in your app. Lots of people will need CORS >support, but lots of people won't. Now we could go overboard putting >every method in its own bead, but that won't help the folks who aren't >using some feature as the overhead would overwhelm the advantages of not >carrying around the code of a feature that isn't used. So when you break >stuff out into a bead, we want the net code size and performance for >someone not using the bead to be the same or better. > >Harbs is right that this is a completely different way of thinking about >code than for the regular Flex SDK. The philosophy of "it's only a little >bit of extra code" is why the regular Flex SDK's UIComponent is 13,000 >lines long. And why I had several unhappy customers bring their Flex app >to me looking to save size and performance and I had to tell them that the >cost of refactoring UIComponent was too high and they were out of luck. > >It is certainly worth revisiting the code we've written to see if other >stuff can be pulled out into beads, so thanks for reviewing HTTPService. >It is one of the early classes and probably needs a review. Given the >above, my responses are inline below. > >On 4/9/17, 7:14 AM, "Justin Mclean" <jus...@classsoftware.com> wrote: > >>Hi, >> >>> Therefore code to deal with authentication should not be in the base >>>component. >> >>So in that case should the code dealing with HTTPs headers should be >>removed? > >Possibly. As long as the implementation for folks not using headers would >be smaller/faster. > >> >>I can see the class is also dealing with timeouts should that also be >>removed and placed in a bead? > >Possibly, but I claim that nobody should go into production without >supporting timeouts, so I would leave that baked in. > >> >>The class is also missing JS implementations of addBead, getBeadByType >>and removeBead so it currently doesn’t support beads on the JS side. I >>assume we will need to add JS implementations of those methods? > >Yes, if they are actually missing. It looks like HTTPService is an >Istrand, so I'm surprised about that. > >> >>The method send deals with AIR only HTTP status events, that seems like >>it should not be there at all? Why isn’t that a bead? > >Again, if you can find a way to refactor that out without making the >HTTPService bigger/slower, then great. > >> >>It only has SWF version of error handlers to deal with various AS errors >>surely that also should also be a bead? > >Like Timeout, I claim that nobody should go into production without >handling errors. So probably, the JS errors need to be handled right in >HTTPService or HTTPServiceBase. Maybe there should be a common set of >events generated. > >Thanks, >-Alex >
