As talked in Moving app to Swift issue I configured project by adding bridging headers for main target and unit tests one, and changed a bit configuration of them by adding Swift support.

I also had problems with integrating Quick and Nimble via Cocoapods because Swift libraries are integrated as frameworks and Cocoapods' requirement is to use flag use_frameworks!. This flag brake another pods and project is not compiling. Because of that I decided to download frameworks from github and integrate them with project manually. I created sample test (not commited) and project is compiling which is great ;)

With this setup I think we can start moving by little steps to Swift ;)

https://trello.com/c/dd7EGPPt/6-move-settings-in-app

Adds a settings modal from which the unit settings can be selected. It also displays the privacy policy in a web view.

To-do:

• [x] Find a good place for the settings button
• [x] Bring in acknowledgements
• [x] Add Tropos version/build information
• [x] Outbounds links to Forecast.io and thoughtbot

This PR implements caches the weather update to disk whenever it's requested. This cache is then used when the app is loaded so the user doesn't have to wait for the update to complete to have something on screen.

I'm opening this as a separate PR than background fetch. This sets up the prerequisite things we need so I can come back with another PR that uses this to refresh this data in the background.

In this gif: 1st app start is fresh with no cache. 2nd is with the cache

We show whether there is no chance of precipitation, a slight chance (< 30%), or a good chance (> 30%). The precipitation chance is displayed on the main weather screen, above the wind information.

• Add TRPrecipitationChanceFormatter to handle formatting of precipitation chance string
• Add TRPrecipitation to handle calculation of chance of precipitation severity

Trello: https://trello.com/c/FjADNvIV/1-will-it-rain-today

https://github.com/arashpayan/appirater ?

Prompt users after x hours or y opens to answer if they like the app, and send the ones who don't to your support email while prompting happy users to leave a review.

In some situations the forecast information in the morning push notification is outdated. When the app goes into suspended state it still keeps cached forecast information. The information isn't actually updated when the silent notification is received, the local notification presented to the user will show the information loaded the last time the app was in the foreground.

The refresh was disabled in #178 because it was preventing the local notification from being shown at all. The reasoning at the time was that the refresh would be triggered by application:didFinishLaunching: when the app was being unsuspended but that appears not to be true.

The solution seems to be trigger the updateWeatherCommand from application:didReceiveRemoteNotification:completionHandler only if it wasn't already triggered in application:didFinishLaunching:

When I submitted an initial beta build to TestFlight, I got a warning about missing localisations for our supported languages (Italian, French and Polish). This work-in-progress PR first configures the project for Base Internationalisation, then sets up strings files for our various languages. This branch can then become a staging area for the actual translations, which I'll be reaching out to previous contributors for help with.

Hey folks,

Thanks for open sourcing the project! Its great to watch the ThoughtBot team (and now others) doing what they do best.

My question is around MVVM Architecture, other implementations of MVVM seem to throw everything into the viewModel where Tropos has a controller object that seems to do most of the heavy lifting. What is the thinking around this? How do you decide where the responsibility of the controller & viewModel starts and ends?

To use an example, lets say Tropos one day requires user authentication in order to see the weather updates, this introduces a authenticationViewController, authenticationController and authenticationViewModel.

If the authenticated state is determined by presence of a accessToken in userDefaults is it the controller that would be providing a RAC signal here? Is the viewModel aware of the authenticated state?

Thanks again!

Fixes #37

Thought about using a blank-returning-boring-dummy view model and relying on viewModelDidChange:, but that seemed excessive.

Waiting on the test suite.

EDIT: Fixes #20

There was a bug in where comparisons shown from the cache would show inaccurate text because it wasn't using the date from the cache.

Ex: If the date was cached in the AM and you open the app in the afternoon it might say, "Last updated 8:00AM, It's the same this afternoon as yesterday afternoon." when it should say, "Last updated 8:00AM, It's the same this morning as yesterday morning."

This PR has the comparison be initialized with a date that it uses when checking the time of day.

I chose to switch from a class method to instance method so that I didn't have to pass the date through a chain of class methods.

https://trello.com/c/IeLJK4C8/36-temperature-comparison-text-not-taking-cached-date-into-account

This partially fixes the issue where certain time zones will never receive push notifications because the time zone names used by Rails are different from those used by iOS (See thoughtbot/Tropos#185 for more information)

This fixes it by not using the names, but the relative offset from UTC as the channel name. Currently we subscribe to us-pacific when the iOS time zone is set to San Francisco.

This PR changes it to subscribe to the channel minus-0700 instead. This is a more reliable way of identifying time zones across platforms.

After having forked this repository, the project does not compile. Indeed errors about old Swift 3.0 version in use raise, making the build fail. Versions of dependencies of Carthage file has been increased to make to project compilable and compatible to Swift 4.2

Note that compatibility to Swfit 5+ implies some refactoring.

This restores functionality that was previously provided by cocoapods-acknowledgements (CocoaPods was removed in https://github.com/thoughtbot/Tropos/pull/224).

The two main parts of this are the generate-acknowledgements command line tool, written as a small Swift program, and a new AcknowledgementsViewController.

The Tropos app appears to indicate a slight chance of rain 365 days a year, even when other weather forecasts are calling for 99% chance of rain. I am located in Canada.

Various strings are unused in the translations and we should remove them to prevent confusion / unnecessary work. Thanks to @tomkowz for bringing these up.

• PrecipitationChanceFormat
• NoneRain
• Good
• Slight
• None