GitHub versus CoreData #31
Labels
Comments
Exploring the Composition ModelWhat if instead of unifying issues and comments through a common protocol, we factored the common behavior into a talk object that would be contained by the issue, comment, or any other body of text that can be included in a timeline aka talk list. That might simplify things mightily. Not only could we avoid the awkward operation of casting LETalk conforming objects to their actual classes, we could simply throw every talk into a list and sort them according to their times or other criteria independent of where they came from. The advantage over the inheritance model is a drastic simplification and decoupling versus the current arrangement of classes and quasi-container-subclasses. The disadvantage, and indeed the driver of the current implementation, is a departure from the server-side schema, which necessitates creating our own architecture in an increasingly complex middleware layer with a growing potential for schematic incompatibilities as specifications drift. On the other hand, this does force a level of indirection that is likely to become necessary to break away from the GitHub experience and move into a more Twitter-like experience. Moreover the awkwardness we have so far encountered from the current implementation is only likely to increase. |
ElDragonRojo
added a commit
that referenced
this issue
Aug 1, 2013
… created or modified date. * For now, just check if it responds to the selector. * This causes warnings because the selector is undeclared. * Our goal is zero warnings, so we need to find a way to suppress that. * There may be an architectural solution. * Add these keys to GHManagedObject, or * Factor out main object and helper object. This is the same problem as the similarity between issues and comments. We resolved that with a protocol and a category, which has its ups and downs. We could also create a middle layer of abstract entities and classes. Refs #31
ElDragonRojo
added a commit
that referenced
this issue
Aug 1, 2013
…se case—attached to issues. In the UI, issues and comments both contain some common conceptual sub-object called a talk, which has a body. (Seeing the problem as Composition versus Inheritance, Refs #31) In the code, issues and comments are both kinds of talks, their common API unified behind the LETalk protocol. In any case, the user may be replying to the top-level issue or one of its comments, but they both result in the same thing: a new comment being added to the issue. Therefore, we have to disambiguate between whether the current talk is the issue, or the current talk is contained by the issue. For this we can introspect the actual class of the talk, and use the issue back pointer if necessary. ## Next steps 1. Create a comment and attach it to the issue. 2. Ensure this is done in a way that is compatible with the coming sync architecture. 3. Actually sync these changes. Refs #30
ElDragonRojo
added a commit
that referenced
this issue
Aug 1, 2013
## Experience 1. If you are looking at a talk that you have not changed, and you are in preview mode, the save button is a reply button. 2. Tapping the reply button creates a new comment and opens that comment in the editor. 3. Editing the comment works as expected, and is added to the conversation aka talk list. ## LEWorkViewController * Finished the reply method, which now adds the new comment to the current issue or comment’s issue, refs #30 ## GHIssue * Add a comment adding method that conveniently adds the new comment to the issue. * Add named constants for the comments key and property. ## GHComment * Add a comment factory similar to that employed by GHIssue * The difference being there is only one new comment. * This will let us explore how to deal with unsynced comments and issues, refs #31
ElDragonRojo
added a commit
that referenced
this issue
Aug 1, 2013
The narrative of the experience and its UI are starting to come together, as the tension between GItHub and Twitter begin to tear the model apart. Refs #31 There is a list of conversations, displayed by topics, containing talks by users. The structure of the project should reflect this. Unfortunately, changing the names and locations of things causes tears in the history, so we’ve postponing that, while trying on the new structure. Once the experience gels, and everything is committed, the filesystem can be changed to reflect the project structure, and it can all be folded into the master at one time.
ElDragonRojo
added a commit
that referenced
this issue
Aug 5, 2013
_Creating, editing, and deleting issue and comments._ ## GHStore Creating, edit and deleting issues and comments are accomplished via two methods: 1. The over-arching `save<Class>` methods will add, edit, or delete, according to the current state of the object passed in as an argument. 2. The `delete<Class>` methods delete canceled new objects, then call through to the appropriate `save<Class>` method if necessary. ## LETalk * Add a `topic` property to return the current issue’s title, regardless of whether the object is an issue or comment. ## GHManagedObject+LETalk * Implement `plainTitle` method to return the current title including changes. * Implement `topic` to return the current issue’s title regardless of whether the current talk is an issue or a comment. * The default behavior throws an exception and meant to be overridden by subclasses . ## GHManagedObject * Move dictionary encoding for GitHub keys out of `dictionaryWithValuesForKeys:` into its own method. ## GHComment * Expose commentID property * Override `die` method * Override `topic` method ## GHIssue * Override `styledTitle` to experiment with delivering a different title for issue than for comments. * Override `topic` method ## LETalkListController * Remove the default accessory to save space. * Set a custom disclosure accessory in an attempt to save space. ## LETalkViewController * Reload the list on `viewWillAppear:` to ensure current changes are reflected in the table view. * Enable the `CreateComment` segue. ## LEWorkViewController * Implement `save` to send the current issue or comment to the server and pop back to the previous table. * Save changes to the issue title. * Toggle save and delete on comments based on whether there is a body. * If you want to delete the comment, delete the text, and the save button becomes delete. * Deleting comments seems to work. * Toggle save and delete on issues based on whether there is a title set. * If you want to delete the issue, delete the title, and the save button becomes delete. * Deleting issues does not seem to work. I don’t know why. (Refs #40) * Ensure the correct segment is selected when edit mode is toggled. * Add a topic field for editing the current topic. * When editing an issue, as opposed to a comment, move the topic from the prompt into the topic field. * This doesn’t work well and will probably be refactored away (Refs #31) ## iPhone UI * Add some word bubbles in the table view cells. * Give the app a nice bluish color to make the bubble pop. * Adjust the layout to accommodate these changes and fix autolayout conflicts.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the reference issue for the problem of mapping the GitHub API objects into CoreData.
The text was updated successfully, but these errors were encountered: