Skip to content

📙 Updates needed to iOS Parse UI docs #596

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
TomWFox opened this issue Mar 12, 2019 · 17 comments
Open

📙 Updates needed to iOS Parse UI docs #596

TomWFox opened this issue Mar 12, 2019 · 17 comments

Comments

@TomWFox
Copy link
Contributor

TomWFox commented Mar 12, 2019

The iOS Parse UI docs are in need of updates. Generally consisting of simple syntax changes and fixes.

I have got the ball rolling:

@TomWFox
Copy link
Contributor Author

TomWFox commented Mar 13, 2019

The link to the API Reference for PFSignUpView currently 404s - I can seem to find the API Reference for Parse UI.

This is the current link: http://parseplatform.org/Parse-SDK-iOS-OSX/api/Classes/PFSignUpView.html

@TomWFox TomWFox pinned this issue Mar 13, 2019
@TomWFox TomWFox changed the title Updates needed to iOS Parse UI docs 📙 Updates needed to iOS Parse UI docs Mar 18, 2019
@noobs2ninjas
Copy link
Member

I'm going over this now and I had a few questions. Not wanting to make that pull request super long I thought I'd ask them here. Heres the first one I found that I think may needed updating.

The Local Datastore

... To enable the datastore, add libsqlite3.dylib

I dont think this is really relevant anymore is it? Its been years since I've had to manually add libraries. Also, just curious, does local data store still use sqlite 3?

@TomWFox
Copy link
Contributor Author

TomWFox commented Jul 24, 2019

Not sure, I believe it does still use sqlite3 - if you use the iOS simulator you can go into the file system and find the sqlite file

@noobs2ninjas
Copy link
Member

noobs2ninjas commented Jul 24, 2019

Gotcha!

I figured the library is still being used. However, I don't think users have to manually add it as instructed in the document since Xcode 7 or 8. Which means the minimum iOS version Parse supports requires an Xcode version that automatically compiles included libraries found in the source code.

@noobs2ninjas
Copy link
Member

noobs2ninjas commented Jul 24, 2019

The next thing I found is this:

If you need to refresh an object you already have with the latest data that is in the Parse Cloud, you can call the fetch method like so:

myObject.fetch()

Not only would this not compile because in swift it requires a try but all other platforms examples always show preference to "fetchInBackgroundWithBlock" type functions as asynchronous tasks are generally preferred when doing potentially long-running tasks as opposed to by this example would be blocking on the main thread.

Agreed?

If so I think I can handle the rest. Just want to make sure that consistency between documentation is preferred.

@TomWFox
Copy link
Contributor Author

TomWFox commented Jul 24, 2019

Ok, I’m not sure on the automatic compiling, have you tested it?

Changing to fetchinbackground seems logical, and yes consistency between docs is definitely preferred.

@noobs2ninjas
Copy link
Member

I just downloaded the Parse source and it has zero linked frameworks and only Bolts is mentioned on target dependencies to build the Parse-iOS target itself. Ooo I also just found that the dylib at the end means its a dynamic library which Xcode will detect and build itself on all Xcode versions supporting our minimum target (iOS 8)

@noobs2ninjas
Copy link
Member

This is weird. Just doesnt seem like it belongs in a doc about Parse IMO. Thats just general programming best practices.

We recommend that you NameYourClassesLikeThis and nameYourKeysLikeThis, just to keep your code looking pretty.

@noobs2ninjas
Copy link
Member

noobs2ninjas commented Jul 25, 2019

I just noticed this example in the Retrieve section of Local Data Store

`PFQuery *query = [PFQuery queryWithClassName:@"GameScore"];
[query fromLocalDatastore];
[[query getObjectInBackgroundWithId:@"xWMyZ4YE"] continueWithBlock:^id(BFTask *task) {
if (task.error) {
// Something went wrong.
return task;
}

// task.result will be your game score
return task;
}];`

Might be just my opinion but in order to avoid confusion I'm thinking we should stick to examples that use PFObjectResultBlock and other PFQuery response typealias' as we don't cover Bolts(BFTask) anywhere in this documentation and this example may be confusing.

Edit: I also just noticed the unnecessary return task lol

@noobs2ninjas
Copy link
Member

One more thing. Probably should have noticed this sooner. Seems like there is a lot of redundant documentation in Objects and Local Data Store. Thoughts?

@TomWFox
Copy link
Contributor Author

TomWFox commented Jul 25, 2019

I think removing BFTask in favour of PFObjectResultBlock is a good idea. In time it would be nice to move away from Bolts completely as it’s not very well maintained anymore.

Not certain on the redundancy, my instinct would be to keep it because we don’t want the guide to be to confusing/annoying if people come at it from a ‘localdatastore First’ approach.

Also I didn’t notice at first but this issue is about ParseUI not localdatastore so it would be good to continue this elsewhere, perhaps you could open a pr?

@noobs2ninjas
Copy link
Member

We can do that. What I've been doing for the last couple days is actually going through section by section and making updates to ALL the iOS documentation. I guess an open pull request would be the best place to cover all potential changes.

@noobs2ninjas
Copy link
Member

Created a pull request here. When I get to ParseUI documentation update I will make an update here.

@noobs2ninjas
Copy link
Member

noobs2ninjas commented Jul 26, 2019

@TomWFox since we where on the subject in that other thread I decided to work on this today. Wanted your opinion. "User Interface" as well as the way Twitter and Facebook is presented within the documentation doesnt give any hint whatsoever that this is a separate module. In fact if someone browsed "User Interfaces" intro (which we are all guilty of skipping doc intros) they might never tell it wasnt baked in. Also, everyone who uses parse for any length of time refers to it by its repository name. Should we just leave it alone or try to find a way to better represent it?

@TomWFox
Copy link
Contributor Author

TomWFox commented Jul 26, 2019

I don't think there is much we can do if people misunderstand something because they skipped over the explanation - the intro section does explain how to add ParseUI to your project. We could rename the section to ParseUI, I'm not that fused either way.

As for the Facebook & Twitter sections it definitely could be made more clear that they are submodules.

@noobs2ninjas
Copy link
Member

Perfect. Off to knock this out. Too bad we dont have that API documentation. That would make updates super easy.

@noobs2ninjas
Copy link
Member

Guess what I did!

parse-community/Parse-SDK-iOS-OSX#1435

@TomWFox TomWFox unpinned this issue Jul 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants