Added automatic PFObject subclass registration. #5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
2 times, most recently
from
f304933 to
2f81142
Compare
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
from
2f81142 to
cb56a6a
Compare
|
Fixed OSX unit tests, was an issue related to symlink resolution only happening partially. |
|
+1 |
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
2 times, most recently
from
3fcdc47 to
af28af7
Compare
|
Rebased. |
|
Hey guys, just letting everyone here know that we are tracking this to be merged in and release with version 1.8.4 of the SDK. |
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
from
af28af7 to
fef157a
Compare
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
from
fef157a to
b4e5adf
Compare
|
Needs rebasing + tests to pass, back in your queue :) |
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
from
78160ac to
4a46a19
Compare
richardjrossiii
added
GH Review: review-needed
and removed
GH Review: needs-revision
labels
|
@richardjrossiii updated the pull request. |
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
from
4a46a19 to
36f34bd
Compare
|
+1 |
This will scan all loaded code bundles for classes which inherit from `PFObject`, and register them upon Parse initialization. Still have opt-in support for manual-only registration, though it shouldn't be necessary for most cases.
richardjrossiii
force-pushed
the
richardross.subclassing.autoreg
branch
from
36f34bd to
11111a0
Compare
|
Rebased. |
|
Due to issues with travis CI, we've moved this issue to #967, for any who are following this PR still. |
This was referenced Aug 22, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a breaking change.
What's new
Currently, every
PFObjectsubclass must be registered with parse before it is used. This can create some hard-to-track-down issues if you're not aware of this, and it isn't exactly the cleanest API.In Objective-C/Swift, it is relatively easy to search at run-time for subclasses of
PFObject, and have them register with parse automatically (in the case of dynamic libraries, even as soon as they load from their bundles).This should prevent needing your app delegate to have lots of extra lines of code related to simply registering all of your
PFObjectsubclasses.What's breaking
PFObject, which implementedPFSubclassing, but intentionally did not register it with parse (or only conditionally registered it with parse), then you may run into errors printed to the console and a crash on start. The error message in the console should be concrete enough to help you track down the issue.PFSubclassingSkipAutomaticRegistration.[MySubclass registerSubclass]inAppDelegateor similar, andMySubclassis located in a not-yet loaded dynamic library/framework, then until you manually load that library (by using a class/method/function inside it), your subclass will not be registered.dlopen& friends, if your application needs such a feature.These breaking changes shouldn't effect 99% of our users, and workarounds should be fairly simple for those it will break for.