See below.
Corey has created
*https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/BugReporting
<https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/BugReporting>* to help
document this, and is pursuing support for this in Phabricator, Wikimedia's
feature/bug tracker (this replaced Bugzilla). Here's the Phabricator task
created by Corey for this -
https://phabricator.wikimedia.org/T92708 -
as well as a related task on task types -
https://phabricator.wikimedia.org/T93499
-Adam
On Fri, Mar 6, 2015 at 4:02 PM, Kristen Lans <klans(a)wikimedia.org> wrote:
> Love it, I can add descriptions on our project boards...
>
> https://phabricator.wikimedia.org/project/profile/782/
> https://phabricator.wikimedia.org/project/view/489/
>
> It would be cool if we could use some kind of template/custom fields in
> Phab for this. Where else could we socialize this?
>
> On Fri, Mar 6, 2015 at 6:57 PM, Bernd Sitzmann <bernd(a)wikimedia.org>
> wrote:
>
>> I like the idea a lot.
>>
>> On Fri, Mar 6, 2015 at 4:53 PM, Dan Garry <dgarry(a)wikimedia.org> wrote:
>>
>>> (adding Elena and Rummana to this, since I'm not sure if they're on
>>> mobile-tech)
>>>
>>> This all makes sense to me.
>>>
>>> The requested additional information is stuff that it would take the
>>> reporter a trivial amount of time to add to the task, but save time for
>>> both the reporter and engineer in back and forth.
>>>
>>> Dan
>>>
>>> On 6 March 2015 at 11:18, Corey Floyd <cfloyd(a)wikimedia.org> wrote:
>>>
>>>> Hey not sure if we have documentation for this somewhere, but if not, I
>>>> would like to propose we require some minimum requirements for filing a bug
>>>> (at least internally - volunteer bug reports are a separate matter).
>>>>
>>>> The thought is to make sure that bug tickets have enough information on
>>>> them to not only triage but also for engineers to reproduce reliably.
>>>>
>>>> I think the following would be a good start (iOS specific examples
>>>> given, but Android would be similar):
>>>>
>>>>
>>>> Device
>>>> ----------
>>>> iPhone 4, iPhone 6, iPhone 6 Simulator, etc…
>>>>
>>>> OS version
>>>> ---------------
>>>> iOS 6.2, iOS 8.1, etc…
>>>>
>>>> Observed Behavior
>>>> -------------------------
>>>> What happened? (ex. The image is left aligned)
>>>>
>>>> Expected Behavior
>>>> -------------------------
>>>> What was supposed to happen? (ex. The image was supposed to be centered)
>>>>
>>>> Steps To Reproduce
>>>> ----------------------------
>>>> How to reproduce from start to finish example:
>>>> 1. launch app
>>>> 2. tap menu button
>>>> 3. tap login
>>>> 4. enter user name "Test User" and password "Test Password"
>>>> 5. tap login
>>>> 6. etc…
>>>>
>>>> Screen Shot
>>>> -----------------
>>>> Attach a screen shot of the bug (if applicable)
>>>>
>>>>
>>>>
>>>> What does everyone think of this? Anything to add or change?
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Dan Garry
>>> Associate Product Manager, Mobile Apps
>>> Wikimedia Foundation
>>>
>>
>>
>
Hey y'all,
Just a reminder that I've been doing jury duty today and will be for up to
two weeks – I found this out today – which is far from ideal.
The court sits until 4:30 PM so there's time for me to do some code review
in the evening, which'll be a welcome break from, well, everything else.
Boo in general.
–Sam
To get the creative juices flowing for our upcoming discussion about our Q4
work, where I am proposing that we set our sights on getting in-line
Wikidata description editing on the Wikipedia app
<https://www.mediawiki.org/wiki/Talk:Wikimedia_Engineering/2014-15_Goals/Q4#…>,
I spent 30 minutes making a prototype of what I think it could look like to
stimulate discussion.
All the interactions are long-presses simply because it was quicker for me
to do that, and the copy was written totally off the top of my head. When
looking at it, don't think about the visuals or copy, but *do* think about
how you think users would respond to it.
Also, don't be afraid to play with the prototype. All of what's happening
is only happening on your local device, it's not hitting any APIs to save
the descriptions.
If you're the a savvy Android engineer, check out the patch and build your
own Wikipedia Alpha app to test it:
https://gerrit.wikimedia.org/r/#/c/197733/
If you're not, watch a video of it in action:
https://www.dropbox.com/s/nx7xmerlyelk963/wddedit.mp4?dl=0
Feedback welcome!
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
The Wikipedia Beta for iOS 4.0.7.8 has been sent out to the external
testing group via TestFlight. v 4.0.7.7 was only released internally (it
was missing the Crash button), so we skipped that for the external testing
group.
Moving to mobile-l
> Begin forwarded message:
>
> Date: March 20, 2015 at 5:00:09 PM EDT
> Subject: Re: Versioning MobileFrontend
> From: Jon Robson <jrobson(a)wikimedia.org>
> To: Bahodir Mansurov <bmansurov(a)wikimedia.org>
> Cc: mobile-tech <mobile-tech(a)wikimedia.org>
>
> Seems sensible, but knowing history I don't think it will be updated correctly.
>
> I think the updating of VERSION.txt really needs to be automated. Can we have a script that can be run bumps the version number and generates these logs by searching for keywords e.g. 'Bug:' 'Feature:' and generates this list. I think without this, this is a nice idea but will be disastrous.
>
>
> On Fri, Mar 20, 2015 at 1:56 PM, Bahodir Mansurov <bmansurov(a)wikimedia.org <mailto:bmansurov@wikimedia.org>> wrote:
> Hello,
>
> I’ve submitted a patch [1] in which I’d like to start documenting changes in MobileFrontend and versioning it so that interested third parties are more informed about developments in MF. I think we will bump versions at the end of our sprints. I would appreciate it if anyone can share any similar experience they had or any other suggestions. Thank you.
>
> Baha
>
>
> [1] https://gerrit.wikimedia.org/r/#/c/198382/ <https://gerrit.wikimedia.org/r/#/c/198382/>
For the upcoming unstructured sprint on iOS or perhaps later on, would it
make sense to explore reinstating the loading of the first section of an
article in one request, followed by loading of the others?
I've heard that the payload for the upcoming mobile app content service is
pretty dramatically reduced, although that's down the road for full
productionization.
I'm wondering if on this single payload for the new content service for
relatively larger articles the time to interact for the iOS user would
approach the incredibly fast time-to-interact that's present on Android as
a consequence of its two-step loading mechanism.
For some historical context, there was two-step loading on iOS, but
eventually things became crashy, so it was revised to be a one-step
action=mobileview call.
-Adam
See https://phabricator.wikimedia.org/T93210 for details.
Quoting from the discussion: «As of today, there is broad consensus in
support of the proposal, as discussed by an ample spectrum of users
active in multiple wikis. Several users stressed that: talk page access
is crucial, to ensure communication with mobile users; errors of the
past, like the mobile uploads campaign, must not be repeated; local and
global effects in terms of (un)productive contributions will be under
constant monitoring and re-evaluation per the usual processes.»
Nemo
On Fri, Mar 20, 2015 at 11:17 AM, Ulf Buermeyer <ub2125(a)columbia.edu> wrote:
>
> Hi,
>
> just reporting (not subscribing to) the privacy issues ... and IIRC
> there was also a "non-free maps in the context of free knowledge" issue
> being raised.
>
Interesting, since Apple uses OSM to power Apple Maps
<https://blog.openstreetmap.org/2012/10/02/apple-maps/>.
>
>
> Anyhow, if what Brian suggests is generally accepted then I'm happy to
> update my patch (using Apple maps) to the current state of the app &
> submit a new pull request. OSM could always be added lated - I feel it's
> a great way to point users to what free content has to offer by now.
>
> Let me know.
>
> Best, Ulf
>
>
> On 20/03/15 16:10, Brian Gerstle wrote:
> > Ulf, thanks bring me up to speed. I'd love to make this happen, so I've
> > written some responses inline.
> > *
> > *
> > *TL;DR;* I disagree with privacy concerns raised in the PR and (in my
> > non-legal-expert-opinion) think we should be able to do this w/o
> > affecting user privacy or complicated workarounds.
> >
> > On Fri, Mar 20, 2015 at 10:47 AM, Ulf Buermeyer <ub2125(a)columbia.edu
> > <mailto:ub2125@columbia.edu>> wrote:
> >
> >
> > Hi Brian & all,
> >
> > that's basically what I implemented last year (but for articles with
> > geocoordinates):
> >
> > https://github.com/wikimedia/apps-ios-wikipedia/pull/3
> >
> > The addition was rejected for policy reasons (see discussion in the
> PR)
> > - iOS hits Apple servers to download maps and thereby reveals the
> users'
> > locations to Apple.
> >
> >
> > This was before I joined the org. Though I'm reluctant to, I'd like to
> > revisit this debate because I feel we'd be adding a non-trivial amount
> > of complexity (maintenance cost) to the app when it can be avoided.
> >
> > First, showing a map with annotations on it does not require knowing the
> > user's location. We can simply render a map for a given coordinate
> > region and decorate it with annotations from the article. To put it
> > plainly, does looking up map data about Egypt tell Apple that I'm Egypt?
> >
> > Second, and most importantly, we're already giving Apple the user's
> > location for the Nearby feature. If we wanted to show the user's
> > location, we could simply ask for it.
> >
> >
> >
> > Thus we thought we might rather use OpenStreetMap data: If you cache
> the
> > tiles on a proxy operated by Wikimedia, then nobody's privacy will be
> > harmed. The OSM tile server guys would probably prefer you to do that
> > anyway (server load on their side would be HUGE if that's rolled out
> in
> > production).
> >
> >
> > Only issue (besides setting up the proxy) was to keep iOS from
> loading
> > Apple data. That's now feasible as of iOS7 using [MKOverlay
> > canReplaceMapContent] => YES.
> >
> >
> > IMO, the cost of implementing and maintaining all of this does not
> > justify the benefit to the user. We can add a lot of user value with
> > other features, and in this case simply prompt the user with an "Open
> > With..." dialog to view it in an app of their choice. This shouldn't be
> > necessary, as we can render maps in the Wikipedia app without requiring
> > user location.
> >
> >
> >
> > Best, Ulf
> >
> >
> > On 20/03/15 15:38, Brian Gerstle wrote:
> >
> > > Adding a native map view to display nearby locations on a map
> sounds
> > > like a great feature! Are there any links to mock-ups of what the
> > > feature is supposed to look like? I ask because it's not clear
> why we
> > > need custom map tiles or URL protocols instead of simple
> annotations &
> > > annotation views. These are straightforward to implement and fully
> > > backwards compatible.
> > >
> > > On Fri, Mar 20, 2015 at 9:43 AM, Adam Baso <abaso(a)wikimedia.org
> <mailto:abaso@wikimedia.org>
> > > <mailto:abaso@wikimedia.org <mailto:abaso@wikimedia.org>>> wrote:
> > >
> > > Migrating thread to mobile-l, with Ulf's permission.
> > >
> > > On Wed, Mar 18, 2015 at 11:29 PM, Ulf Buermeyer <
> ub2125(a)columbia.edu <mailto:ub2125@columbia.edu>
> > > <mailto:ub2125@columbia.edu <mailto:ub2125@columbia.edu>>>
> wrote:
> > >
> > >
> > > Hi all,
> > >
> > > if you're deprecating iOS6 then the solution might be to
> just
> > > implement
> > >
> > > [MKOverlay canReplaceMapContent]
> > >
> > > and return YES. This effectively prevents iOS from loading
> Apple map
> > > content:
> > >
> > >
> https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOv…
> > >
> > > As for the MKTileOverlay, that would be an option as well,
> I'm
> > > just not
> > > sure how efficient it is for caching OSM content - the
> > > documentation is
> > > silent on that point:
> > >
> > >
> https://developer.apple.com/library/prerelease/ios/documentation/MapKit/Ref…
> > >
> > > And as I already have the drawing code we could go with
> that.
> > >
> > > Best, Ulf
> > >
> > >
> > >
> > > On 19/03/15 01:49, Adam Baso wrote:
> > >
> > > > Oops, /now/ I'm CC'ing Max.
> > > >
> > > > On Wed, Mar 18, 2015 at 10:07 PM, Monte Hurd <
> mhurd(a)wikimedia.org <mailto:mhurd@wikimedia.org>
> > <mailto:mhurd@wikimedia.org <mailto:mhurd@wikimedia.org>>
> > > > <mailto:mhurd@wikimedia.org <mailto:mhurd@wikimedia.org>
> > <mailto:mhurd@wikimedia.org <mailto:mhurd@wikimedia.org>>>> wrote:
> > > >
> > > > Ulf, I was also thinking we could maybe use a custom
> NSURLProtocol
> > > > to intercept the MKMapView's requests for the apple
> map tiles
> > > > (instead of a "overlay only" mode - would have the
> same effect I
> > > > think). Thoughts?
> > > >
> > > >
> > > > On Mar 18, 2015, at 8:45 PM, Adam Baso <
> abaso(a)wikimedia.org <mailto:abaso@wikimedia.org>
> > <mailto:abaso@wikimedia.org <mailto:abaso@wikimedia.org>>
> > > > <mailto:abaso@wikimedia.org <mailto:
> abaso(a)wikimedia.org>
> > <mailto:abaso@wikimedia.org <mailto:abaso@wikimedia.org>>>> wrote:
> > > >
> > > >> Ulf,
> > > >>
> > > >> Great meeting you!
> > > >>
> > > >> Hi there - I was wondering if there was perhaps a
> way to make use
> > > >> of MKTileOverlay for achieving these ends? We're
> going to be
> > > >> deprecating iOS 6 in the relatively near future,
> and this is an
> > > >> iOS 7+ thing.
> > > >>
> > > >>
> http://nshipster.com/mktileoverlay-mkmapsnapshotter-mkdirections/
> > > >>
> > > >> I've CC'd Max Semenik, who may have some insight
> into tiling
> > > >> server options at Wikimedia.
> > > >>
> > > >> -Adam
> > > >>
> > > >> On Fri, Mar 13, 2015 at 3:13 PM, Monte Hurd <
> mhurd(a)wikimedia.org <mailto:mhurd@wikimedia.org>
> > <mailto:mhurd@wikimedia.org <mailto:mhurd@wikimedia.org>>
> > > >> <mailto:mhurd@wikimedia.org <mailto:
> mhurd(a)wikimedia.org>
> > <mailto:mhurd@wikimedia.org <mailto:mhurd@wikimedia.org>>>> wrote:
> > > >>
> > > >> Good seeing you again as well Ulf!
> > > >>
> > > >> I'll check out the OpenRadar ticket and
> experiment some more
> > > >> with your maps patch.
> > > >>
> > > >> Exciting stuff!!!
> > > >>
> > > >> On Wed, Mar 11, 2015 at 10:19 PM, Ulf Buermeyer
> > > >> <ub2125(a)columbia.edu <mailto:
> ub2125(a)columbia.edu>
> > <mailto:ub2125@columbia.edu <mailto:ub2125@columbia.edu>>
> > > <mailto:ub2125@columbia.edu <mailto:ub2125@columbia.edu>
> > <mailto:ub2125@columbia.edu <mailto:ub2125@columbia.edu>>>> wrote:
> > > >>
> > > >>
> > > >>
> > > >> Hi,
> > > >>
> > > >> good to see you guys today! I just wanted
> > to keep you
> > > >> posted about that
> > > >> maps issue. In fact I re-filed a rdar with
> > Apple
> > > in order
> > > >> to have them
> > > >> add an "overlay only" mode to MKMapView
> today
> > > (the other
> > > >> one had been
> > > >> closed w/o any feedback). See my OpenRadar
> for
> > > this issue:
> > > >>
> > > >> http://www.openradar.me/20132462
> > > >>
> > > >>
> > > >> For your reference here is the pull request
> I
> > > issued last
> > > >> year (that's
> > > >> effectively the code for what I showed to
> Moiz
> > > today):
> > > >>
> > > >>
> > > https://github.com/wikimedia/apps-ios-wikipedia/pull/3
> > > >>
> > > >> I'd be happy to work with you on a solution
> > that
> > > complies with
> > > >> Wikimedia's policies as I think that maps
> for
> > > articles or
> > > >> even an
> > > >> initial "places around you" feature with
> > pins on
> > > a map
> > > >> would be very
> > > >> useful additions to the Wikipedia app.
> > > >>
> > > >> All the best, Ulf
> > >
> > >
> > >
> > > _______________________________________________
> > > Mobile-l mailing list
> > > Mobile-l(a)lists.wikimedia.org
> > <mailto:Mobile-l@lists.wikimedia.org>
> > <mailto:Mobile-l@lists.wikimedia.org
> > <mailto:Mobile-l@lists.wikimedia.org>>
> > > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> > >
> > >
> > >
> > >
> > > --
> > > EN Wikipedia user page:
> > https://en.wikipedia.org/wiki/User:Brian.gerstle
> > > IRC: bgerstle
> >
> >
> >
> >
> > --
> > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
> > IRC: bgerstle
>
>
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
Ulf, thanks bring me up to speed. I'd love to make this happen, so I've
written some responses inline.
*TL;DR;* I disagree with privacy concerns raised in the PR and (in my
non-legal-expert-opinion) think we should be able to do this w/o affecting
user privacy or complicated workarounds.
On Fri, Mar 20, 2015 at 10:47 AM, Ulf Buermeyer <ub2125(a)columbia.edu> wrote:
>
> Hi Brian & all,
>
> that's basically what I implemented last year (but for articles with
> geocoordinates):
>
> https://github.com/wikimedia/apps-ios-wikipedia/pull/3
>
> The addition was rejected for policy reasons (see discussion in the PR)
> - iOS hits Apple servers to download maps and thereby reveals the users'
> locations to Apple.
>
This was before I joined the org. Though I'm reluctant to, I'd like to
revisit this debate because I feel we'd be adding a non-trivial amount of
complexity (maintenance cost) to the app when it can be avoided.
First, showing a map with annotations on it does not require knowing the
user's location. We can simply render a map for a given coordinate region
and decorate it with annotations from the article. To put it plainly, does
looking up map data about Egypt tell Apple that I'm Egypt?
Second, and most importantly, we're already giving Apple the user's
location for the Nearby feature. If we wanted to show the user's location,
we could simply ask for it.
>
> Thus we thought we might rather use OpenStreetMap data: If you cache the
> tiles on a proxy operated by Wikimedia, then nobody's privacy will be
> harmed. The OSM tile server guys would probably prefer you to do that
> anyway (server load on their side would be HUGE if that's rolled out in
> production).
> Only issue (besides setting up the proxy) was to keep iOS from loading
> Apple data. That's now feasible as of iOS7 using [MKOverlay
> canReplaceMapContent] => YES.
>
IMO, the cost of implementing and maintaining all of this does not justify
the benefit to the user. We can add a lot of user value with other
features, and in this case simply prompt the user with an "Open With..."
dialog to view it in an app of their choice. This shouldn't be necessary,
as we can render maps in the Wikipedia app without requiring user location.
>
> Best, Ulf
>
>
> On 20/03/15 15:38, Brian Gerstle wrote:
>
> > Adding a native map view to display nearby locations on a map sounds
> > like a great feature! Are there any links to mock-ups of what the
> > feature is supposed to look like? I ask because it's not clear why we
> > need custom map tiles or URL protocols instead of simple annotations &
> > annotation views. These are straightforward to implement and fully
> > backwards compatible.
> >
> > On Fri, Mar 20, 2015 at 9:43 AM, Adam Baso <abaso(a)wikimedia.org
> > <mailto:abaso@wikimedia.org>> wrote:
> >
> > Migrating thread to mobile-l, with Ulf's permission.
> >
> > On Wed, Mar 18, 2015 at 11:29 PM, Ulf Buermeyer <ub2125(a)columbia.edu
> > <mailto:ub2125@columbia.edu>> wrote:
> >
> >
> > Hi all,
> >
> > if you're deprecating iOS6 then the solution might be to just
> > implement
> >
> > [MKOverlay canReplaceMapContent]
> >
> > and return YES. This effectively prevents iOS from loading Apple
> map
> > content:
> >
> >
> https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOv…
> >
> > As for the MKTileOverlay, that would be an option as well, I'm
> > just not
> > sure how efficient it is for caching OSM content - the
> > documentation is
> > silent on that point:
> >
> >
> https://developer.apple.com/library/prerelease/ios/documentation/MapKit/Ref…
> >
> > And as I already have the drawing code we could go with that.
> >
> > Best, Ulf
> >
> >
> >
> > On 19/03/15 01:49, Adam Baso wrote:
> >
> > > Oops, /now/ I'm CC'ing Max.
> > >
> > > On Wed, Mar 18, 2015 at 10:07 PM, Monte Hurd <
> mhurd(a)wikimedia.org <mailto:mhurd@wikimedia.org>
> > > <mailto:mhurd@wikimedia.org <mailto:mhurd@wikimedia.org>>>
> wrote:
> > >
> > > Ulf, I was also thinking we could maybe use a custom
> NSURLProtocol
> > > to intercept the MKMapView's requests for the apple map
> tiles
> > > (instead of a "overlay only" mode - would have the same
> effect I
> > > think). Thoughts?
> > >
> > >
> > > On Mar 18, 2015, at 8:45 PM, Adam Baso <
> abaso(a)wikimedia.org <mailto:abaso@wikimedia.org>
> > > <mailto:abaso@wikimedia.org <mailto:abaso@wikimedia.org>>>
> wrote:
> > >
> > >> Ulf,
> > >>
> > >> Great meeting you!
> > >>
> > >> Hi there - I was wondering if there was perhaps a way to
> make use
> > >> of MKTileOverlay for achieving these ends? We're going to
> be
> > >> deprecating iOS 6 in the relatively near future, and this
> is an
> > >> iOS 7+ thing.
> > >>
> > >>
> http://nshipster.com/mktileoverlay-mkmapsnapshotter-mkdirections/
> > >>
> > >> I've CC'd Max Semenik, who may have some insight into
> tiling
> > >> server options at Wikimedia.
> > >>
> > >> -Adam
> > >>
> > >> On Fri, Mar 13, 2015 at 3:13 PM, Monte Hurd <
> mhurd(a)wikimedia.org <mailto:mhurd@wikimedia.org>
> > >> <mailto:mhurd@wikimedia.org <mailto:mhurd@wikimedia.org>>>
> wrote:
> > >>
> > >> Good seeing you again as well Ulf!
> > >>
> > >> I'll check out the OpenRadar ticket and experiment
> some more
> > >> with your maps patch.
> > >>
> > >> Exciting stuff!!!
> > >>
> > >> On Wed, Mar 11, 2015 at 10:19 PM, Ulf Buermeyer
> > >> <ub2125(a)columbia.edu <mailto:ub2125@columbia.edu>
> > <mailto:ub2125@columbia.edu <mailto:ub2125@columbia.edu>>>
> wrote:
> > >>
> > >>
> > >>
> > >> Hi,
> > >>
> > >> good to see you guys today! I just wanted to keep
> you
> > >> posted about that
> > >> maps issue. In fact I re-filed a rdar with Apple
> > in order
> > >> to have them
> > >> add an "overlay only" mode to MKMapView today
> > (the other
> > >> one had been
> > >> closed w/o any feedback). See my OpenRadar for
> > this issue:
> > >>
> > >> http://www.openradar.me/20132462
> > >>
> > >>
> > >> For your reference here is the pull request I
> > issued last
> > >> year (that's
> > >> effectively the code for what I showed to Moiz
> > today):
> > >>
> > >>
> > https://github.com/wikimedia/apps-ios-wikipedia/pull/3
> > >>
> > >> I'd be happy to work with you on a solution that
> > complies with
> > >> Wikimedia's policies as I think that maps for
> > articles or
> > >> even an
> > >> initial "places around you" feature with pins on
> > a map
> > >> would be very
> > >> useful additions to the Wikipedia app.
> > >>
> > >> All the best, Ulf
> >
> >
> >
> > _______________________________________________
> > Mobile-l mailing list
> > Mobile-l(a)lists.wikimedia.org <mailto:Mobile-l@lists.wikimedia.org>
> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >
> >
> >
> >
> > --
> > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
> > IRC: bgerstle
>
>
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
Migrating thread to mobile-l, with Ulf's permission.
On Wed, Mar 18, 2015 at 11:29 PM, Ulf Buermeyer <ub2125(a)columbia.edu> wrote:
>
> Hi all,
>
> if you're deprecating iOS6 then the solution might be to just implement
>
> [MKOverlay canReplaceMapContent]
>
> and return YES. This effectively prevents iOS from loading Apple map
> content:
>
>
> https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOv…
>
> As for the MKTileOverlay, that would be an option as well, I'm just not
> sure how efficient it is for caching OSM content - the documentation is
> silent on that point:
>
>
> https://developer.apple.com/library/prerelease/ios/documentation/MapKit/Ref…
>
> And as I already have the drawing code we could go with that.
>
> Best, Ulf
>
>
>
> On 19/03/15 01:49, Adam Baso wrote:
>
> > Oops, /now/ I'm CC'ing Max.
> >
> > On Wed, Mar 18, 2015 at 10:07 PM, Monte Hurd <mhurd(a)wikimedia.org
> > <mailto:mhurd@wikimedia.org>> wrote:
> >
> > Ulf, I was also thinking we could maybe use a custom NSURLProtocol
> > to intercept the MKMapView's requests for the apple map tiles
> > (instead of a "overlay only" mode - would have the same effect I
> > think). Thoughts?
> >
> >
> > On Mar 18, 2015, at 8:45 PM, Adam Baso <abaso(a)wikimedia.org
> > <mailto:abaso@wikimedia.org>> wrote:
> >
> >> Ulf,
> >>
> >> Great meeting you!
> >>
> >> Hi there - I was wondering if there was perhaps a way to make use
> >> of MKTileOverlay for achieving these ends? We're going to be
> >> deprecating iOS 6 in the relatively near future, and this is an
> >> iOS 7+ thing.
> >>
> >> http://nshipster.com/mktileoverlay-mkmapsnapshotter-mkdirections/
> >>
> >> I've CC'd Max Semenik, who may have some insight into tiling
> >> server options at Wikimedia.
> >>
> >> -Adam
> >>
> >> On Fri, Mar 13, 2015 at 3:13 PM, Monte Hurd <mhurd(a)wikimedia.org
> >> <mailto:mhurd@wikimedia.org>> wrote:
> >>
> >> Good seeing you again as well Ulf!
> >>
> >> I'll check out the OpenRadar ticket and experiment some more
> >> with your maps patch.
> >>
> >> Exciting stuff!!!
> >>
> >> On Wed, Mar 11, 2015 at 10:19 PM, Ulf Buermeyer
> >> <ub2125(a)columbia.edu <mailto:ub2125@columbia.edu>> wrote:
> >>
> >>
> >>
> >> Hi,
> >>
> >> good to see you guys today! I just wanted to keep you
> >> posted about that
> >> maps issue. In fact I re-filed a rdar with Apple in order
> >> to have them
> >> add an "overlay only" mode to MKMapView today (the other
> >> one had been
> >> closed w/o any feedback). See my OpenRadar for this issue:
> >>
> >> http://www.openradar.me/20132462
> >>
> >>
> >> For your reference here is the pull request I issued last
> >> year (that's
> >> effectively the code for what I showed to Moiz today):
> >>
> >> https://github.com/wikimedia/apps-ios-wikipedia/pull/3
> >>
> >> I'd be happy to work with you on a solution that complies
> with
> >> Wikimedia's policies as I think that maps for articles or
> >> even an
> >> initial "places around you" feature with pins on a map
> >> would be very
> >> useful additions to the Wikipedia app.
> >>
> >> All the best, Ulf
>
>