Mobile-l December 2014

mobile-l@lists.wikimedia.org

32 participants
27 discussions

[Apps] Using Swift for new feature development on iOS
by Dan Garry 10 Apr '15

10 Apr '15

*tl;dr: The programming language used to develop new features by our iOS app engineering team is changing from Objective C to Swift at some point in the near future.* When making a native app, the language you have to implement the app in is chosen by the third party responsible for the platform. For iOS apps, Apple chose Objective C to be the language the app is written in. Objective C is a... very strange language. It has a lot of quirks that slow down development. To solve the above problem, you can now write apps in a new language called Swift. Notably, Swift has features that make it less error prone and more concise than Objective C, which should increase our velocity of feature development. Swift is also much more readable and in-line with other languages, which lowers the barrier of entry (which is currently very high with Objective C). Importantly, Objective C and Swift can live alongside each other. So, when we "switch to Swift" we do not need to rewrite all of our existing code from Objective C to Swift. Instead, we can just start developing new features using Swift, and slowly rewrite the old code from Objective C into Swift as time allows. On the downsides, Swift is only supported on iOS 7 and above. iOS 6 only represents around 5% of our user base, and we can pin iOS 6 users to the last version of the app we released before we used Swift. We need to decide what the last set of features we're want in that build are before we switch. Here are our next steps: - Evaluate more concretely whether Swift actually fits our needs or not. [Engineering] - Decide last set of features for our iOS 6 build. [Product/Design] Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

5 9

Testing extensions together
by Antoine Musso 12 Jan '15

12 Jan '15

Hello Mobile! Fairly recently, a code cleanup in Mantle caused a back compatibility issue with several other extensions such as MobileFrontend and ZeroPortal. It could have been caught if, when the Mantle patch has been proposed, we had Jenkins to run the tests of the other extensions. Over the summer I wrote code that supports testing extensions together and I wrote an RFC which got approved [RFC] I am now looking for extensions to tests together and the mobile related ones seems to be good candidate. If you agree, I will craft a Jenkins job that clones: - Mediawiki core + Vendor - JsonConfig - Mantle - MobileApp - MobileFrontend - WikiGrok - ZeroBanner - ZeroPortal And run the MediaWiki PHPUnit test suite. The new job, will be triggered for changes made on any of those repositories and be non voting while it is being refined. Once we are happy about it, I would remove the '-testextension' jobs and make it voting. Next, we can reuse the same logic for -qunit and -qunit-mobile jobs and ends up with well integrated set of repositories. The evil plan for next year, is to extend that to all extensions deployed on the Wikimedia cluster. Crazy? [RFC] tis a long read https://www.mediawiki.org/wiki/RFC/Extensions_continuous_integration -- Antoine "hashar" Musso

3 9

Declarative DOM event delegation in JS views
by Joaquin Oltra Hernandez 08 Jan '15

08 Jan '15

