iOS SDK development without drop in UI

[nashr]

I just had a discussion with a developer who has never done mobile development, which became a little heated. (Unfortunately, it was my client, so I think our relationship is now breaking down because of it...).

Anyway, we were discussing the SDK I am building for him, and we have come to a feature that demands the presentation of a UIWebView, to handle a crappy html form.

For the sake of this thread and without going into any detail about why, please assume that presenting a web view is an essential requirement, and jumping out of the App and going to Safari is not an option.

The client asked that we show a full screen, modal web view from within the SDK. I suggested that we implement a protocol which would delegate the presentation of the web view back to the implementing developer, who would then present it from where he/she likes.

Bear in mind that any events that occur in the web view need to be monitored and handled by the SDK, i.e. certain requests need to be halted / inspected, before they start etc (but all of this would be implemented by the SDK anyway).

What are you thoughts on presenting UI from an SDK over having the control yourself, in terms of good SDK design and implementation complexity ?

Specs:
iOS 7+.
All devices.

 

[WordMasterRice]

Lets start by saying that I think your post is a bit over the head of this forum.

Personally I would do it both ways. I think that if it is a requirement of the SDK then I would have the SDK have the ability to do it, but also with the ability to override certain functions so that you can handle the presentation yourself (as the developer using the SDK). My view on these sorts of things is that if it is a requirement for the SDK to work then the SDK should have the ability to take care of it to the extent possible, while also allowing the developer to override the default implementation if possible as well.

 

[AndyK]

I never argue with my clients that much even though most of the time they want things done the 'stupid' way. Do the work, get paid, move on & just don't work with them again once the job is completed. There are plenty more fish in the sea.

More on topic, as said above I would also do it both ways to then open up options at a later stage in the development process.

 

[firewood]

Cynically, if you are paid by time and materials, it may take longer to do it the "stupid" way (plus debug, maintain, and fix it later). Plus you will gather actual data and evidence on how not to do it to help educate later clients/students.

 

[PhoneyDeveloper]

Well, you can look at these apple examples: MPMoviePlayerViewController, MFMailComposeViewController. You can consider UIKit and MPKit and MFKit as SDKs and they show these complete UIs to accomplish important tasks. There is no rule that says an SDK doesn't provide UI.

Alternatively, if you like you can provide an example in your demo app where the app provides the web view and your SDK provides the @protocol, and things all work. If the customer is provided complete working code that does what he wants he may be happy enough with that.

Is this for an oath2 login screen? That can certainly be done either way. Google's GData SDK did that by exposing a view controller that managed the login. Was a little awkward but worked fine.

 

[ArtOfWarfare]

Cynically, if you are paid by time and materials, it may take longer to do it the "stupid" way (plus debug, maintain, and fix it later). Plus you will gather actual data and evidence on how not to do it to help educate later clients/students.

Yeah, but then you have a crappy application in your portfolio. That or a gap in your portfolio, where potential clients want to know what you were doing for that time period (have you been keeping up with the latest developments? If we hire you, are you going to make us something that has a UI more appropriate for the iPhone 3GS / iOS 3, rather than iPhone 6 + / iOS 8?)