Deployment Target & AFNetworking 2.0 about ohhttpstubs HOT 7 CLOSED

Yep I saw the mess that @mattt did with using __IPHONE_OS_VERSION_MIN_REQUIRED (Deployment Target) instead of using __IPHONE_OS_VERSION_MAX_ALLOWED (Base SDK), and this choice of his really annoys me.

See also comments on #34.

I really don't like bumping the Deployment Target of OHHTTPStubs to iOS7 just so that the Unit Tests that uses AFNetworking can compile, because not everyone uses AFNetworking 2.0 (And because of this poor choice of design by mattt of forcing us to have a Deployment Target iOS7+ for all apps that want using AFN2, I'm considering totally dropping the use of AFN2 in my projects, I really can afford dropping support for iOS6 in my apps now).

I really want OHHTTPStubs to still be able to work with users running iOS5 and iOS6, so forcing a Deployment Target to be iOS7+ is out of the question, contrary to what @mattt did with AFN2. Instead, I am considering removing the Unit Tests that use AFN2 completely, and the AFN submodule (and just keep my own Unit Tests with NSURLSession and NSURLConnection and all). Or maybe keep my AFN submodule used for AFN Unit Tests to point to AFN 1.x. Or maybe simply wait for Travis-CI to migrate its VM to Xcode5 which should be quite soon.

from ohhttpstubs.

AFN2 can be used with 6.0+ deployment target, only NSURLSession-related part requires 7.0.

But this will require using CocoaPods instead of submodules.

from ohhttpstubs.

Yep, but I do not want to force this dependency just for my Unit Tests. Because again, I don't have a dependency between OHHTTPStubs and AFNetworking, it can totally be used with OR without AFN.
Adding a dependency to AFN2 in the podspec just for my Unit Tests to run, even if users of my lib don't use AFN, seems totally nonsense.

I may revert my submodule pointing to AFN and try to use a Podfile instead, with no pod for the main (lib) target and "AFNetworking", "~> 2.0" for the target :Tests, will give it a try some day soon. But the more I think about it the more I realize I may drop all the Unit Tests related to AFN itself (as long as my coverage remains the same…)

from ohhttpstubs.

I agree with you, closing 👍

from ohhttpstubs.

AFNetworking is in the right way to solve this see AFNetworking/AFNetworking#1412
Still some conversions from MIN_REQUIRED to MAX_ALLOWED required in his code, but hopefully it will be fixed soon

from ohhttpstubs.

That's great to know @AliSoftware

from ohhttpstubs.

My submodule now points to my own AFN2 fork — which fixes the problem with AFN2 conditional compilation issues — so Travis-CI is back to green and passes happily now 👍

Waiting for my PR AFNetworking/AFNetworking#1486 to be merged (to then switch back to the official repo and remove my fork).

from ohhttpstubs.