Thanks for this helpful explanation! I'll go ahead and make a 'no data available for this date' error state, sounds much less complicated / more transparent and straight forward. Thank you for helping me understand why this is the better approach!

@cmadeo What should our placeholder content for this widget be (not the skeleton view, but the transient widget content displayed for preview purposes - on POTD for example, we use the 2019 Commons Picture of the Year)?

Sorry for the late reply, let's use https://en.wikipedia.org/wiki/Moon which was a featured article on August 28, 2007!

PR: https://github.com/wikimedia/wikipedia-ios/pull/3999

@vadim-kovalenko I'm excited seeing this move forward - thanks for your continued work on it!

This work (https://phabricator.wikimedia.org/T269312) adds a leadImage property to the API response for media list items. This property indicates whether a particular media item represents the lead image for the page (that is, it matches the rest_v1/page/mobile-html endpoint's mw:leadImage property). I've confirmed on the Staging scheme (against the mobileapps labs instance) with a few test articles that leadImage property is being returned in the responses and so far they appear to be properly indicating the lead image of the article.

Great news – as of iOS 15 beta 2, they've dramatically improved the pull to refresh experience in Mobile Safari, and as a result of that work our WKWebView pull to refresh experience has also been dramatically improved. It's no longer extremely easy to induce jittery behavior in our article view when pulling to refresh an article.

The primary goal of this spike was to discover if we could (from a technical level) leverage local user notifications to supplement our incoming push notifications in order to create separate more granular notifications (all in the case where the user receives a single push notification, but actually has many different notifications available in the remote notifications API).

See notes on widget cleanup task. To summarize, these crashes will be resolved by our eventual widget data model transition.

As a result of some of the widget clean up/explorations during iOS engineering week, we have a path towards more autonomous widgets with user configurable languages (to allow, for example, three different top read widgets of the same display size on your home screen in three different languages). Once we're able to move all our new widgets to the new independent reloading model, it should be fairly straightforward to implement multiple language support on them.

With the forthcoming Featured article widget (a result of iOS engineering week), we're dipping our toes into an alternate retrieval model for widget data. Currently, the WidgetKit refresh cycle relies on the main app and its Core Data store for the featured feed network fetch and data model population.

As of iOS 14, there's a native SwiftUI Map (MapKit), but as of iOS 15 widgets still do not support using it directly. Apple's recommendation for displaying maps in the new style widget is utilizing a MKMapSnapshotter in the main app to create an image of the map, then just displaying the image in the widget.

The in-progress work on the new Explore widget (widgets/explore branch) requires updates to the URL schemes in order to match the design intentions, so that may be a good opportunity to also resolve this work.

Preliminary work (mostly design implementation) for this widget is currently up in the widgets/explore branch of the repo.

Related: iOS 15's giving us per app dynamic font sizes. I haven't read/watched the related sessions yet, but I think it's just transparent to the app, not some separate value we have to read.

iOS 15 is adding "pull to refresh" in Safari, matching similar behavior to what we use in this article view. Chatting with a WebKit engineer, it seems our currently used method of adding a refresh control to the underlying scroll view of our web view is the right path, so we shouldn't need to update that. Currently though, iOS 15 has the same jittery behavior when pulling to refresh a page as we experience in the article view.

While my Radar for it remains open with no feedback from Apple, it appears that iOS 15 resolved this particular crash! It still occurs on iOS 14.6 though.

@cmadeo What should our placeholder content for this widget be (not the skeleton view, but the transient widget content displayed for preview purposes - on POTD for example, we use the 2019 Commons Picture of the Year)?

@cmadeo What should the error text displayed in the widget be when:

Checking in using the supported list of languages for today (e.g. https://zh.wikipedia.org/api/rest_v1/feed/featured/2021/06/03), these are the listed as supported language subdomains that are failing to return any featured article content:

There's a UIAccessibility notification that gets sent when an announcement finishes reading that may be helpful here: https://developer.apple.com/documentation/uikit/uiaccessibility/1620202-announcementdidfinishnotificatio

Clicking the affirmative button ("yes"), should open the built in review UI: https://developer.apple.com/documentation/storekit/skstorereviewcontroller

@MSantos Many thanks for the explanations.

From a technical level, it looks pretty straightforward to incorporate this information. In loadImage() on ShareViewController, we can also pull the owner from imageInfo, and use the same safety trimming on it we use elsewhere before displaying it.

The iOS component of this work has been merged: https://github.com/wikimedia/wikipedia-ios/pull/3943

PRs:

• https://github.com/wikimedia/wikipedia-ios/pull/3944
• https://github.com/wikimedia/wikipedia-ios/pull/3946

@Ondreas_novak So glad this one's resolved for you!

Additional info from user:

It happens on ipad and iphone, as well as the standard browser (safari) version on my laptop. It seems the issue is linked to my profile, not to a particular device.

In T269312#7065012, @vadim-kovalenko wrote:

@Dmantena I think if we come to solution #2 with leadImage: boolean, gallery ordering can be re-implemented to set the first image with leadImage: true. Thank you for your update, no need to upload a video, I've already tested this issue with gallery.

@MSantos Thank you for investigating this!

After exploring a few wrong directions, I think I've figured out what's up. The summary of the problem is that while in VoiceOver mode, we can use the navigational gesture (single finger left or right swipe on screen) to navigate through all the text presented in this view, but arbitrarily tapping or dragging on to individual items (to focus and announce them with via VoiceOver) doesn't work for any of the header items. It seems like some of our custom hit logic (in TalkPageHeaderView and LinkOnlyTextView) is actually preventing VoiceOver from doing its thing. That's why it seems the navigational gesture works fine, but taps/drags do not.

Just for clarity: the TopReadWidget binary name is identical for both our old-style and new home screen style Top read widgets, but it appears this crash is specifically related to the old-style UIKit Top Read widget (WMFTodayTopReadWidgetViewController).

PR for visual fix above up at: https://github.com/wikimedia/wikipedia-ios/pull/3923

The initial improvements I'm looking to make revolve around some of these visual issues: https://phabricator.wikimedia.org/T238863#6949757

I feel okay about removing the scroll indicator here, esp with the blurred overlay, I hope it will be clear to folks (we can do testing to see!) that this area is scrollable.

Hey @cmadeo - this one's in code review right now. Toni suggested I share some screenshots of it with you here to potentially save us all some cycles if something felt off.

1. Developer makes HTTP request to https://deployment with parameters of environment (production, development), notification type (silent, visible, forwarded to PI's push service), device identifier (variable length string), and topic identifier (variable length string)
2. https://deployment performs performs the message delivery either by forwarding a formed HTTP request to Apple's push servers or forwarding a formed request to the appropriate PI service (development or production) based on the original parameters

What does https://deployment refers to right now? and endpoint being served from WMCS?

This PR adds language variant support to the Top read widgets: https://github.com/wikimedia/wikipedia-ios/pull/3895

@Tsevener Cool - thanks!

https://github.com/wikimedia/wikipedia-ios/pull/3894

Moved the direct/specific variant component of this into new task (https://phabricator.wikimedia.org/T278581), moving this task back.

@Tsevener Following up on you mentioning proxying the language changes yesterday, so far it seems like the app itself makes calls with the appropriate Accept-Language header value when switching languages in app. I just want to confirm one thing: is the intent of the Accept-Language header value for requests in languages without explicit variants to use the iOS device's preferred languages?