[04:01:44] <josephine_l>	 Hi niedzielski-afk , any chance you're around? :)
[04:04:03] <josephine_l>	 Or, umm, does anyone know which Android/Java library is most commonly used to access the MediaWiki API? Been looking around and found a few, but not sure which one to go for.
[05:49:26] <niedzielski>	 josephine_l: we use java-mwapi for the wikipedia android app but i don't recommend it for new projects
[05:50:01] <josephine_l>	 niedzielski, hi. :) I've been looking at Bliki, apparently it's recommended at https://www.mediawiki.org/wiki/API:Client_code#Java
[05:50:06] <niedzielski>	 josephine_l: we're in the process of switching to retrofit which we may or may not move into java-mwapi
[05:50:14] <niedzielski>	 but it's a generic networking lib
[05:50:59] <josephine_l>	 niedzielski, oh, okay. Why isn't java-mwapi recommended for new projects?
[05:51:59] <niedzielski>	 josephine_l: actually, i guess we probably wouldn't move our retrofit code into java-mwapi since we wouldn't technically be communicating directly with a mediawiki install but that's probably tangential to what you're doing
[05:52:47] <niedzielski>	 josephine_l: i think it's likely to be deprecated and i don't think it actually does a whole lot, in my opinion
[05:53:13] <josephine_l>	 niedzielski, ah, yeah, I should def try a different one then. What do you think of Bliki? https://bitbucket.org/axelclk/info.bliki.wiki/wiki/MediaWikiAPISupport
[05:55:30] <niedzielski>	 josephine_l: what's the reason you don't want to modify the existing upload implementation?
[05:56:05] <josephine_l>	 niedzielski, because the class they use to do it doesn't seem to have the methods we need. I could be wrong though.
[05:56:27] <josephine_l>	 niedzielski, their implementation seems to be using in.yuvi.http.fluent;
[05:56:56] <josephine_l>	 The Http.java class
[05:57:37] <niedzielski>	 josephine_l: it doesn't use volley?
[05:58:15] <josephine_l>	 Erm, that's a generic networking library right? Is that all we need, I shouldn't be trying to look for a MediaWiki-specific library?
[05:59:04] <niedzielski>	 josephine_l: yeah, it's pretty generic. designed for small networking requests, but otherwise generic
[05:59:32] <niedzielski>	 josephine_l: hm, let me poke around a little bit
[05:59:46] <josephine_l>	 niedzielski, okay, thanks. :)
[06:02:11] <niedzielski>	 josephine_l: so initially this is for uploading GPS coordinates, right? what else do you want to do with it?
[06:02:38] <josephine_l>	 niedzielski, use those coordinates to query the MediaWiki API for method C. Same thing that we did in the API sandbox
[06:02:51] <josephine_l>	 (Sorry, method D I mean)
[06:03:35] <niedzielski>	 josephine_l: hm, the description for bliki is "The Java Wikipedia API (Bliki engine) is a parser library for converting Wikipedia wikitext notation to HTML." i don't think you're going to be processing much wikitext directly, right?
[06:03:59] <josephine_l>	 niedzielski, yeah, I was aiming to use their helper classes mostly - https://bitbucket.org/axelclk/info.bliki.wiki/wiki/MediaWikiAPISupport
[06:06:11] <niedzielski>	 josephine_l: hm, so i don't have a good sense of how complete this library is. if it happened to support all the query options and outputs you needed, it might save you time. personally, i think it would be easier to use the existing Volley implementation, request json instead of xml, and use Gson annotations on your models
[06:06:45] <josephine_l>	 niedzielski, Volley is kinda like AsyncTask, right, except better?
[06:06:47] <niedzielski>	 josephine_l: but i don't want to discourage you from pursuing one lib over another if you think it's a better option. i'm just giving my opinion
[06:07:24] <niedzielski>	 josephine_l: i think it would be better to think of volley as abstracting away all the threading concerns.
[06:08:35] <josephine_l>	 niedzielski, ah, okay. So if I were to use just Volley, how would I build the URL that I would use in my http request?
[06:09:15] <niedzielski>	 josephine_l: i've used volley quite a bit at my last job and it worked well. if i had to pick a generic networking lib again, i'd probably pick retrofit. the only thing i didn't really understand with volley was how to coordinate multiple requests. for example, if i had to make 3 different requests and assemble a comprehensive output, i didn't quit
[06:09:15] <niedzielski>	 e get how to do that elegantly. i got the sense, but haven't tried, that this would be easy to do with retrofit
[06:09:50] <niedzielski>	 josephine_l: since this project already uses volley, and i know it works well, i personally would try to use volley. that shouldn't discourage you from trying something else
[06:10:31] <niedzielski>	 josephine_l: i'm not sure on what all the conventions are in commons but it looks like one example is in contributionssyncadapter
[06:10:40] <josephine_l>	 niedzielski, sure, I don't have any preferences since I haven't properly tried any of the other libraries either. So trying Volley is good with me too.
[06:10:46] <niedzielski>	 josephine_l: you can see that a method called action has been added, for example
[06:12:21] <niedzielski>	 josephine_l: if you're interested in a volley overview, you might check out this video: https://www.youtube.com/watch?v=yhv8l9F44qo . i watched it last year and it was alright. definitely not needed to do an implementation but at least it will give you some insight into the design goals of the library
[06:12:48] <josephine_l>	 niedzielski, sorry, I'm a bit confused, aren't they using MWApi Requestbuilder in ContributionsSyncAdapter?
[06:13:25] <niedzielski>	 josephine_l: i thought that used volley underneath the covers? (checking)
[06:16:24] <josephine_l>	 niedzielski, hrmmm. Maybe I could just use MWApi too then? Although their methods seem to be mostly for logging in and uploading
[06:16:44] <niedzielski>	 josephine_l: hm, so i see volley being used for some image loader but i think you're right, mwapi is not using volley :/ i have used the apache http client much directly to comment on it
[06:18:13] <niedzielski>	 josephine_l: yeesh, is ContributionsSyncAdapter the only place they use RequestBuilder?
[06:18:54] <niedzielski>	 josephine_l: comments like "// This code is fraught with possibilities of race conditions, but lalalalala I can't hear you!" don't promise a good pattern to copy
[06:20:18] <josephine_l>	 niedzielski, actually, from what I see now, they're using MWApi to use in.yuvi.http.fluent.HttpRequestBuilder :/ It's quite convoluted.
[06:20:46] <josephine_l>	 niedzielski, hahahah and yeah. The code is full of stuff like that. There's an "OHAI, look, a kitty!" log or something somehwere too. Lol.
[06:20:55] <niedzielski>	 josephine_l: it looks like CategorizationFragment is wrapping an MwApi call in an asynctask :( :( >:(
[06:21:25] <josephine_l>	 niedzielski, yeah...
[06:22:50] <niedzielski>	 josephine_l: hm, i have some conflict over this. the way i see it, there are a couple options: 1) use either a) Volley or b) MwApi + AsyncTask 2) add a third networking library to the project
[06:23:30] <josephine_l>	 niedzielski, is Volley capable of doing everything all on its own?
[06:23:55] <josephine_l>	 niedzielski, as in, if I used Volley, I wouldn't have to use AsyncTask at all right?
[06:25:40] <niedzielski>	 josephine_l: 1a) i like Volley but the project doesn't have any good examples of using that and might need some refactoring to expose request queue. 1b) i'm pretty anti AsyncTask but the project has a number of example that i think could easily be mimicked to achieve the requests you needed. the AsyncTasks are really lame though. 2) you might be ve
[06:25:41] <niedzielski>	 nturing further into uncharted waters with this and adding another networking lib to the project may convolute networking even more
[06:26:19] <josephine_l>	 niedzielski, ah, okay.
[06:26:39] <niedzielski>	 josephine_l: right, i would expect you to need any asynctasks when using volley. volley would add your requests to a queue that is serviced on a background thread. you'd get a callback on the main thread. you could even do your unmarshalling on volley's background thread
[06:26:46] <niedzielski>	 wouldn't expect*
[06:27:32] <josephine_l>	 niedzielski, I suppose I could give Volley a try and see if it turns out well. I'm just a bit concerned about the timeline, especially as you will be on vacation soon, so I dunno if I would end up exceeding the deadline.
[06:28:49] <niedzielski>	 josephine_l: ok, i can try to put together some trivial mediawiki centric example using volley to get you started. as a back up plan, do you see what i mean about the 1b approach looking pretty straightforward?
[06:29:52] <josephine_l>	 niedzielski, that would be great! And no, to be honest, I'm still a bit mired in the code. :/
[06:30:32] <niedzielski>	 josephine_l: check out CategorizationFragment.CategoriesUpdater
[06:31:26] <niedzielski>	 josephine_l: do you see the implementation for doInBackground?
[06:31:33] <josephine_l>	 niedzielski, oh, okay, I see it!
[06:31:43] <niedzielski>	 josephine_l: api.action("query").param("list", "allcategories").param("acprefix", filter).param("aclimit", SEARCH_CATS_LIMIT).get();
[06:31:50] <josephine_l>	 Yeah, they extended AsyncTask, then created a MWApi to build the query right?
[06:32:05] <niedzielski>	 josephine_l: i think you'd basically plug your request URL into that format and get your result out serially on the background thread
[06:33:08] <niedzielski>	 josephine_l: ok, so your game plan is to first try to use volley (1a) and as a fall back, use MwApi (1b)?
[06:33:20] <niedzielski>	 josephine_l: right
[06:33:24] <josephine_l>	 niedzielski, okay, got it.
[06:34:16] <josephine_l>	 niedzielski, wouldn't we end up re-creating the MWApi code in 1a though?
[06:34:30] <josephine_l>	 Re-writing, I mean.
[06:37:12] <niedzielski>	 josephine_l: hm, there would be some overlap. however, at 180 lines, is mwapi really doing that much? it looks like it gets the result back as xml and then the client uses an xpath to specify the nodes they want
[06:38:06] <josephine_l>	 niedzielski, ah, okay. So I'll just reuse some of the MWApi code like the request builder in my implementation then.
[06:38:13] <niedzielski>	 josephine_l: i suppose you could request an xml response back in volley and still have it populate a Document if you wanted
[06:38:24] <josephine_l>	 niedzielski, speaking of which, we'll be using JSON right?
[06:38:56] <niedzielski>	 josephine_l: if you're going to use MwApi, i think i'd recommend sticking to the current implementation which seems to be xml centric
[06:39:22] <josephine_l>	 niedzielski, okay.
[06:40:40] <niedzielski>	 josephine_l: you see what i mean about it using an xpath, right? check out the result processsing on line 169, ArrayList<ApiResult> categoryNodes = result.getNodes("/api/query/allcategories/c");
[06:41:23] <niedzielski>	 josephine_l: so it gets back a big xml structure and just drills into the nodes it cares about
[06:42:15] <josephine_l>	 niedzielski, oh, got it, thanks! But why the comment on ApiResult about valid json?
[06:43:25] <niedzielski>	 josephine_l: sorry, could you reframe that question? i'm not following :)
[06:43:55] <josephine_l>	 niedzielski, line 50 in ApiResult.java
[06:44:46] <niedzielski>	 josephine_l: ah, iwas looking at the decompiled class which didn't have comments :)
[06:45:31] <niedzielski>	 josephine_l: no idea. it looks like an xml request to me: .data("format", "xml")
[06:46:29] <josephine_l>	 niedzielski, haha, yeah. I just got confused by that, my bad.
[06:46:52] <niedzielski>	 josephine_l: i wonder if this commons MWApi is some old fork of java-mwapi. comment style lookssimilar
[06:47:13] <josephine_l>	 niedzielski, this was written by yuvipanda if I recall correctly. Not sure though.
[06:47:35] <niedzielski>	 josephine_l: hm, ok then probably
[06:48:01] <niedzielski>	 josephine_l: i think the version we have is all json
[06:48:19] <josephine_l>	 niedzielski, so, umm. I try to use Volley, and try to reuse the request building and XPath code from MWApi
[06:48:28] <josephine_l>	 We get the result back as XML and use the XPath code on it
[06:48:49] <niedzielski>	 josephine_l: ok cool. i'll try to figure out a simple implementation on my end. do the same on yours and maybe we'll meet in the middle?
[06:49:38] <josephine_l>	 niedzielski, I don't honestly know if I could get an implementation up before you leave (in 24h?). I'm totally new to both Volley as well as XPath implementation. But I will try.
[06:50:03] <niedzielski>	 josephine_l: well technically i left yesterday :)
[06:50:18] <niedzielski>	 josephine_l: i'll still be around i'm just not as accessible by irc
[06:50:34] <josephine_l>	 niedzielski, haha, okay. :)
[06:50:45] <josephine_l>	 niedzielski, I would make a Volley class to start with then?
[06:51:27] <niedzielski>	 josephine_l: hm, maybe start with that video i sent and i'll try to put together a dummy app showing a basic Request
[06:52:29] <josephine_l>	 niedzielski, aight. :)
[06:53:21] <josephine_l>	 niedzielski, should I try to get this into the existing codebase, or make a dummy app myself? If I put it in existing, can I call the new class from ShareActivity.java as well?
[06:53:27] <josephine_l>	 After the GPSExtractor etc call
[06:54:34] <niedzielski>	 josephine_l: i think it will be a lot easier to start from a new project. that's the approach i'm taking
[06:55:19] <niedzielski>	 josephine_l: i'm not sure on the order. i know that a picture has to be uploaded and the edit might have to come after that
[06:55:45] <josephine_l>	 niedzielski, thanks, will do. Uhh, I had a problem with the last dummy app I made - API 23 doesn't seem to org.apache.http imports. But the updated version of Android Studio doesn't let me choose which API to target when I make the project
[06:56:02] <josephine_l>	 *doesn't seem to play nice with org.apache.http*
[06:56:06] <niedzielski>	 josephine_l: oh, just change your target api in the android manifest
[06:56:20] <niedzielski>	 josephine_l: or use um, there's a setting. hold on
[06:57:02] <niedzielski>	 josephine_l: i think in a gradle project it would be "useLibrary 'org.apache.http.legacy'"
[06:57:23] <josephine_l>	 niedzielski, is that in build.gradle?
[06:57:35] <niedzielski>	 josephine_l: right, app/build.gradle
[06:57:53] <niedzielski>	 josephine_l: http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-apache-http-client
[06:58:16] <josephine_l>	 niedzielski, ah, okay, thanks!
[06:58:37] <niedzielski>	 josephine_l: if that doesn't work, just mimic the commons target api. set targetSdkVersion 17 in app/build.gradle
[06:59:34] <josephine_l>	 niedzielski, what User-Agent do we send as part of the request btw? I read that it's necessary, but I can't seem to figure out what our commons app sends
[07:00:57] <niedzielski>	 josephine_l: user agent is an http header you send as part of your http request. it's used to distinguish the different clients like chromium for linux and netscape on windows or whatever
[07:01:18] <niedzielski>	 josephine_l: my grep of commons for user-agent turns up empty :)
[07:01:22] <josephine_l>	 niedzielski, so I'll just say "Android"?
[07:02:42] <niedzielski>	 josephine_l: hm, maybe it would be copy the syntax used by the wikipedia app? https://phabricator.wikimedia.org/diffusion/APAW/browse/master/app/src/main/java/org/wikipedia/WikipediaApp.java;2ecbf5662a1565c55ad5aca1ad1fe5757fd932fc$220
[07:03:12] <niedzielski>	 josephine_l: but maybe we can worry about that later. that would likely be just an entry in a map or a method call and nothing too complicated
[07:03:31] <josephine_l>	 niedzielski, okay, I'll do without first then?
[07:03:43] <niedzielski>	 josephine_l: sounds good
[07:07:12] <josephine_l>	 niedzielski, thanks, I should probably get to learning Volley now. What's the best way to contact you tomorrow?
[07:07:26] <niedzielski>	 josephine_l: email :)
[07:08:45] <josephine_l>	 niedzielski, aight. :) Have a good trip!
[07:08:55] <niedzielski>	 josephine_l: thanks :)
[08:15:30] <niedzielski>	 josephine_l: i gotta head out. here's an example implementation to get you started: https://github.com/niedzielski/VolleyDemo. please review and follow up with any questions over email. should be pretty straightforward if you compare the HEAD and prior commit
[08:15:59] <josephine_l>	 Ah, thanks niedzielski ! :)
[08:16:35] <niedzielski>	 josephine_l: https://github.com/niedzielski/VolleyDemo/compare/9be6d38...master
[08:16:58] <niedzielski>	 so ~130 lines
[08:17:45] <niedzielski>	 josephine_l: anyway, i'll see you around :) night!
[08:18:04] <josephine_l>	 niedzielski, seeya!