*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
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
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-extendhttp://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).
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
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
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
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?
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
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?)
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]])