Problem Statement Mary is excited about controlling her house electronics from her mobile device, and has turned several rooms of her house into an IoT enabled smart home.

She has setup a backend infrastructure API here: http://private-1e863-house4591.apiary-mock.com/. (Please visit for the full API list).

The API has the following calls:

She would like you to build an iOS or Android application to turn on and off the fixtures. However, she has some expectations for requirements, listed below:

App Functionality

Create a homepage that lists all of the rooms. For each room, create a page that lists all the fixtures and their current state (on/off), as well as the ability to turn each fixture on or off.

The AC fixture has special requirements. The application needs to ping a weather API periodically for the temperature. If the temperature is above 25°C, then the AC needs to turn on immediately if it is off. If the temperature is below 25°C, then the AC should be turned off if it is on. The AC fixture should also show the temperature from the weather API as well as the fixture's on/off status.

To make it easy for you to test, the mock API also has 2 calls that return weather temperatures that turn the AC on and off (you may use them to simulate weather conditions for testing):

http://private-1e863-house4591.apiary-mock.com/weather/cold

// returns mirrored structure of metaweather
 consolidated_weather: 
     0: 
        the_temp: 20

http://private-1e863-house4591.apiary-mock.com/weather/hot

// returns mirrored structure of metaweather
 consolidated_weather: 
     0: 
        the_temp: 30

Persistence Requirements

She would like you to locally persist the data for rooms, fixtures and their state within the app. This persistence should allow the app to show the last known state of the house even if the user is offline.

Performance Requirements

She would like the UI to be seamlessly updated instantly without any blocking or lag when a state is confirmed changed. When a request is in flight (that is, request is sent but response not yet received), the user should still be able to navigate to other screens. When navigating to a room page, it should immediately show the fixtures' current state.

Architecture Requirements

She wants you to properly engineer the app and develop a solid architecture to operate these fixtures. You can use MVVM, MVC or any other architecture that you find useful, but must document it in your README.

:::info iOS Specific Instructions For the UI, you can use either Storyboard, traditional Interface Builder, or even manually create the UIViewControllers and laying out the UIViews, but you must document your choice. :::

:::info Android Specific Instructions You may either use multiple Activitys, or use a single Activity and multiple Fragments, or some other ways of organizing the various screens, but you must document your choice. :::

Platform Version Requirements

As of July 2018, the app should build and target the following OS/SDK versions:

Mock-API Details and Assumptions

For this assessment, we are using a simple mocking API service with no actual state stored on the server. For simplicity, you may assume all fixtures start off as "OFF" when the app is first run, and that no other changes to the fixtures occur unless the app initiates it.

The API doesn't care for the state of the fixture, it just sets the state and returns true on success.