For a few weeks now, users of 13.0 nightlies have stumbled across a ‘Weather’ category in their Settings dashboard, and rightfully wondered what it was (and why it’s empty). We’re now ready to provide some exposition on our newest feature to our mainline code.
Historically, we’ve used Yahoo! Weather and OpenWeatherMap to power the weather in the status bar or with our weather widget. Like most things these have had their pros and cons.
Yahoo! has been our default for some time, but they have made some recent changes to their API and policies, causing many bug reports of weather no longer working. Maintaining API compatibility is usually a trivial maintenence task, but Yahoo! Weather now requests every weather query go through an OAUTH implementation, and since these are traceable, counts against a quota limit 100k requests daily (which our millions of users quickly exceed even via previously anonymous requests) should we have just tried to use one static key. The quota and OAUTH changes make it so Yahoo! Weather no longer ‘just works’ out of the box without user intervention.
Around the same 6 month timeframe that Yahoo! Weather made these changes, we were asked by OpenWeatherMap to start using tokenized calls for our requests – but without a limit at that time – and we obliged. In doing their research, it was no surprise that our userbase quickly exceeded what a normal ‘developer’ account would reasonably use. Their pricing structure is not condusive of our use case, and as such we agreed to move away from our usage pattern of their platform.
This left an unfortuante gap, but also an opportunity. Our install base will exceed any weather provider’s caps for free, open-source or developer tiers if reported as all coming from one entity. However, each individual phone is usually making 12-24 requests a day (on average) and well below personal limits. With that in mind, we’ve built a pluggable model for our weather functionality, and through our platform SDK, one that can be repurposed by other apps or use cases beyond just our own.
As of nightlies April 17th and forward, you can download your own weather provider and have it seamlessly power the features mentioned above. This allows us to not have to worry about API limits and the like, as each user is reported independently. The first such weather provider is on the Play Store now (we are looking into FDroid and APK Mirror deployment for those that prefer that route) – WeatherUnderground CM Weather Provider.
We’d like to emphasize this is the just first of many that will be compatible, and work for a sample OpenWeatherMap app under this new model is already under way. Likewise, developers worldwide have the capability to create and upload their own providers for regions and areas where our sample apps aren’t well suited.
Looking at our first sample, let’s answer a few questions preemptively.
1) Do I have to pay for your apps?
No – our samples are free (and the code is open sourced).
2) WeatherUnderground is saying there is a fee for signup?
The pricing structure of our samples all allow for a free ($0.00) developer account for personal usage. You do not have to pay to use this functionality with the providers we are starting with.
3) The UX (user flow) is clunky!
Unfortunately, as the pain points in the post above describe, we can’t seed an API token into the OS, meaning there is some user setup involved. We’d love to avoid this, and provide one that ‘just works’, but the folks that power these things have a right to establish their own rules for usage.
4) Will I have to pay in the future?
For CyanogenMod uploaded samples, no. However, since this is now a public API for anyone to develop against, it’s up to individual publishers to set their pricing – just like any other app on the store.
5) Where is the source code for these samples?
On our Github of course!
6) I don’t like/trust the information from your WeatherUnderground app, what about other samples?
We’re working through other samples (eg OpenWeatherMap) and other developers can upload their own as well.
7) Why not just bundle these into the OS?
For starters, the UX leaves a lot to be desired, especially since there is no solid out of the box working state with zero user setup. Additionally, more apks equate to larger zip downloads, and since you would only need one provider setup & selected, any others would be a waste of space and bandwidth. Finally, in the event of API breakage or compatibility needs, this gives us an opportunity to fix issues without requiring end users to update their OS version to a newer build.