Portal Downtime
When opening the app without portal access, it should alert the user that the portal could be reached and only local modules will be shown. There should only be 3 icons on the home screen for the modules that don't require the portal.
To test this, you'll need to either shut down the portal server, or prevent your device/emulator from reaching the portal host.
Network Downtime
When the user tries to make any network request (such as loading home screen, logging in, trying to load a portlet), the app should check that they have a live internet connection. If the device doesn't have an internet connection, a simple window should appear notifying them that they don't have network access, with a button to try again. Once the user has internet connection again, if they press try again, it should take them to the home screen and load their portlets.
To test this, go into Airplane mode or disable data on the device/emulator. Once the network downtime screen has been reached, turn the network radio back on to test that the app is able to re-establish a connection.
Authentication Process
When the user first installs the app, they should be automatically logged in as a guest, and an indicator at the bottom of the home screen should explain that they're seeing a limited layout. Clicking that notification should open the settings window where they can login. After logging in successfully, they should be notified that they've logged in, and should be redirected back to the home screen where their new portlets will be loaded. At this point, the blue indicator at the bottom of the home screen should be gone. If the user returns to the settings window, they should see a new "Sign Out" button since they're now logged in.
If the user's login is unsuccessful, they should be alerted that the login failed, at which point they can re-type the credentials. If the user goes back to the home page at this point, they should still see the guest layout and blue indicator at bottom of the screen.
When the user logs out, they should be notified that the logout was successful, but the settings window will remain open.
If the user is signed in, their credentials should be saved so that next time they open the app, it loads their individualized layout (and doesn't have the blue guest layout indicator at the bottom of the home screen).
Orientation Changes
The app is designed to be rotated freely, and adapt in orientation and dimensions as the user rotates their device. The best way to test this is to constantly rotate the app each time you navigate to a new view, and rotate each view at least twice to make sure it adapts properly to the changes.
Module Testing
There are two types of modules: native and web-based. The web-based ones all use the same native code, so testing one thoroughly will tend to bring to light issues with all of the web-based portlets.
The main feature to test with web-based layouts is a dynamic secondary navigation bar with a "back" button that navigates the user back one step in the embedded web browser. The back button should only appear on pages after the first page of the portlet. For example, when you open the videos portlet, it shouldn't show the back button until you actually select a video. The back button should remain at the top of the view until the user goes back to the videos home page.
Home Screen
The home screen should display a grid of icons representing portlets the user is able to use. It should also determine if the user is a guest user, and if so, display a blue bar at the bottom of the screen with white text indicating that this is a guest layout. Clicking this blue bar should take the user to the settings module, where they can log in.
If the portal isn't reachable, the blue bar indicator should have text representing that the portal wasn't able to be reached to load modules. Clicking the indicator should attempt to reach the portal again and load the user's portlets.
Map
When opening the map, the user should see a loading indicator telling them that the locations are being loaded. When the loading process is done, the map should be centered based on default location returned from the map locations web service. If there was an issue getting map locations, or parsing the data, the user should be notified of the specific issue with an alert. If the app wasn't able to parse the locations, the user will only be able to search locations that had already been loaded in the app.
When the user searches for a term, it should either notify them that there were no locations that matched the search, or it should plot points on the map for all results that match the search, and should center the map around those locations. Clicking on one of the results should first open a title of that location. Clicking that title should open a detail view of the location, which shows the address, name, and photo of the location.
Clicking "back" from the detail view should return to the map view with the search results still displayed.
Test that you're able to exit the map, return to the map, search, and open a new result in the detail view.