I'm happy to announce that we've landed on Mantle and MobileFrontend a new way to specify DOM events on a javascript view that I think will make our views better in several ways. TLDR: * Backbone style declarative delegated DOM events handling is in Mantle's View class. Use it when possible. TOC: * Why. Current approach to binding events * A different proven approach, delegated declarative DOM events map * Examples of this in MobileFrontend * Good practices and conventions * Gotchas * Next steps Why. Current approach to binding events --------------------------------------- Currently on JS views, when we want to bind some events to the view, we bind them on the `postRender` method, like so: var CounterView = View.extend({ // ... postRender: function() { // View display logic this.$('.increment').click(function(ev) { // ... }) this.$('.reset').click(function(ev) { // ... }) }, // ... }) With the current approach, a few bad side effects follow: * Everytime the view renders, we bind events (multiple of them), this is inefficient, there are better ways. * The postRender method on views grows a lot in size, event handling declarations and method code is mixed with display logic. * The complexity of the view (arguably) increases, and with it the ability to read and modify the source confidently. A different proven approach, delegated declarative dom events map ----------------------------------------------------------------- Inspired and brought from Backbone.js, we have ported their dom events map, which brings a way of specifying event and selector, and a handler that will be bound to the view, declaratively on the view itself, the same way we specify defaults, for example. http://backbonejs.org/#View-extend http://backbonejs.org/#View-delegateEvents The previous example, with this approach with our views would be: var CounterView = View.extend({ // ... events: { 'click .increment': 'increment', 'click .reset': 'reset', }, postRender: function() { // View display logic }, increment: function() { this.counter++; }, reset: function() { this.counter=0; }, // ... }) On View, we can now specify a `events` entry, which is a map of `event selector`: handler Where event is any valid jQuery event, selector is any valid jQuery selector, and handler is either a function, or a string (name of a method on the view). With this approach: * Events are bound with delegate, effectively attaching one DOM listener on the view's root DOM element. (Read http://api.jquery.com/on/#direct-and-delegated-events) * To see which DOM events the view binds and reacts to, just need to find the events map of the view. * Event handling code (usually pieces of logic of the view) gets a name, and it's encapsulated on its own method giving us: * Reuse of such logic/functionality * Easier and better testability * Cleaner postRender methods Internally, this is just using jQuery to delegate the events and the selectors to specified handlers bound to the view, no black magic. Examples of this in MobileFrontend ---------------------------------- https://gerrit.wikimedia.org/r/#/c/180835/ https://gerrit.wikimedia.org/r/#/c/180836/ https://gerrit.wikimedia.org/r/#/c/180837/ Notice that the code is much less nested and comes back to View level. In some cases the postRender method becomes unnecessary, and is deleted, and the code that was on it, has now a name and is properly encapsulated on the view. Good practices and conventions ------------------------------ When creating event handlers, if they are doing DOM stuff, like preventDefault, or extracting data from the DOM node, manipulating the DOM, etc, you should name the handler `onEvent`, for example `onThanksClick` or `onHeaderToggle`. If possible, extract functionality that makes sense independently into methods with a good name and call them from the handlers as needed. When creating methods on a view, like the `increment` example above, that happen to be called when an event happens but make sense independently, I would argue that a method name `increment` makes more sense than a handler name `onIncrementClick`, but that is open to common sense and taste I guess. If I had to also extract what to increment from a DOM element, and then increment, then I would do both, for example: // ... events: { 'click .increment': 'onIncrementClick' }, onIncrementClick: function(ev) { var amount = parseFloat(this.$('.amount').val()); this.increment(amount); }, increment: function(amount) { this.counter += amount || 1; }, // ... Gotchas ------- Currently, a common practice is inside a event handler to access the DOM element that initiated the event doing `$(this)`. With the events map the handlers/methods are at view level and are consistently bound to the view's this, so how do we access the DOM element of the event? Handler methods get an jQuery.Event as a parameter, so: onIncrementClick: function(ev) { var $incButton = $(ev.target); // ... http://api.jquery.com/category/events/event-object/ Next steps ---------- If there is any doubts or concerns, please ask them. If you find going along the code you spot a View that could benefit of this approach, open a Phabricator task (prefixed with "Hygiene" and in the MobileWeb team) and take on it ifyou want. I think this gives us a good opportunity to get more view tests, and make the code cleaner, more understandable and approachable for both us and possible contributors (Backbone style views are known by everybody at this point).

3 3

experimental error reporting interface for mobile
by Ryan Kaldari 30 Dec '14

30 Dec '14

Thanks to finally having some time to write code during the holiday slow-down, I put together a little feature prototype as a research project: https://gerrit.wikimedia.org/r/#/c/182082 The feature is just a simple interface for reporting errors on article pages (similar to what exists on the Spanish and Russian desktop Wikipedias). It adds a 'Report an error' button to the bottom of article pages. When they click the button it encourages them to fix the error themselves by editing the page. If they still want to submit the error, it gives them a text input for doing so. The error report is then posted on the article Talk Page, the overlay is closed, and the user is shown a toast notification thanking them for their feedback. This is intended to be a lightwight form of microcontribution, but without all the extra overhead of ArticleFeedback and without the complexity of real talk pages (or Flow). Unfortunately, it can only be used if the user is allowed to edit, so it will be of limited value on non-Italian Wikipedias. Try it out and let me know what you think. Kaldari

3 5

Wikipedia Beta Android app update
by Dmitry Brant 22 Dec '14

22 Dec '14

Hi everyone, We're very excited to bring you our latest update to the Wikipedia Beta app, which should be available on the Google Play Store shortly[1]. The updated app packs a ton of awesome new features, the biggest of which are: * Lead Images -- When navigating to an article, the app now displays the most relevant image from the article at the very top, with the image expanded to fit the width of your screen, and the title of the article overlaid onto it. This provides a much improved visual context of the article, and a better entry point into starting your reading experience. (We're even doing face-detection in the image, so that photos of persons are properly aligned in the viewing area) * Image Viewer -- Tapping on any image in an article (including the lead image) will take you to a full-screen image viewer where the image may be panned and zoomed. It also displays the caption, as well as author and license information, overlaid on top of the image (tap once on the image to make the descriptions slide away). There are also options, accessible from the toolbar on the top right, for sharing the image, saving it to the photo gallery on your device, showing miscellaneous information (Exif) about the image, and navigating to its File: page on Wikipedia. * Search enhancements -- We have improved the search experience (accessible from the top toolbar) to intelligently incorporate search results from title-only searches, as well as full-text searches, so that typing a search term will give you the most relevant result, without having to switch between Title and Full-text search. More minor enhancements include: * Wikidata descriptions in Nearby search results. * Improved design of collapsed infoboxes and tables. * Improved design of the main toolbar and search interface. * Now bundling license information for open-source libraries that we use in the app (accessible from the More -> About screen) * Now using ProGuard in some portions of the app package, making it a bit smaller in size. * Numerous bug fixes for crashes and compatibility with various device types. We hope you enjoy using the updated app, and as always, we welcome your feedback! Cheers, Dmitry Brant Mobile Apps Team (Android) Wikimedia Foundation https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering [1] https://play.google.com/store/apps/details?id=org.wikipedia.beta

