4 ms·

Why did you choose not to use HNKit from chpwn's news:yc? https://github.com/Xuzz/HNKit https://github.com/Xuzz/HNKit The way you do it right now seems like it

Why did you choose not to use HNKit from chpwn's news:yc? https://github.com/Xuzz/HNKit https://github.com/Xuzz/HNKit The way you do it right now seems like it would be terribly slow. The API calls made by this app are slightly tricky. For the front-page posts, a call is made to http://hnsearch.com/bigrss http://hnsearch.com/bigrss and then the resulting xml is parsed to grab the unique IDs from each post. Those are then sent as a request to the actual API to get the posts. The comments, unfortunately, return as basically a totally unordered set. I create a linked list out of those, and then I turn it into a flat array based on the nested nature of the comments - so UITableView will render correctly.

bennyg 13y ago
HNKit isn't in ARC, and does a myriad of things that I think are unnecessary and can be maintained cleaner (there's absolutely no documentation!!!). Those methods are actually very quick (imperceptibly fast) right now - but I'm not a computer scientist by any means, so I believe they can be made even faster by someone that knows a better data structure to use. Each comment comes back out of order with a parent ID and a comment ID. A comment that is a reply to Comment 1 will have the parent ID matching Comment 1's comment ID (hence my linked list structure right now). There's got to be a better way, and that's also why I open sourced the whole thing. HNKit is also doing XML parsing over everything, and string comparisons can be fairly slow as well. That, in conjunction with not being ARC ready and a total lack of documentation made me choose something else entirely.
- Xuzz 13y ago
  Hey, I wrote HNKit. I'll admit I haven't had time to write documentation. However, most everything follows Cocoa conventions, and the headers should be pretty readable. Absolute worst case, there's an existing app using the framework as an example. :) You can also combine ARC and non-ARC code in one project. HNKit was written before ARC (although I still prefer manual memory management), but there's nothing keeping you from using HNKit with an ARC-based app. And unless you're modifying HNKit itself, you wouldn't ever need to see or write any retain or release calls as a client of the API. Apple did a pretty good job making ARC and non-ARC code interoperate well. I'm happy to help with any HNKit questions — feel free to open issues on GitHub if there's anything confusing. HNKit already supports most of the things you are hoping to implement (logging in, commenting, voting), so I would hate to have all that effort duplicated. If you have any specifics about things that could be done better, I'm all ears. Performance-wise, HNKit hasn't been optimized, but it does do parsing on a background thread. In general, a bit of extra local parsing is almost always going to be faster than additional network fetches. I haven't had any performance issues, even on older devices, so I doubt that part will be an issue at all.
  - bennyg 13y ago
    Hey Xuzz, Didn't mean for that to come off rude if it read that way. I haven't dug too far deep into HNKit - I was really just worried about the interplay of ARC and nonARC code and what that meant for the future of maintainability of my own codebase (really for things that go multiple classes deep, I didn't want to introduce retain cycles and the like). I'm considering creating a branch of this with HNKit and starting to build that in to see how it plays with everything I have now.
    - bierko 13y ago
      You can integrate non-ARC code into an iOS app pretty easily: http://stackoverflow.com/questions/8958761/how-to-remove-arc-from-xcode/ http://stackoverflow.com/questions/8958761/how-to-remove-arc...

bennyg 13y ago

HNKit isn't in ARC, and does a myriad of things that I think are unnecessary and can be maintained cleaner (there's absolutely no documentation!!!). Those methods are actually very quick (imperceptibly fast) right now - but I'm not a computer scientist by any means, so I believe they can be made even faster by someone that knows a better data structure to use. Each comment comes back out of order with a parent ID and a comment ID. A comment that is a reply to Comment 1 will have the parent ID matching Comment 1's comment ID (hence my linked list structure right now). There's got to be a better way, and that's also why I open sourced the whole thing. HNKit is also doing XML parsing over everything, and string comparisons can be fairly slow as well. That, in conjunction with not being ARC ready and a total lack of documentation made me choose something else entirely.

Xuzz 13y ago
Hey, I wrote HNKit. I'll admit I haven't had time to write documentation. However, most everything follows Cocoa conventions, and the headers should be pretty readable. Absolute worst case, there's an existing app using the framework as an example. :) You can also combine ARC and non-ARC code in one project. HNKit was written before ARC (although I still prefer manual memory management), but there's nothing keeping you from using HNKit with an ARC-based app. And unless you're modifying HNKit itself, you wouldn't ever need to see or write any retain or release calls as a client of the API. Apple did a pretty good job making ARC and non-ARC code interoperate well. I'm happy to help with any HNKit questions — feel free to open issues on GitHub if there's anything confusing. HNKit already supports most of the things you are hoping to implement (logging in, commenting, voting), so I would hate to have all that effort duplicated. If you have any specifics about things that could be done better, I'm all ears. Performance-wise, HNKit hasn't been optimized, but it does do parsing on a background thread. In general, a bit of extra local parsing is almost always going to be faster than additional network fetches. I haven't had any performance issues, even on older devices, so I doubt that part will be an issue at all.
- bennyg 13y ago
  Hey Xuzz, Didn't mean for that to come off rude if it read that way. I haven't dug too far deep into HNKit - I was really just worried about the interplay of ARC and nonARC code and what that meant for the future of maintainability of my own codebase (really for things that go multiple classes deep, I didn't want to introduce retain cycles and the like). I'm considering creating a branch of this with HNKit and starting to build that in to see how it plays with everything I have now.
  - bierko 13y ago
    You can integrate non-ARC code into an iOS app pretty easily: http://stackoverflow.com/questions/8958761/how-to-remove-arc-from-xcode/ http://stackoverflow.com/questions/8958761/how-to-remove-arc...