Jeff - I totally understand and agree with the need of a startup to focus. So - I have no problem with that.
Just so I understand this better as I try to move forward with an app development effort for Android that I fund - Can you give me an estimate in hours that you think it would take to develop a first cut Android application that works reasonably well that implements the major features (e.g. oneboxing, liking, flagging), but doesn’t attempt to achieve feature full parity with the web version of Discourse?
And - Michael, I can imagine a scenario where I would release the code to the public domain for the app after a certain period of exclusivity for my own site (e.g. a year or so).
I’m not really for building a native mobile client for Discourse, but if you are thinking about building a mobile app, I would look into using Xamarin and writing the app in C# that way you can deploy to Android, iOS, and Windows.
I read a lot of topics about an app for discourse. I know, discourse is web-only, I know, slack guys have only zip their website into an app ;-)and I know discourse is awesome on mobile…
I’m an huge fan of Discourse, really… I’m not a great poster buy I have read a lot and I’m building my community (shifting from FB) on this fantastic platform. @codinghorror I get your opinions and your doubts about it could be right but please, really please, rethink to the possibility to have an app!
One reason: notifications. From this point of view slack wins, notification matter! But I don’t want Slack I prefer Discourse. This is my man
Email notifications aren’t the same, seriously.
Please put some effort to build good API to permit this easily
I feel obligated to point out that there are a few holes in the API, some things that are only ever returned in the PreloadStore in the HTML. Most prominent is site settings.
Our application loads too long, but that could be something on our part. We pretty much dropped this idea. That said I don’t feel that Discourse is obligated to create app. It is the forum software for the web and it works nicely in any browser. No reason to go further.
Agreed. I would rather the site perform in a browser.
However, I like the idea of push notifications. That would give the feel of a native app and I can see it be of great use for mobile users to interface with the OS itself (eg: view notifs for Discourse-built communities on my lock screen).
Is there a method then to auto-deleting specific emails after the notif is read? I am guessing for gmail there’s a filter that can be set on incoming messages.
Please, as I said, it’s not the same. Notifications != email. Otherwise all apps would have used email and not notifications
From my point of view there are premises to go further and try a long step in this direction.
App is not compatible with discourse > 0.9
And Api are incomplete…
I would like to press the point further.
EDIT: even more incentive here is that Pushbullet can be run under nearly any OS, so that means anyone can get popup notifs. Maybe go a step further and have a setting where it doesn’t send notifs if the browser tab is focused.
Aye. It has a lot of potential and a whole array of possible features from just tinkering with Pushbullet’s API. But I’m happy with just push notifs and nothing else!
I think it could be even more active. Unless you’re active on the site, have seen the notification and or read the post, you should get the mobile notification imo. It is a lighter thing and leads to more communication. Though it should be configurable.
I am interested in this as well, and am thinking about doing the implementation. Though no promises and I don’t mind someone else taking it on. I am not a Ruby/Rails person so would be slow going for me anyways.
