More speed on which device? iOS devices are insanely fast compared to Android:
2 Likes
Iâm on an iPhone 6S. Itâs not so much the speed of the app thatâs the problem, itâs the speed of the network connection. The time from when I click a site in the list to the site being loaded in the browser is too long. When I switch from one site to another and back, it requires a full reload.
I think itâd be nice if the app pre-loaded the Discourse sites and kept them in memory when switching between them rather than reloading the whole page each time.
Doubtful we can do anything about that at the current time. @eviltrout tells me when we upgrade from Ember 1.12 to Ember 2.9+ the load time will improve, though.
Well⌠that is only part of the problem, even when all the resources are cached I am counting 1.5 seconds from when I click on a site till I can see it on an iPhone 7. Feel free to multiply that number by 3-8 for Android speeds.
Our first render is expensive, and all you see is âwhiteâ until the site is ready.
@eviltrout will be looking at adding a âloadingâ state so you donât just see white while stuff is loading, this should improve the experience a bit.
There are other things we need to explore which we will probably next year.
I am super duper extra double reluctant to add any âmobile app specificâ hacks to work around these kind of issues for a few of reasons.
-
We need to focus on a faster / better experience on the mobile site. If the app cheats then we are throwing in the towel and forcing people to use an app which is against our interests. The app is a value add, not a replacement.
-
We use Safari View Controller, which basically gives us a single API call âshow websiteâ. We can not âwarm stuff upâ on iOS 10, there are simply no APIs to load a page without it being visible.
-
This pain is actually a reality check on the real experience we have, I think being aware of the problem is a good thing.
5 Likes
This also implies youâd have shared assets between websites, that is, one set of dependencies that can be pulled down a single time and re-used on discuss.foo.com as well as talk.bar.orgâŚ
Thereâs also the case for jumping between multiple Discourse sites and keeping them in memory (much like tabs on a desktop browser).
You could potentially stick multiple Safari View Controllers in a parent controller that lets you toggle between the various sites without throwing out the page each time the user wants to switch between sites in the app.
I am not sure if this is technically possible, but will investigate at some point.
This is a great point, and make me think, since our vendor.js only changes once every few months we could engineer it so it is shared between all our hosted sites.
6 Likes
Or even just cache it for each site. Check to see if the version numberâs changed since last visit. If not, use the cached version of the client app.
Are you accepting new beta testers or did we miss the boat? Thanks.
I also love to try this out if you still need more testers.
Invites are out, PM me if I missed anyone
I just released very significant build.
As usual a big thank you to @joffrey_jaffeux who got the ânotificationâ feature in.
You now have a little 
in the top right that allows you to view your notifications.
-
New tab shows all new notifications across all sites you are tracking (new is defined as new since you opened the app, it is reset if you kick app to background)
-
Replies, basically strips out likes
-
All is everything across all sites
To support this change I needed to amend it so we request a read/write key as opposed to just a *read key. This means that you will need to re-authorize.
I fixed the âauthâ sequences in a few ways:
-
SSO login, google login etc all forward stuff properly to the auth screen, this was a great general fix to auth
-
The app now clears the âconnectâ button a bit faster so it is less confusing.
If you wish to use the app with any of your sites you must upgrade to latest, a bunch of internal adjustments were required to support the notification window. For example, I needed to add an API to mark a notification read and clean up some internal bugs in Discourse.
Hope you enjoy the build, keep the feedback coming.
Note: we are pretty much done feature wise with the app till our public release. All that is left is polish and android notification collapsing.
9 Likes
What can we do to get iOS notifications on individually-hosted communities?
I had started making almost this exact same application, and had actually started first with the notification part. A lightweight middleman server would forward notification requests to Appleâs (or Googleâs) servers, therefore taking out the requirement of all Discourse instances to have private, global push notification credentials, and providing a layer to restrict to which communities & users they can notify.
Can something like this be provided? Iâd be happy to dedicate time to it, or adapting my initial work to support it.
2 Likes
Perhaps it would be a good idea to have something that looks like OAuth scopes?
So this app would request the notifications scope, âread and manage your notificaitonsâ, and have a full and read_full scope â the current default â for âfull account accessâ for any applications we havenât thought of yet.
Certain URLs, like /session/current, would be permitted with any / a blank scope list (identity is kinda a basic requirement, no need to restrict that).
Actually, looking at the contents of that again, perhaps a /session/whoami.json is neededâŚ
Would probably also want to silo off all /admin URLs into its own admin scope - so full permissions would be full,admin.
2 Likes
Following startup, thereâs a window that shows up and it says that no Discourse sites have been added (note that I already have sites entered prior to startup). That window then disappears and it shows the sites youâve added. Personally, this is very noticeable and it would be great if thereâs a blank window with a Discourse logo on it before the sites load.
Iâve created a video to better illustrate the issue.
iPhone 6 128 GB
iOS 10.0.1 (14A403)
Build 1.0 (11)
2 Likes
I am kind of unhappy this asks for what looks like FULL READ WRITE in permissions now. That is not a good feeling⌠
1 Like
I can look at adding scopes per @rikingâs suggestion to user api keys, so we ask for âread/write notificationsâ or something along those lines.
Yeah full read write is terrible. Itâs gonna post as me? Also what does âwrite notificationsâ even mean? Is that app going to WRITE a notification?
I think what you want is
Read and clear notifications
The actual technical permissions the app needs now are:
- Read current user details
- Access message bus (which is a read but technically a POST)
- Mark notification as read
- Read notifications list
- Reset max seen notification id
We can up with scopes that cover these kind of activities eg:
Discourse for iOS can:
- read/write notifications
- read private user information
- receive updates from site
This would actually be an improvement over the original state which allows global read cause we can be surgical.
Itâs not too complicated of a change, and 99.9% servers side.
I STRONGLY object to the wording âwrite notificationsâ.
That implies the app will send notifications to you in Discourse. Is that the case?
I vastly prefer
Read / clear notifications