Covers: https://phabricator.wikimedia.org/T97786 https://phabricator.wikimedia.org/T118350

Adding TSMessages pod for the banner logic. This is managed by a WMFAlertManager.

• [x] Need real assets
• [x] Fine tune the styling

Adds welcome screens

This includes:

• a container welcome VC that transitions between each welcome page
• a welcome page listing new items
• a welcome page for picking languages that allows re-ordering and deletion
• a welcome page for enabling analytics/crash reporting

For preferred language reordering and forthcoming deletion, the language classes were refactored:

• LanguagelinkController now manages OS languages and preferred languages
• An MWKLanguageFilter was extracted to handle filtering
• An MWKTitleLanguageController was extracted to handle languages for specific articles.
• The Language picker was refactored to allow the hiding of preferred languages

Other small refactors song the way.

Summary of commits:

The first updates the bundled CSS from production;

The second switches CSS loading to MW-Vagrant and pulls in the new styles about to be deployed to hide the (listen) parenthetical in IPA spans, and makes some other changes to the request params for correctness (with no current effect);

The third removes styles that are no longer needed;

The fourth removes the bundled legacy enwiki.less styles and adds support for loading the current MediaWiki:Mobile.css from ResourceLoader as mobile.site;

The fifth cleans up by switching default CSS loading back to production.

Note that the third and fourth are based on MobileApp extension patches currently awaiting review. Reviews on those in time to make this week's MediaWiki train deployment (i.e., by ~18:00 UTC Tuesday) are very welcome!

Most of this ended up being a refactor to get most of the sharing logic in the same place.

Basically all sharing logic is now in the WMFShareOptionsController (which is no longer a view controller, because it want being used as one anyways)

WMFShareOptionsController has also been refactored to no longer require a delegate.

The share funnel has also pretty much been moved inside of the share options controller - EXCEPT - there is some logging that can't be moved (it involves selection of text in the webview) - so that object is passed to the options controller on initialization.

(In case you were wondering, we can't move to using the UIAlertController - because you can't customize it to add images)

