+100 on using WKWebView over UIWebView. Apple, unlike Oracle and Sun,
are serious about deprecation and removal.
My 2 cents:
* when the majority of developers are learning most about a new
platform, we should hesitate to wrap new-to-us concepts in badly
implemented not-new-to-us-concepts. Fighting Cocoa to use Java
metaphors, in my experience, is a Fool's Errand.
* a complex object with lots of state/lifecycle should probably live
with a helper/manager object. This doesn't mean hiding WKWebView -- if
you need the webview, you always get it from the helper. If you're just
passing it around, then pass around the helper. We can
encapsulate/abstractions later if we still feel the need (yay automated
refactoring).
* wiring is always difficult to reason about and review. KVO is no
different. Separating wiring from the code it wires up continues to be
the best approach here. Utility wiring methods that respects lifecycles
and avoids magic strings will give us some flexibility and robustness
here. Reviews will help reduce the places we abuse the wiring -- ideally
wiring will happen in only a handful of places.
I like Wes' single responsibility objects, but as views (API, not
UIView) observing a raw WKWebView, not responsible for holding or
maintaining it.
-- James
On 12/11/14, 9:10 PM, Mark Finkle wrote:
A few thoughts:
1. I agree with others that we should embrace WKWebView. I have
learned to avoid premature abstractions. Unless you have a use for the
abstraction, it ends up just cluttering up the code until you get
around to removing it.
2. I think Notifications and KVO each has it's strengths and
weaknesses. My initial thoughts are that KVO seems nice for an outer
object to "watch" an aggregated (compostion) object: Like Browser
holding a WKWebView as a member. I guess I am more comfortable with
well defined delegates, protocols or notifications for "cross-object"
communication. If we decide to start with KVO, I think we should use
it sparingly and explicitly. Let's avoid an explosion of KVO hookups
and lose control over the code flow.
3. I agree with Wes in that we should create some "single
responsibility" objects and not allow code duplication to creep into
the code. Wes' examples of Browser/Tab management are good ones.
Objects should not need to recreate how to determine the selected tab.
We also don't want lots of objects watching via KVO just to cache the
selected tab for use when a situation arises.
Finkle
------------------------------------------------------------------------
There was a discussion yesterday on IRC about abstracting/hiding
WKWebView. I would like to make a counter argument here and
suggest we embrace the the WKWebView APIs fully and not try to
hide its existence.
Currently we have wrapped WKWebView in a Browser object. The
Browser has functions like canGoBack() and goBack(). I think this
is redundant because these map 1:1 to the WKWebView.
This adds a layer of complexity that we don't need. Instead I
would like to be able to freely access the WKWebView and for
example use Key-Value Observing to update user interface elements
(and internal logic) when the WKWebView's state has changed.
A good example of the power of directly talking to the WKWebView
combined with KVO is this:
https://gist.github.com/st3fan/df6e470f177044a41436#file-gistfile1-swift-L123
Here we have a LocationTextField that only needs to know what
WKWebView it is currently connected to. It then starts observing
for URL changes and security changes and updates its UI
accordingly. The URL is now always up to date and when the page
has secure content, the location field turns green. Look how
little code this is. This is the Cocoa way of doing things. If we
abstract away the WKWebView then we are basically going to
reinvent all of this by introducing delegates and extra
infrastructure code to do what the framework is already giving us.
The same mechanism can be used for progress tracking, keeping
back/forward button state correct, showing a title, acting on page
loads and a bunch more things.
I think we should realize that WKWebView is the way forward on
iOS. UIWebView will likely be deprecated by iOS9 (which is summer
next year) and Gecko will never happen on this platform because
the App Store forbids it. So lets use WKWebView as a first class
object and take advantage of the things it gives us.
What do you think?
S.
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
