-
-
Notifications
You must be signed in to change notification settings - Fork 516
📙 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
Comments
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 |
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.
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? |
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 |
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. |
The next thing I found is this:
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. |
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. |
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) |
This is weird. Just doesnt seem like it belongs in a doc about Parse IMO. Thats just general programming best practices.
|
I just noticed this example in the Retrieve section of Local Data Store `PFQuery *query = [PFQuery queryWithClassName:@"GameScore"]; // task.result will be your game score 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 |
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? |
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? |
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. |
Created a pull request here. When I get to ParseUI documentation update I will make an update here. |
@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? |
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. |
Perfect. Off to knock this out. Too bad we dont have that API documentation. That would make updates super easy. |
Guess what I did! |
The iOS Parse UI docs are in need of updates. Generally consisting of simple syntax changes and fixes.
I have got the ball rolling:
PFSignUpViewController
andPFLogInViewController
PFTableViewCell
PFQueryTableViewController
The text was updated successfully, but these errors were encountered: