[03:16:40] dr0ptp4kt: how did you stumble on that ores api call? is that something that gets fired a lot? [03:17:01] https://phabricator.wikimedia.org/T152542 has been fixed, but the query that call fires off seems unreasonably slow [04:03:54] (filed https://phabricator.wikimedia.org/T152585 about it) [16:42:01] raynor: getting de-auth'd [16:42:04] one moment [17:02:09] mdholloway: just left a note on the page view ticket… let me know if that makes sense on what we are seeing in iOS [17:24:56] dbrant: left this in the wrong channel posting here, update the survey times: https://gerrit.wikimedia.org/r/#/c/325805/ [19:02:06] niedzielski: were you planning to work on the restyling of the "save" button in the editing screen? 'cause I can knock that out real quick. [19:02:53] dbrant: o/ i don't think so? go for it! [19:10:50] dbrant: niedzielski: re: page refreshing after a description edit. same as with editing the page, the heart of the issue for us is that the backend doesn't offer us any way to tell when the change has truly propagated, so that refreshing will result in us grabbing and caching a copy of the update. should i just add a short delay before performing the [19:10:50] refresh? (it looks like we don't do that for page edits anymore.) [19:11:32] hm, maybe it got lost in a refactor? [19:12:08] mdholloway: +1 for adding a delay. Yep, it probably disappeared when we switched to retrofit. I'm curious how we'd reintroduce it now? [19:12:49] as for updating the UI optimistically, i have kind of mixed feelings. it seems like doing that would be misleading in the event we refresh too early, and of little value in the event we get the updated copy on refresh. [19:13:53] ok, delay it is! i'll track down what happened to the old delay, too. i was trying to see how exactly we'd implemented that for page editing and found it had disappeared. i'll probably do a follow-up to replace it. [19:29:20] niedzielski: dbrant: false alarm! we do still have the delay in EditClient. Just need to do something similar for description editing. [19:29:21] https://github.com/wikimedia/apps-android-wikipedia/blob/master/app/src/main/java/org/wikipedia/edit/EditClient.java#L50-L52 [19:30:28] niedzielski: nice prez, btw! [19:30:29] ah, cool [19:31:02] ha thanks [20:18:13] mdholloway: hey not sure when gerrit is coming back up but wanted to get that date patch in before you deploy… (are you deploying??) [20:18:45] coreyfloyd: yeah, i'm planning on deploying, i'll make sure to merge it first [20:19:15] i'll put out a call for dbrant to sign off too once gerrit is back up [20:19:43] mdholloway: awesome thanks [20:19:55] will do. [20:38:14] dr0ptp4kt: meeting? [20:38:28] bmansurov: eek. be right there [20:47:18] dbrant: coreyfloyd: gerrit's back up! https://gerrit.wikimedia.org/r/#/c/325805/ [20:54:13] mdholloway: 🎉 [21:05:10] mdholloway: What's the issue with optimistic updates for description edits? I'm not sure I follow. We don't need to refresh automatically in that case. And due to that combined with the (speedbump) success activity I don't think we would need a delay for description editing. No delay in the client also means the tests run faster, too. [21:08:41] bearND|afk: so what you have in mind is to update the page model object and the cache, no refresh? [21:09:30] bearND|afk: could try it that way, too, i suppose. the issue was that if we refresh, it's likely to knock out our change [21:10:05] actually better than likely, guaranteed! [21:10:43] i'm not sure what updating the cache would look like here but i can play with that approach after i finish the deployment [21:12:24] yes, just update the cache, no refresh [21:12:59] mdholloway: I think you can retrieve the old page content from the cache the put it back with the updated description [21:13:51] although i'm not 100% sure if this works due to timing issues [21:14:44] mdholloway: so, maybe do your original approach for now and then we can try the other approach later [21:15:24] maybe we could update the cache in the way you suggested and then do a refresh with cache preferred? it would have to be either that or update the cache and separately set the new description on the description textview [21:22:31] mdholloway: hmm, the more I think about the page cache idea the less I like it. It would be best if we would avoid messing with the page cache since we want to get rid of it eventually and just rely on okhttp caching [21:23:51] bearND|afk: good point, i hadn't thought about that either [21:23:56] mdholloway: maybe we could disable the use of the page cache when coming back from the success activity, but then there's still the issue of what if the page activity had to be recreated due to memory constraints