Page MenuHomePhabricator

Widget clean-up
Open, MediumPublic

Description

Umbrella task for widget issues.

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
Resolvedcmadeo
ResolvedJMinor
ResolvedJMinor
ResolvedJMinor
ResolvedJMinor
ResolvedJMinor
OpenNone
DeclinedNone
ResolvedJMinor
ResolvedJMinor
ResolvedNone
ResolvedDmantena
OpenNone
Opencmadeo
OpenNone
OpenSpikeNone
OpenNone
DeclinedBUG REPORTNone
ResolvedDmantena
OpenNone
DeclinedNone
OpenNone
ResolvedJMinor
OpenNone

Event Timeline

LGoto triaged this task as Medium priority.Nov 30 2020, 7:46 PM
LGoto moved this task from Needs Triage to Product Backlog on the Wikipedia-iOS-App-Backlog board.
Dmantena added a subscriber: Dmantena.

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.

Core Data (specifically SQL backed instances) is notoriously bad news in shared app group usage, and continues to cause crashes in our (old and new) Widget extensions. This has lead to some involved Core Data mutual exclusion code that unfortunately still doesn't completely resolve our crashes.

With the new iOS 14+ Featured article widget, we're testing a different approach (which we'll apply to the existing widgets if it performs well in practice): the widget extension itself will now have a little network stack of its own to directly fetch featured content. It also has a shared WidgetCache that can be used to transit data (like the user's primary language, or cached feed results) between the app itself and the extensions via a shared App Group.

This allows us to remove the extension's direct shared Core Data usage (and along with that, resolves all our outstanding Core Data related widget crashes), as well as provides a path to more autonomous widgets (with their own independent user selectable language, for example).

It does come at a cost though, in that there’s some minor duplication of data models and network fetch, but I believe these costs are worth the path to resolving our biggest outstanding crashes while supporting our ideal future of more independently user configurable home screen widgets. A stretch goal I was unable to finish during my time working on this was to have content fetched in the main app cache itself to be used in the widget, but this is straightforward enough to implement as a future improvement.

The key point from my investigation of all this during engineering week is that I believe we have a viable model and strategy for less crash prone, more independent widgets.

Thanks @Dmantena. That all sounds wonderful. And thanks for the great write-up.

Dmantena removed a project: ios-app-v7.0.1.

Two big clean up tasks remain:

  • Convert our remaining Core Data based widgets over to use the new self-sustaining data retrieval pattern that Feature Article uses. There seems to have been in increase in Core Data related SQLite file lock issues that manifest in multiple widgets of the same type on the home screen at the same time sometimes not working.
  • Await feedback from Apple Radar about handling images in widgets. There seems to be new enforcement (but no documentation yet) in iOS 16 of image dimensions having maximum sizes in widgets, where exceeding that maximum size prevents a widget from archiving/rendering. We did some preventative work here that resizes POTD images to 1000x1000 max before displaying, but we need to revisit this if we get guidance or documentation from Apple.