matthewpalmer / charter Goto Github PK

🔁 realtime updates
💬 improved conversation threads
🔎 laying the groundwork for search

It seems the app doesn't display any message that was sent after June 8th.

I tried uninstalling the reinstalling the app but the issue didn't go away. Maybe there's something wrong with the app's backend?

Might be handy to have a quick/simple overview of the architecture and how things are done in the iOS app

Is there a reason for that or..?

I'm sorry but I have a question if I want to contribute to this repository, which branch do I need to track or modify.

I've tried the develop branch, but the app crashed when I click any of the Mailing Lists item, the cause seems to be the realm, do I need to run the backend myself or do I need to do some additional configuration?

I am interested in this repository, and I want to contribute. It will be great if you can give me some additional information. Thanks.

• cut 1.1 release branch
• update metadata with fastlane
• test 1.0 app store -> 1.1 migration
• write release notes
• submit for app review

I want to cat the contents of contributors file onto the end of the readme, and make sure the contents of the contributors file goes out in the release notes for that version.

Todo

• add contributors so far to the contributors file
• write a script to do this
• copy Moya's contributing guidelines/process (i.e. mention in readme that I'll give push access plus community guidelines too)

Conversations are not properly threaded if the In-Reply-To header isn't set. This should be fixed as part of #2.

• Add descendants field to the email document

Do before #14.

Also this should replace the very hacky Mac app and parser that's been built

Prefer the idea of a monorepo over 5 different repos for different modules and stuff, would make contributing a lot easier.

Things I need to think about

• how to deploy the node server?
• multiple cocoapods within a repo?
• is it weird to have the app and the server next to eachother in the directory? [don't think so as long as they stay separated]

I try to run pod install but get this error:

!] Error installing CollapsibleTextView
[!] /usr/bin/git clone https://github.com/matthewpalmer/CollapsibleTextView /var/folders/hk/kjr928bd31g6r9k1qc38y6r00000gn/T/d20160220-4444-1xho9ra
Cloning into '/var/folders/hk/kjr928bd31g6r9k1qc38y6r00000gn/T/d20160220-4444-1xho9ra'...
remote: Repository not found.
fatal: repository 'https://github.com/matthewpalmer/CollapsibleTextView/' not found

Considering moving away from redux/reswift. Reasons:

• not everyone is familiar with it, so might increase barrier to contribution
• I don't want to couple my view controllers to the store, but I'd also rather not create a controller for every piece of state
• the cool thing about react + redux is that you can just pass whatever props without worrying about re-rendering. With UIKit we're going to need to do comparisons of next/previous state to determine when to re-render. I think this would introduce state (esp. w/o a pure render mixin)
• working around UIKit introduces certain workarounds/hacks, e.g. we'd have to re-implement the "Back" button for UINavigationController/Bar to propagate the necessary state change.

I'm definitely convinced that reswift/redux is a great way to write apps, and having a single state receptacle is the way we'll be doing it in the future, but right now for this project I'm not convinced it's a perfect fit. Still thinking it over.

Improve the README layout

• Involves backend db schema change
• Involves Realm db schema change

Currently inline quotes just throw up a fixed-size popover. It'd be cool to size this approximate to the content being displayed.

Also, this UI is pretty bad on iPad

• Add the ability to link from a email in the app to the email on the website.
• Add to backend/database
• Add to app

• think about whether the data sources to the various view controllers should be turned into protocols and injected (at this stage, I'm thinking yes, but it's maybe a little tricky because of the view lifecycle)
• unit tests for thread detail data source
• add tests for formatContent on the EmailFormatter class
• remove various retain cycles that I've introduced
• go through TODOs littered throughout the codebase and open issues or fix

One of the things I noticed when watching @orta’s tvOS app code review video was how helpful it was to have a storyboard to look at when first seeing the codebase. I want new contributors to this app to be able to get a quick overview of the app flow, and a storyboard is the best way to do that. While it might not be 100% the best technical choice, the value it'll add to the community is too much to ignore.

• Need to track and note down any missing messages, parsing errors, etc. This is an ongoing issue.

This won't be ready for a while.

Need to figure out precisely what a star means:

• appears at the top of the threads list?
• receive push notifications?
• adds visual identifier next to message?
• more like a "read later" thing? can you view a list of all starred convos? do we need user accounts?
• do we have star counts for all convos? can people order threads by number of stars?

Add a backend for faster list refresh

• add mail listener
• parse emails
• present emails as REST API
• auth for REST API
• partition emails into threads if they have no references or in-reply-to. also handle the Dave Abrahams case where he doesn't set in-reply-to. Hmm... not sure what to do here yet, but definitely need to be better at handling this so that we get proper threading all the time. Also, provide a /threads endpoint for a list that just has the root emails for each thread

New feature

• add archive URL so we can link to the posts on the swift lists website

Current thinking for the archive URL approach:

Compute a new message's archive URL from the previous message in the db. Every x minutes check that the most recent document's archive URL matches the page it points to. If it matches, we're ok, and continue. If it does not match, find the message that the page references, set the archive URL for that page, and then recompute all archive URLs for messages that come after that message (by date).

This won't ensure 100% accuracy, but bounds inaccuracy within hour-long periods and minimises the number of requests we have to make against the server

• Add tests for backend
• Clean up logging
• Clean up db instantiation
• Open source the backend (open sourcing might take a little while to get all the config stuff set up... also, #7 ?)

99% chance it'll be MIT, just need to think about it for a sec

Hi,
I'm sorry to bother but I took the liberty to localize your app to Portuguese and Spanish. My problem is that I created a branch for it, directly from your repository instead of forking first.
Only noticed it when was pushing the commit.

Are you interested in localizing it as you say in the Readme?
If so, any advice on how to handle it now or should I just create the PR?

People often put [Idea] and [Review] and stuff in the subject line for their messages. It'd be cool to turn these into coloured labels (c/f github issue labels) on the message, and maybe eventually search for them

Often when reading you come across an awkward newline... I wonder if we can do something like if char == '\n' and column == 80 (I think they get wrapped at 80?) then strip the newline otherwise use the newline.

The inline quote handling area of the codebase is a bit of a toxic hellstew