iOS 14 User logout does not erase session

[pmmlo]

Hi All - Wanted to check if I am having an implementation issue. I have tried calling logout both synchronously and asynchronously. No trouble removing the keychain object, but the session object in database persists.

Anybody having this issue in iOS 14?

[cbaker6]

By database do you mean still exists on the Parse server?

[pmmlo]

By database do you mean still exists on the Parse server?

Yup. When I login again, the session objectId is changed. I am not familiar enough with parse-server and Parse-Swift, so I am not sure if this is a failure in parse-server promise/callback or Parse-Swift not issuing API call.

[cbaker6]

Thanks for filing the issue! I think this is a bug in the SDK. I believe I know where the problem is.

[pmmlo]

Thanks for filing the issue! I think this is a bug in the SDK. I believe I know where the problem is.

Got it! Thanks @cbaker6. Your PRs are always on point. Love the rotating keys in parse-server.

[cbaker6]

Your PRs are always on point. Love the rotating keys in parse-server.

appreciate you 🙏🏾

[pmmlo]

@cbaker6 Thanks for the quick fix. Would have taken me a long time to figure out the updated API endpoint. Cheers!

[cbaker6]

No problem @pmmlo thanks for reporting! How do you like using the framework so far (pros/cons)? Also, are you coming from the objective-c iOS SDK? If so, any challenges, things you like better/worse?

Of course, let us know if you find any other issues and if you find something you want to tackle, open a PR and we can help.

[pmmlo]

I actually haven't used Parse+Objective-C SDK since the pre-acquisition days and the initial transition to an open source project. I believe there wasn't an open source SDK at that time, so I wrote my own wrapper around the web API. So, I can't speak much to the comparison, but skimming through both SDKs, they look like a nearly direct port.

Overall, I think Parse+Open Source is excellent. I mostly use SwiftUI with the changing times, unless I need lower-level.

These are just initial thoughts from my short use.
Pros:

• SPM (what made me use Parse-Swift over Parse-SDK-iOS)
• Plans for integrated Livequery
• Very straightforward open source contribution.

Cons:

• No Livequery.

[cbaker6]

The public parts of the framework are made to look a little similar to the objective-c one, but they are only minor pieces that have been ported (Keychain and FileManager come to mind). Hopefully the similarity of the public parts makes it easier to use. Under the hood, Parse-Swift is a lot different from it’s counterpart.

[cbaker6]

Opening this back up. The linked PR fixing the bug will close it once it’s merged

[pmmlo]

@cbaker6 I had a little time to dig into Parse-Swift's query syntax. I think the QueryConstraint encoder methods are powerful, more explicit, manageable and extensible.

On initial thought, I think QueryConstraint methods are overall better than passing arguments. It's been a number of years, but I recall constraints being passed as arguments. This really made it difficult to extend complex compound queries and arguably, readability suffered.

This choice of making QueryConstraint methods wrap encoders is definitely more explicit and seems to be very extensible as new cases arise. I think one of the downsides of this new conceptual choice is a loss of parity with the other Parse SDKs, so the associated challenges have to be balanced.

I did have one question: do you think we should potentially create a public init for the QueryConstraint struct, so end users can wrap their own methods around the encoder rather than having to wrap the methods? Then we could call something like this:

let query = GameScore.query(QueryConstraint(key: "score", value: 0, comparator: Comparator.greatherThanOrEqualTo))

query.find(callbackQueue: .main) { results in
    switch results {
    case .success(let scores):
        if scores.count >= 1 {
            scores.forEach { score in
                print("\(score)")
            }
        }
    case .failure(let error):
        print("Error querying: \(error)")
    }
}

Just a thought to give developers another syntax option, and allow them to write their own methods that directly wrap the encoder, as needed (rather than contributors writing all permutations).

I may end up thinking this is a dumb idea later but wanted to share while I'm working with Parse Swift.

Not sure if you wrote it, but very well-written IMO.

[cbaker6]

Thanks looking and taking advantage of the framework! Flo started the project and left a strong foundation. My goal has been to stick with (as much as possible) his suggestions in this comment #3 (comment)

Some relevant points he made are:

The guidelines are quite simple, I want to make the SDK as less intrusive as possible, as you may have noticed, pretty much every functionality is coded as protocols.

Backwards compatibility/in-place replacement is not a goal, this is a new SDK with a new philosophy.

Of course, this relieves this SDK of the restrictions of the other SDKs, but introduces a learning curve for experienced parse devs.

As you’ve mentioned, Query works differently. It looks like you already know to use them, but I’ll leave some examples for those who find this later

Parse-Swift/ParseSwift.playground/Pages/7 - GeoPoint.xcplaygroundpage/Contents.swift

Lines 59 to 76 in 3f1c897

	let pointToFind = ParseGeoPoint(latitude: 40.0, longitude: -30.0)
	var constraints = [QueryConstraint]()
	constraints.append(near(key: "location", geoPoint: pointToFind))
	let query = GameScore.query(constraints)
	query.find { results in
	switch results {
	case .success(let scores):
	assert(scores.count >= 1)
	scores.forEach { (score) in
	print("Someone with objectId \"\(score.objectId!)\" has a score of \"\(score.score)\" near me")
	}
	case .failure(let error):
	assertionFailure("Error querying: \(error)")
	}
	}

Or like this:

Parse-Swift/ParseSwift.playground/Pages/7 - GeoPoint.xcplaygroundpage/Contents.swift

Lines 118 to 133 in 3f1c897

	var query3 = GameScore.query("score" > 50, doesNotExist(key: "location"))
	query3.find { results in
	switch results {
	case .success(let scores):
	assert(scores.count >= 1)
	scores.forEach { (score) in
	print("""
	Someone has a score of \"\(score.score)\" with no geopoint \(String(describing: score.location))
	""")
	}
	case .failure(let error):
	assertionFailure("Error querying: \(error)")
	}
	}

To your question:

I did have one question: do you think we should potentially create a public init for the QueryConstraint struct, so end users can wrap their own methods around the encoder rather than having to wrap the methods?

I’m not sure, but maybe I don’t understand the usecases for it. How do you envision this making it easier?