*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
+1 for this idea. I still have an Android 2.3 device, but the Wikipedia app (and others too) is very slow and becomes more and more unusable, while it's agreat user experience on my Android 4.4 device.
If dropping 2.3 support means a faster development of the main Wikipedia app and the <2.3 users still have access to Wikipedia through a lite app (which will be faster and more usable) i would say: do it, it has advantages for both sides :)
Florian
Gesendet mit meinem HTC
----- Reply message -----
Von: "Dan Garry" <dgarry(a)wikimedia.org>
An: "mobile-l" <mobile-l(a)lists.wikimedia.org>, "Carolynne Schloeder" <cschloeder(a)wikimedia.org>, "Toby Negrin" <tnegrin(a)wikimedia.org>, "Lila Tretikov" <lila(a)wikimedia.org>
Betreff: [WikimediaMobile] [Apps] Wikipedia Lite app?
Datum: Sa., Jan. 31, 2015 06:45
Hi everyone,
Those of you who were at the Mobile quarterly review heard me mention Facebook Lite, an app that's designed especially for the developing world.
Notably, their app has a lot of optimisations which make it good for users in developing world:
It's only 252kB, good for limited data plans.It supports down to Android 2.2, good for older devices.It's data-efficient, good for 2G connections and for people on limited data plans.
From a development perspective, some advantages are:
You no longer have to support older versions of Android in your main app.
You can tailor the performance of the lite app to the older devices so it's faster.You can tailor the features of the lite app to the developing market.So obviously there are a lot of advantages for our users if we do this. And, selfishly, I can't stress enough how much dropping Android 2.3 from our current app would speed up development. As an example, almost all of the edge cases with lead images occurred on 2.3 devices, and they required quite a lot of investigation and hacking to fix them up. Obviously we've not dropped 2.3 so far because it's a very strategically important part of our user base, which I'm sure Carolynne can attest to!
I'd say that we should put some serious thought into whether we'd prefer to have a Wikipedia Lite app for the developing world, rather than our current "one app to rule them all".
Comments? Questions?
Dan
--
Dan GarryAssociate Product Manager, Mobile Apps
Wikimedia Foundation
Hi all,
A new apk for the beta app[1] was just published to Google Play, which
should be available within a couple of hours.
Here's what's new:
beta/2.0-beta-2015-02-27:
- 2 widgets for search and feature page (this time hopefully ;) )
- Improve moving of infoboxes to end of first paragraph
- Don't display last modified message on main and file pages
- Read more suggestions for main page based on previous page visited
- Fix disambiguation links that point to specific sections to work properly
- Use icons in Gallery license information
- Video playback in Gallery
- Fix NPE crash when updating DB
- Translation cleanup
Please report any issues you find. Thank you!
Enjoy!
-Bernd
[1] https://play.google.com/store/apps/details?id=org.wikipedia.beta
Moving to mobile-l. See thread below. Additionally, Brion Vibber noted the
following:
<snip>
Nice!
A couple quick notes:
* Face detection can be moved to a background thread to keep it from
blocking the UI, pretty easily I think
* It looks like HTML parsing of the article is pretty expensive, especially
on a big one like the Obama page. Might want to reconsider the idea of
progressively feeding parts of the article in for parsing, whether that's
dribs and drabs sent over the bridge or directly via the network and using
incremental rendering during the download. (Currently I think the whole
page is loaded in as a single string via the loadHTMLString:baseURL: method
on the web view after it's been downloaded and saved to storage, and that
doesn't leave much time for incremental rendering.) This should also space
out the CPU cost of parsing in between download and rendering, and should
get "first pixels on screen" much faster.
* Sounds like the image caching can be improved a lot; you have a great
todo list already :D
</snip>
---------- Forwarded message ----------
From: Brian Gerstle <bgerstle(a)wikimedia.org>
Date: Wed, Feb 25, 2015 at 3:03 PM
Subject: Re: [ios] Instruments trace
To: Dan Garry <dgarry(a)wikimedia.org>
Cc: mobile-tech <mobile-tech(a)wikimedia.org>
On Wednesday, February 25, 2015, Dan Garry <dgarry(a)wikimedia.org> wrote:
> On 25 February 2015 at 14:14, Brian Gerstle <bgerstle(a)wikimedia.org>
> wrote:
>>
>> We're already near max CPU usage while loading an article (time profiler
>> clocks us at around 80-90% peaking well over 100%—our app makes the CPU
>> faster!)
>>
>
> Our app is so unperformant that it breaks the basic principles of
> mathematics. Nice.
>
I mean this in the nicest way: I read that in Jon Oliver's voice
>
>
>> We quickly found a number of "big (CPU) spenders" that we should be able
>> to optimize in parallel by splitting the work amongst the devs. I've
>> started an etherpad where we can scratch notes
>> <http://etherpad.wikimedia.org/p/instruments_observations> on the
>> attached trace, and link to phab tickets as we identify issues.
>>
>
> Good stuff.
>
> I'll go ahead and create notes & corresponding tickets for the things
>> Monte and I discovered. I highly encourage other devs to have a look when
>> they're done with their current work items to see if we can gain any more
>> insight from this trace.
>>
>
> Great. The more material we have for our ticket busting meeting tomorrow,
> the better!
>
Oh don't worry, there will be plenty.
>
>
>> If we want, I can conduct a spike to convert these steps into a
>> rudimentary automation script. *It should take less than a day* and
>> will give us a way to *accurately reproduce the measurements on all our
>> machines* and be able to *relatively compare differences in performance
>> caused by our patches*.
>>
>
> We're not in a position to be able to prioritise this yet. Let's focus our
> energy on getting the immediate problem fixed first.
>
I agree, we can try to reproduce our results manually at first. If that
proves to be unreliable, we will let you know and draft a plan accordingly.
>
> Thanks,
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
>
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
Do site banners appear on mobile apps and mobile web? I can't recall seeing
one. With the growth in mobile, I hope that mobile apps and mobile web will
support site banners for important notifications such as Wiki Loves
Monuments.
Thanks,
Pine
*This is an Encyclopedia* <https://www.wikipedia.org/>
*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*
*—Catherine Munro*
Hi all,
Those of you who have been using the iOS TestFlight builds recently will
have noticed a particularly large regression in user-perceived article load
time. This is not related to the network request that gets the article, but
is actually related to the way the app stores the data it gets.
Some of the iOS engineering team and myself will be meeting tomorrow to
discuss specific action items for fixing this, and working on this next
sprint. We need to get this fixed before we get a production release.
Thanks!
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
See https://tools.wmflabs.org/autodesc for the new API described in the
post. Interesting at least as a fallback to human-written descriptions...
---------- Forwarded message ----------
From: Magnus Manske <magnusmanske(a)googlemail.com>
Date: Mon, Feb 9, 2015 at 2:41 AM
Subject: Re: [Wikidata-l] descriptions in mobile app
To: "Discussion list for the Wikidata project." <
wikidata-l(a)lists.wikimedia.org>
Manual descriptions are, in the vast majority of cases, a waste of
volunteer time. Alternative:
http://magnusmanske.de/wordpress/?p=265
On Sun Feb 08 2015 at 17:37:42 Gerard Meijssen <gerard.meijssen(a)gmail.com>
wrote:
> Hoi,
> How does that help ? The point is exactly that there is no point to
> descriptions. Why iterate on a dog it will still be a mutt.
> Thanks,
> GerardM
>
> On 8 February 2015 at 14:07, Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il
> > wrote:
>
>> I'd rather see it not as something terribly disappointing, but as an
>> opportunity to find a way to fill item descriptions more efficiently.
>>
>> Basically, to find some cycles to resolve
>> https://phabricator.wikimedia.org/T64695
>> בתאריך 8 בפבר 2015 10:33, "Gerard Meijssen" <gerard.meijssen(a)gmail.com>
>> כתב:
>>
>>> Hoi,
>>> I understand that item descriptions are going to be used in a mobile
>>> app. In my opinion that is seriously disappointing because it is not
>>> realistic to expect enough coverage in any language. Particularly in the
>>> small languages it will not be really useful.
>>>
>>> My question is: we have had automated descriptions for a long time. What
>>> is it that they makes that they are not used.?
>>>
>>> Thanks,
>>> GerardM
>>>
>>> _______________________________________________
>>> Wikidata-l mailing list
>>> Wikidata-l(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>>
>>>
>> _______________________________________________
>> Wikidata-l mailing list
>> Wikidata-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation
Bernd, Dmitry, and I met with Gabriel and Marko from the services team.
Notes:
* Bernd to use https://github.com/wikimedia/service-template-node as a
starting point
* Gabriel, Marko to look into cache invalidation / freshness stuff.
Usually, for the mobile apps the latest non-stale response is what's wanted
by the client.
* Apps team should engage with services on getting the mapping and other
fronting service requirements for rest.wikimedia.org deployed.
* The first target service is for something akin to what would be required
by a "Wikipedia Lite" experience, similar in terms of data transformation
to OCG, Kiwix, Text Extracts.
-Adam
Hi all,
A new apk for the beta app[1] was just published to Google Play, which
should be available in a couple of hours.
Here's what's new:
beta/2.0-beta-2015-02-19:
* Bring back search suggestions
* Two widgets added: search + today's featured article
* Translucent toolbar
* Lead image/gallery:
** white background if image has transparency
** crop off more of the bottom of images
* Styling tweaks: infobox color/shadow, disambig link padding
* Avoid NPE crash from onPrepareOptionsMenu
Android guidelines:
* Updated app icon to be more material
* Make nav drawer overlap over search bar
* Ripple effect when highlighting navigation items
* Nearby: secondary action instead of long-click to view on a map
* Don't keep History, Saved Pages, or Nearby fragment in the backstack
Please report any issues you find. Thank you!
Enjoy!
Bernd