Swift/iOS viewer for photography galleries or portfolios

[SceneConfiguration] Info.plist contained no UIScene configuration dictionary (looking for configuration named "(no name)")

https://developer.apple.com/forums/thread/721912

Because date strings are converted to Date objects, and then shown as strings, check if all goes well when user is located in a different time zone than currently used for string>Date conversion.

The update function for MemberPortfolio contains a club member's roles ("Joe is treasurer of photo club HappyPixels") and status ("Joe is a former member of photo club Kodachrome").

If Joe stops being the treasurer of HappyPixels, the MemberPortfolio.isTreasurer flag should be cleared for Joe (and likely set for someone else).

But the update() function that changes these properties gets called with with parameter values corresponding to

• Joe is currently treasurer
• no info available about whether Joe is treasurer

Member table is renamed to MemberPortfolio.

This is because it represents information about a Member of a PhotoClub, but simultaneously about the image Portfolio of the Member of the PhotoClub. Because the relationships are 1:1, the information is stored in a single table. And Member and Portfolio are synonyms, thus called MemberPortfolio.

The Schema.png file used in the in-app Readme and Github's README.md is also updated to reflect the new table name.

Reproduce using:

1. Select only Aspiring members (or any category with only a few entries)
2. Temporarily remove these entries in Portfolios screen (swipe left)

Now the list of displayed members should be empty. But the text (at the bottom of the empty list of Portfolios) says this is because all settings are disabled. This is incorrect: there are settings enabled, but there is no data that matches the filter criteria. Fix logic (or text message).

Actually the code looks correct, so maybe this is just a translation to NL problem:

if fetchRequest.nsPredicate == NSPredicate.none {
        Text("""
             Warning: all member categories on the Preferences page are disabled. \
             Please enable one or more options in Preferences.
             """, comment: "Hint to the user if all of the Preference toggles are disabled.")

English version was fine. Was a misleading translation.

This crash looks like an Automatic Reference Counting issue. ARC is removing PhotoClub or Photographer objects (NSManagedObject in Core Data) that are still being referenced. This is known as "zombie objects".

Observed error messages (listed below)

• isTemporaryID seems to be CoreData internal, but is work on behalf of the PhotoClub object.
• name is probably PhotoClub.name
• givenName_ is Photographer.givenName_

Analysis

This shouldn't with structure (as there are no references with value semantics). And shouldn't happen with normal strong references to objects, but could happen with weak references that may be used internally within Core Data. In particular, this is used to break a cycle between MemberPortfolio which "points to" both a PhotoClub and to a Photographer. While PhotoClub has a computed CoreData attribute called 'members_'; and Photographer has a similar property called memberships_. To avoid this "classical" ARC risk of memory leaks, one of the references is probably weak.

But what to do about it?

• pinpoint exactly what is going on using the Zombie detection Instrument in XCode. Doesn't seem to detect this? Which is suspicious.
• remove memberships_ and members_ from the data model, hoping that the weak reference no longer exists. This means generating this info ourselves, when needed, using a query to the database. In fact, it may be possible to implement Photographer.memberships and PhotoClub.members as custom computed properties. Core Data however doesn't seem to like relationships without inverse relationships.
• carefully add a temporary copy of PhotoClub and Membership to some scope, thus leaving the objects longer. There is actually a keyword for that.
• put more permanent references to PhotoClub and Membership objects somewhere (at top level). Essentially trying to deliberately create a memory leak. This isn't too bad if you have say 20 PhotoClub objects with 20 members each: 20 + 400 objects.

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[PhotoClub isTemporaryID]: unrecognized selector sent to instance 0x2819cdea0' *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSCoreDataTaggedObjectID name]: unrecognized selector sent to instance 0x93b50e9d26960d3b' *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSCoreDataTaggedObjectID givenName]: unrecognized selector sent to instance 0xb37907d875249736'

https://developer.apple.com/documentation/xcode/investigating-crashes-for-zombie-objects https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

Computed property .filteredPhotographerFetchResult is calculated 3 times (and in 4 places) in filteredPhotographerFetchResult.body

This is normally not a big deal, but is an issue if we trigger network requests each time filteredPhotographerFetchResult is computed.

Currently, the state is lost after then app (really) closes. This is not expected behavior for an - admittedly very minor - user preference setting.

Note that lock state is currently configurable per PhotoClub, and that the set of supported Photo Clubs should ultimately be determined at runtime (=dynamcally).

Alternative designs:

• store state in UserDefaults as a dictionary. The dictionary can grow.
• store state in UserDefaults as a Boolean. Means all locks open/close together. User won’t mind/notice.
• store state using existing Core Data database. There is already a PhotoClubs table, so just requires one extra property, and the ability to get is (no effort) and set it (some code).

Not sure which to choose yet.

The Portfolio of photographer “John Doe” in the context of photo club “Club Foobar” is currently entitled “John Doe”. Change this to “John Doe (Club Foobar)” because that’s more accurate.

Arguably this could be done only if the database contains more than one photo club, but as soon as there are multiple photo clubs, this becomes important given the definition (see README.me) of portfolio.

StoreKit allows you to bug users up to three times per year for a rating or review (if they haven't already provided one?). So this is mainly about delaying calls to requestReview() until the app estimates it has been used enough that the user might be willing to provide feedback.

So this is about maintaining counters (in UserDefaults) that keep track of in-session or cross-session statistics. Current idea is to collect experience 'points' whenever the user activates a feature. And to trigger requestReview() at say multiples of 100 points. Features that might be monitored (possibly with weight factors):

• accessing individual screens
  • Animation (= launching app from scratch)
  • Preference
  • Readme
  • Who's Who
  • Photo Clubs
  • viewing Portfolio (there are currently about 20)
• using Search feature
• pulldown-to-refresh
• changing the lock setting on a map
• viewing the end of the Readme

https://www.youtube.com/watch?v=_oTPT3gFUms