While I was in there: I moved auto layout to masonry Made the options menu fill the width of the screen I fixed the display / dismiss animation to look native Added the camera roll as an option for output (https://phabricator.wikimedia.org/T37764) Did some minor clean up of the web view controller in regards to singleton references

This pr removes all references to MWKSite and MWKTitle in favor of the new NSURL methods.

• [x] Replace all references to MWKTitle and MWKSite
• [x] Handle deserialization of Saved pages
• [x] Handle deserialization of history
• [x] Update Unit Tests
• [x] Update and verify deserialization of all former persisted classes
• [x] Rename all "domainURL" references to "siteURL"
• [x] File separate ticket to re-enable saved page fetcher tests

Out of scope for this PR:

• Any refactoring of logic that is now duplicative due to NSURLs being used for both title and site (refactoring such as this should be performed while boyscouting during normal development)
• Preserving the persisted feed data (The feed model will be completely changed during the feed refactor)

• [x] Update strings
• [x] Update images/icons
• [x] Restyle all 3 welcome screens
• [x] Ensure layout on small screens and iPads isn't explody - i.e. doesn't stretch to full width on iPads, doesn't clip top or bottom of content on 4s, etc.
• [x] Fix crashing bug on existing welcome lang picker (see https://github.com/wikimedia/wikipedia-ios/commit/1e5bb13f0d4b0c5f6ab605eafbc40d84c87c4ce7) - prob need a test case for TSG for this.
• [x] Use WMF green for switches system-wide (and use for a couple Settings icons)
• [x] Add and hook up back button from mocks at top of second 2 screens
• [x] Add "Thank you" flourish when opt-ing in to send usage reports
• [x] Auto-hide welcome screens after opt-in, per the mock video Changed the 'Send usage reports' message instead
• [x] Double-check for RTL issues (identical to UINavigationController behavior)
  • [x] iOS 9 RTL
    • [x] Push starts on left (trailing)
    • [x] Pop starts on right (leading)
    • [x] Back button pinned to right (leading)
  • [x] iOS 8 RTL
    • [x] Back button pinned to left (not flipped for RTL, mirror
• [x] DRY up a couple colors which are presently in the storyboard - move to UIColor category
• [x] Use built-in navigation bar for back button & better transitions
• [x] Enable swipe to go back
• [x] Use light status bar on first panel, dark on the rest

Note: animations (will be follow-on ticket)

iPhone 6

iPad

iPhone 4s

Note: feel free to close this PR if the method used here is shabby

• Added a background view with bottom border as a subview of presentation view
• hiding the view on landscape mode
• removing the view on completion
• changed the background view tint from white to black

Bug: https://phabricator.wikimedia.org/T117474

Phab: T119669, T119903

• [x] refactor galleries
  • [x] base gallery (RTL handling + data source property)
  • [x] article header gallery (basic data source for article images)
  • [x] modal article gallery (modal data source for article images + info)
  • [x] modal POTD gallery (modal data source for POTD images + info)
• [x] tap POTD to view in gallery
• [x] peek POTD to view in gallery
• [x] fetch "medium" POTD image w/ desc for home view
• [x] fetch "large" POTD image w/ all info for modal gallery
• [x] extra credit add older POTDs in gallery

regression tests: (see Phab tasks for dev testing notes)

What's New

Image gallery VC & data source architecture

See header comments in:

• WMFModalImageGalleryViewController: formerly known as WMFImageGalleryViewController, which is now more dependent on its data sources (i.e. no longer fetches image info).
• WMFImageGalleryDataSource: and its "big brother,"WMFModalImageGalleryDataSource are the interface through which domain-specific data can be displayed in the image gallery:
  • WMFModalArticleImageGalleryDataSource: as the name implies, provides data to the modal gallery for images in an article
  • WMFModalPOTDImageGalleryDataSource: I think you've got it by now: this one provides data for the gallery when viewing pictures of the day

Each gallery data source is created as part of one of WMFModalImageGalleryViewController's new initialization methods. Check the header for details.

Standardized image widths

Took a little time to refactor all our disparate image-width stuff into a centralized collection of categories. See UIScreen+WMFImageWidth for details.

Takeaways

• they're collected in a UIScreen category since all the view-specific resolutions are dependent on the screen's scale
• we're maxing out scaling at 2x to prevent ourselves from fetching insanely high resolution images for the home feed. For example: 3x scaling would result in 960-px thumbnails (if available) for an article preview cell in the home view :scream:
• we were previously always showing 1280px thumbnails in the gallery, it now scales from 640 to 1280 depending on screen scale. this means older devices will get lower-res gallery pics and newer devices will remain the same.
• ideally, we'd download higher resolution images on 2-3x devices when on WiFi, but that's out of scope for now. I'll file a ticket to look into this later.

Split WMFHomeSectionController protocols

As part of adding POTD to the Home view, we needed a way to handle selection of home section items which weren't related to articles. And lo, two new protocols were conceived:

• WMFArticleHomeSectionController: all the article-specific stuff from WMFHomeSectionController
• WMFGenericHomeSectionController: (open to better names) non-article stuff for home sections. only provides a "detail view controller" when one of its items are selected. might need to add specialized footer interaction methods here if we ever get around to doing a "more POTDs" list view.

Add'l boyscouting

• Removed unused gallery & gallery cell properties (most of these were added when I tried to use WMFImageGalleryViewController for all galleries, but that got way too complicated, and I forgot to remove these properties when I backed out the changes)
• DRY'd up image view placeholder logic in the cells (category already existed it, just integrated in more places and provided explicit, documented overrides where necessary)
• Fixed image gallery animations. Previously the detail overlay and higher-res images weren't animating into view, nor was the chrome cross dissolving on taps

Pushing last read article if less than 24 hours and the app was quit.

And adding new section, which means:

• New section controller
• New cell
• New Schema item
• Updating the Schema to vend the section based on the rules (show after 24 hours)

Additionally added the support for icons on the sections

:checkered_flag: Ready for review :checkered_flag:

Checklist

• [x] Render HTML natively (DTCoreText)
• [x] Custom XPath for summary
  • [x] filter out coordinates (see taj mahal snapshot reference)

- [ ] filter out IPA? - [ ] Interactions w/ native content Going to do interaction in a separate patch

Amendments

• [x] change UIColor+WMFPalette to the un-artistic UIColor+WMFStyle
• [x] remove premature @autoreleasepool optimization
• [x] remove #define WMFParagraphSelector in favor of vanilla string formatting
• [x] move "minimal content controller" into a custom attributed text cell, encapsulating all logic in one place

Using DTCoreText to render pages natively, doing a different XPath to grab section content. See Extraction section in MWKArticle for implementation details and the new WikipediaUnitTests/ReferenceImages folder for visual examples.

• [x] "Continue reading..." (tap should load the article)
• [x] "Featured article" (tap should load the article)
• [x] "Today on Wikipedia" (tap should load the article)
• [x] "Random" (tap should load the article - but should not prevent refresh from working)
• [x] "Nearby" (tap should load full Nearby list)
• [x] "Today's picture" (tap should load the picture)
• [x] Make header taps use same highlighting - (Josh said it's ok for now if the cell beneath the header highlights)
• [x] Bypass this tap handling for other header types
• [x] "Because you read..." (no longer make only the link tappable - make tapping anywhere on the "Because you read..." header load the article, the link can still be highlighted, it just won't handle taps)

Phabricator: https://phabricator.wikimedia.org/T322955

Notes

• Currently, there are sometimes sequences of consecutive newlines in the headers of talk pages, which creates large gaps in the text. This makes it difficult to read the pages
• This is fixed by cutting off consecutive newlines so that there are no more than two in a sequence

Test Steps

1. Navigate to an article (Example: Black Panther)
2. Navigate to the article talk page
3. Tap read more and view the topics
4. There should be no large gaps of multiple newlines between the text

Screenshots/Videos

Before change:

After change:

Phabricator: https://phabricator.wikimedia.org/T321066

Notes

• Currently, links with fragments (such as sections and equations) do not scroll to the fragment when opened in the app, unless that article is already open. This is fixed by adding the fragment to the web view's request before loading, which triggers the existing restoreScrollStateIfNecessary method to scroll the view to the fragment after the web view loads.
• Currently, if the user has an article open in the app and clicks on a link to a fragment in that same article, nothing happens. This is fixed by adding a statement to scroll to the fragment in this case.

Test 1 Steps: External link with fragment, different article

1. Make sure the “Juice” article is not currently open in the app
2. Paste this link into Safari: https://en.wikipedia.org/wiki/Juice#Preparation
3. Select the link and “Open in Wikipedia”
4. Should open the “Juice” article in the app and scroll to the “Preparation” section

Test 2 Steps: Internal link with fragment, same article

1. Open this article in the app: https://en.wikipedia.org/wiki/Eigenvalues_and_eigenvectors
2. Scroll to the “Algebraic multiplicity” section
3. Click the “Equation (4)” link
4. Should scroll to equation 4

Phabricator: N/A

Notes

• 👋🏻 I realized I introduced this bug when working on peek/pop. Sorry!
• Currently, if you long press on an article reference (or note), a user gets a preview of the article they're currently in, which is not intended. This PR suppresses long press preview for references (and notes).
• Additionally, when a user long presses an element that cannot be previewed (like an external URL or [now] a reference), the text they tap grows as if it can be previewed. I changed the completion handler to nil (from nilConfig), which tells iOS suppresses this behavior. Please let me know if you'd like to keep the current behavior, and I can remove this from the PR.
• Also, I renamed a variable to newArticleUrl as we use articleUrl for the current VC's article. While the compiler can handle it, I think this improves readability for humans - but feel free to request that I revert that.

Test Steps

1. Load an article.
2. Use peek/pop on a reference. It should not work.
3. Use peek/pop on an article link. It should work.

Phabricator: https://phabricator.wikimedia.org/T314809

Notes

Previously, long titled article history pages would not scroll because the navigation bar in the view didn't enable allowsUnderbarHitsFallThrough. This adds a PageHistoryCountsView to represent the existing implemented XIB, and adds the point inside override to support allowsUnderbarHitsFallThrough and allow scrolling the view when interacting with the header.

If there's a better way to handle this, I'm happy to change this PR!

Test Steps

From Phabricator:

- Go to the article: https://en.wikipedia.org/wiki/Cneoridium_dumosum_(Nuttall)_Hooker_F._Collected_March_26%2C_1960%2C_at_an_Elevation_of_about_1450_Meters_on_Cerro_Quemaz%C3%B3n%2C_15_Miles_South_of_Bah%C3%ADa_de_Los_Angeles%2C_Baja_California%2C_M%C3%A9xico%2C_Apparently_for_a_Southeastward_Range_Extension_of_Some_140_Miles within the iOS app
- Navigate to the article's history page
- Scroll down on the history page

Confirm in the case above (and any other article history page) that interacting with the navigation bar to scroll works and allows the user to see the rest of the view.

Phabricator: https://phabricator.wikimedia.org/T324862

Notes

This resolves the issue where tapping link on an unlinked term in the section editor presented the insert link view, but did not immediately start populating search results for the selected term. Now, we perform a search on appearance of the InsertLinkViewController.

Test Steps

1. Open an article and edit a section
2. Select a piece of unlinked text on the page and tap the link button in the toolbar
3. Confirm the Insert Link controller appears with the selected term in the search bar, and that a search is immediately performed to populate the results list
4. Confirm tapping a search result populates that link in the section editor