-
Notifications
You must be signed in to change notification settings - Fork 19
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
Implement JSONWriter to better encapsulate writing JSON content to file. #10
Conversation
Changes: - Upgrade project to Swift 3.1. - Embed Swift standard libraries as needed.
Create JSONDataWriter which will validate JSON before writing it to the file. And use it in modules for JSON writing instead of CLUDataWriter. New classes: - JSONWriter: Writes JSON content to file. - JSONWriterError: Defines error related to writing JSON content to file.
Use JSONDataWriter instead of CLUDataWriter to write JSON content to file.
Make ClueExampleApp and ClueSwiftExampleApp shared schemes.
Changes: - Update append to return a Bool value. - Better error handling. - Add new line after each JSON entry.
@Geek-1001 It look like Travis CI is configured to work with Xcode 8.2: I started working with Xcode 8.3.2, but I can downgrade if needed. Or we could think about upgrading the CI. Whichever you think is better. |
Changes: - JSONWriter append return written bytes count as Int. - Update unit tests.
Hi @andrea-prearo I have some comments regarding particular commits, please check them out. (I'll leave them in 10 minutes or so) Also regarding CI: |
Thanks @Geek-1001! I am using Travis CI for a 100% Swift project without issues. I haven't update it to Xcode 8.3.2 yet, though. I will give it a try sometime this week. |
Hi @andrea-prearo
I'm sure now this was caused by "Xcode 8.2" in our build script. Since you've specified Swift 3.1 in the project and Xcode 8.2 doesn't have it according to Swift releases page So to fix this issue you just need to update osx_image: xcode8.3 and OS version in the build script to OS=10.3 Travis: available SDKs for Xcode 8.3 script:
- xcodebuild test -project Clue.xcodeproj -scheme ClueTests -destination "platform=iOS Simulator,name=iPhone 7,OS=10.3" CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO ONLY_ACTIVE_ARCH=NO I've tested this script locally and everything was fine. |
Changes: - Update source file header comments.
Changes: - Update Travis CI to Xcode 8.3. - Update script to start iOS10.3 simulator.
@Geek-1001 Thanks for the detailed info on updating Travis CI! |
Hi @andrea-prearo Thanks ahead! |
Hi @Geek-1001, GitHub is not showing me your notes. It looks like this PR has only 6 comments (7 with this one). Could you please post them again? Feel free to merge this PR. I will address any feedback you may have and create a new PR for that. Thanks! |
|
||
import Foundation | ||
|
||
public class JSONWriter: NSObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw that you removed CLUDataWriter
in the next commit so maybe my comment is already irrelevant, but what do you think about the following case:
What if we can subclass JSONWriter
from CLUDataWriter
This will leave an ability for some modules to write some raw data (just a string, for instance) into the file if needed and JSONWriter
would be just a layer on top of DataWriter
. That's mean we can migrate CLUDataWriter
> DataWriter
to Swift as well. Also, this will allows us to encapsulate all stream related operations into the DataWriter
so JSONWriter
would deal only with high-level writing and JSON validation.
I believe this approach would leave some flexibility for output data and another layer of abstraction would be easier to understand.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I can create a new PR to migrate CLUDataWriter
to Swift (as DataWriter
) and use it as the base class for JSONWriter
(as you suggested). Does this work for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, absolutely. 👍
fileprivate let outputStream: OutputStream | ||
fileprivate var currentError: JSONWriterError? | ||
|
||
public var error: JSONWriterError? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about adding Header Docs for all public methods and variables in JSONWriter
?
So we can regenerate documentation (using Jazzy
) with this new class as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing. I will add the documentation in the next PR.
@return New instance of info module | ||
*/ | ||
- (instancetype)initWithWriter:(id <CLUWritable>)writer; | ||
- (instancetype)initWithWriter:(JSONWriter *)writer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please explain why you decided to change -initWithWriter:
argument from CLUWritable
to JSONWriter
as a default writer for all Info Modules?
I think we should leave those protocols as a general interface so final info module will decide what kind of writer it requires. That's why I used a CLUWritable
so final Info Module could use DataWriter
, JSONWriter
or even VideoWriter
Also, I didn't found same changes in CLURecordableModule
that's why I was a bit confused 🙂
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't touch CLURecordableModule
because I wanted to restrict the changes in this PR to writing JSON data.
On second thought, though, making these changes to CLUInfoModule.h
is not needed. I will revert them, and re-introduce id <CLUWritable>
, in the next PR.
@andrea-prearo Oh, it's my bad. I forgot to publish my comments so you can see them, sorry 🙂 |
Make sense. I'll merge this one. |
Thanks @Geek-1001! I will address your feedback in the next PR. |
This PR addresses #9.