7 18

Wikipedia Beta Android app update
by Bernd Sitzmann 19 Dec '14

19 Dec '14

Hi, As a heads-up, we've released another update of the beta app a few minutes ago. This a more of a bug fix release: * Fix lead image click area in 2.3. This made it really hard to use the app on Android 2.3. * Go to first suggestion when search submit button is pressed instead of taking the entered text literally. * Updated share icon in image viewer. * Fix various crashes. Cheers, Bernd Mobile Apps Team (Android) Wikimedia Foundation

1 0

Re: [WikimediaMobile] [Wikitech-l] A new extension of content tree about Wikipedia
by Jon Robson 18 Dec '14

18 Dec '14

Okay I had a long hard think about this. I would suggest the following EventLogging experiment on the mobile website: Question to answer: If section collapsing is provided to users in such a way that sections are open by default, do users find the ability to collapse sections a useful feature? To run this experiment: * We will run EventLogging on a certain set of pages that we know are popular on tablet devices (we can make this configurable - maybe set to the top 5 visited articles on the previous day) * We will log an event for page views to these pages with a unique session id * We will log an event when a section is toggled closed on these pages with the same unique session id * After collecting substantial data on the target pages we will analyse that data to see what we find. What % of visits toggled close at least one section. We can then come back to this discussion with a proposal over whether we think it would be a useful feature on desktop. Eallan is this something you would be interested in doing with guidance and support for the mobile web team?

2 1

Search
by Adam Baso 17 Dec '14

17 Dec '14

Mobile web crew: just wanted to say I really like the enhancements on the fulltext search layout the mobile web. It's looking really good! Thanks! -Adam

1 0

API "Nearby" query coordinate bug
by Monte Hurd 16 Dec '14

16 Dec '14

I spent a while today trying to figure out why the app's Nearby didn't seem to be very accurately determining the angle between the device and the article's geo coords. Angles seemed to be off by strange amounts depending on how close I was to an article's supposed location. I believe I found the problem. Run the query below and you'll see the result for Wikimedia Foundation: https://en.m.wikipedia.org/w/api.php?action=query&colimit=1&format=jsonfm&g… The API result says the foundation's coordinates are: 37.787, -122.4 But if you look at the article on desktop it says the Foundation's coordinate are: 37.78*697*, -122.*399677* You can see what's happening. Can we make the API not degrade the coordinates? Super quick fix? (Or is there some extra parameter I should be using?)

3 3

Wikidata now has a mobile site
by Max Semenik 16 Dec '14

16 Dec '14

Hi, today I've enabled MobileFrontend on wikidata.org. So far, it's still considered a trial, so no automatic redirection for mobile devices happens. While it was primarily needed to satisfy a dependency in WikiGrok, this is as good chance as any to revisit the topic of having a mobile UI for Wikidata. The news are both good and bad: while claims unstyled and therefore look broken, they don't take whole desktop screen's width which is a good indicator that a bit of CSS should fix it. I think that even viewing Wikidata from mobile would be really awesome. Compare yourself: https://www.wikidata.org/wiki/Q2 vs. https://m.wikidata.org/wiki/Q2 -- Best regards, Max Semenik ([[User:MaxSem]])

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l December 2014