BLOG POSTS
Select a week to see the blog post.
Week 1
Author: John Do
Author: John Do
Our team began the learning process of the tools and capabilities Android Studio has through various online tutorials and videos. We started out by learning the basics with designing the layout of an app through the xml file that you can edit either through code in Java or through Studio's useful Design view, allowing you to drag and drop different types of objects/elements into the app's design with ease and edit them any way you want.
Image: Android studio running a device emulator simulating an example app
Week 2
Author: Elizabeth Sloan
Author: Elizabeth Sloan
This week we are starting work on building the first pieces for our application. John is beginning research on the drag and drop capabilities for our code. Rachel is researching maps and geo locations using Java and Android Studio. Matteo is looking into connecting weather API data to our code. I have started working on creating our general template of activities in Android Studio.
Focusing on my part: I’ve decided that creating and connecting all of the activities that we have laid out in our wire frames will be a simple way to give our project a leg up in the creation process. I’ve done the research in creating and connecting activities through Android Studio, and the Android Studio IDE makes set up super simple.
Choosing the template: I decided to go with the Navigation Drawer Activity because our application will be implementing that same style of navigation, and because we as programmers shouldn’t have to work any harder than necessary at things that have already been done, it just made sense.
Choosing the Version: I chose to go with android version 8.0 Oreo (API Lv 26) because it allows for custom data storage which we want for storing weather data. I didn’t choose any lower because earlier versions didn’t have data storage, and any higher versions had too many features and didn’t support enough devices. I would have preferred to go with KitKat (level 19) which supports 100% of devices, but we need more functionality.
Week 3
author: Rachel Montesano
This week we continued to work on various aspects of our app to prepare for our first sprint in week 7. We each focused on different parts, and once we had working code, we pushed it to our main code's GitHub repository. I worked on getting a radar into our app, which included researching about ArcGIS APIs. I discovered that there is an ArcGIS Runtime API for Android that is thoroughly explained on the ArcGIS Developers website. Using this information, I learned how to include a radar in our app by implementing a WMS (Web Map Service), which can display maps that use frequently changing data.
Week 4
author: Matteo Marcheschi
This week is the first major milestone for our project: Thursday, March 23rd is Sprint 1 demo day. This means that work has accelerated significantly, with our focus moving from understanding the functionality of Android Studio to using it in a meaningful way to create a functional demo of our weather app. John has moved from drag and drop (where he created a functional in-app demo) to understanding how to save the states of fragments (the different pages in the app) when the user switches between them. Rachel is continuing the painstaking process of getting weather radar and map data into our app. Elizabeth has been hard at work getting our individual features combined into the main app.
My work has consisted of connecting our app to the National Weather Service API, which contains current conditions from official weather observation stations across the country, as well as forecasts for any given point in the U.S. By taking the device’s location (a topic which Rachel and John, who both specialize in geolocation in Android Studio, helped me on), I compared each station in a JSON-formatted list of stations nearest to the device’s location to find the closest one. After that, I retrieved the page where the current weather data from that station is located.
After this was completed, I began research about how to do the same task for forecast data. The file path is a bit different than that of current observed data, but my understanding of the JSON file structure meant that finding it was relatively straightforward.
Week 5
author: John Do
This week and for some of the previous week which was spring break for us, we have been focusing on streamlining and refactoring our current code with Matteo working on the main weather data api side and Rachel on the radar api side, and adding new needed features for our upcoming sprint 2. Elizabeth and I have been focusing on getting the android app to be able to save its state through the use of the onPause, onResume, and onSavedInstanceState methods, to restore whenever you switch between fragments, rotate the phone, and when closing and reopening the app. An important feature we want to achieve with this is when it comes to remembering the saved state for when you drag and drop elements on the screen.
Week 6
Author: Elizabeth Sloan
Author: Elizabeth Sloan
Over the past 3 weeks we’ve been struggling to come to terms with the fact that implementing a drag-and-drop and saving the location where items have been dropped are two completely different levels of difficulty. While allowing items to be dragged and dropped is fairly simple, and there are many tutorials on the subject, actually saving the locations is quite more complicated than just using saved instances. While we know it’s completely possible, and we could use file storage for implementing the saving, we only have another week until our Sprint 2 deadline, and our final project is due at the end of next month. We all collectively agreed that our skills are not at the level required to implement the drag-and-drop save.
Our group came to the decision that we were too far behind and needed to simplify our design while keeping our original goal of allowing our app to be customizable. We know how to use check boxes and switches and can implement them fairly quickly, so we have pivoted from drag-and-drop to allowing the user to hide and show widgets using check boxes.
We are currently on track for meeting our goals for sprint 2 after our customizability pivot.
Moving forward, Rachel is working on getting the location to display on the Radar image, John is working towards making UI pieces to disappear and reappear on the home screen (like the wizard he is), I will continue developing the UI and layout of the app and working with Matteo and the rest of the group on connecting the front and back end.
Week 7
Author: rachel Montesano
The focus of this week was on improving the UI for sprint 2, which is in Week 8. Our team has been working to create an overall more attractive UI and to ensure that the widgets that the user turns on will remain on after they close out of the app. I have continued to work on improving the radar fragment, which included removing the "developer use only" watermark by adding a license string to our code, and displaying the device's current location on the radar map.
Week 8
Author: Matteo Marcheschi
Author: Matteo Marcheschi
This week was Sprint 2, and we made significant progress since Sprint 1. Since Sprint 1, I worked with our professor, Dr. Stonedahl, to refactor the code I wrote to get the weather data into a more easily readable and efficient format, using nested FetchJSON statements instead of several methods of the AsyncTask class. This made it easier to ping multiple API endpoints when refreshing weather data. The more visually notable changes came in the form of the use of recycler views for the hourly and daily forecast displays. In this work, I took charge of the backend data retrieval and display, while Elizabeth worked on the frontend, arranging the data within the recycler views and making the UI look as nice as possible. A look at the top photo of Elizabeth's week 6 post, which used placeholder data and at the photos in this post, which uses real-time data, shows just how far we've come in such a short time.
I also researched and implemented a second API that converts latitude and longitude values to town and city names and vice versa, which I used to display the user’s town with the current observed weather data. This API will likely play a significant role in a feature we will work on for Sprint 3, which is the ability to search up locations and get their weather information.
Week 9
Author: John Do
Author: John Do
Our team is continuing a good and steady progress on the app. Rachel has been fleshing out the radar fragment and Matteo has been including more features with the main weather data forecast such as including the ability to save locations and be able to look up your location with an autocomplete capability. Elizabeth and I have been working on adjusting the UI to look more cleaner and pleasing, starting with the widget fragment and changing the colors of the app's overall UI. I have been personally working on fleshing out the education fragment by including an embedded web page that a user can zoom in and out of and interact with.
Week 10
Author: Elizabeth Sloan
Author: Elizabeth Sloan
I think our users are going to need a sock-finding app once they see our app...
Because it's going to knock their socks off!!!
Our latest sprint has seen some big improvements, including new settings that let users customize how they see temperature data. We're hoping this will make the app even more user-friendly.
Matteo, has been busy setting up alerts within the app. They've added new search capabilities, but the UI had a problem where when the user was typing, the search bar would go off-screen. Matteo fixed that bug as well because they've just been an absolute beast with the programming this sprint.
With most of our apps capabilities added, we're able to start focusing more on the front end. I've been having a great time making some custom icons and choosing colors (very important work!)
We've also been busy tidying up our GitHub issues to make sure everything runs smoothly. We've got a few more things to achieve in our last sprint, like saving location preferences and displaying saved locations on our radar map. We're pretty stoked about these features, and we think they'll take the app to the next level.
Week 11
Author: Rachel Montesano
Author: Rachel Montesano
This week we've been working on creating our final features and making sure to fix any bugs as our final sprint is next week.
After weeks of attempting to add more features to the radar (such as a layer for storm warnings) with no luck, I finally succeeded in adding something new to the radar, which is displaying locations (other than the device's location) that the user has saved. This involved getting the locations and their names from the shared preferences and displaying the points and labels on the map as graphics. I also made the radar layer partially transparent so that the user can see town names and other features of the basemap that are covered by precipitation. I was very happy that I was able to add more to our radar fragment and that it all worked the way it should.
Week 12
Author: Matteo Marcheschi
Author: Matteo Marcheschi
It's presentation week, and we have come an incredibly long way in three short months. I'll focus on my own work in this post, but that's absolutely not to sell short my teammate's work in any way. They have all done amazing jobs and I look forward to seeing what each of them go on to do.
These last few weeks, I have been working on one big project that turned into many smaller projects: Being able to display weather data from any location, not just the user's location. Now that this is implemented, it can be done in two ways: Through the location fragment (top), by tapping the location after adding it, or by adding it in the location fragment, going back to the home fragment (bottom), and choosing it from the spinner now located at the top of the screen. This allows the user to see current conditions and forecasts from anywhere in the U.S. I also worked on adding alert banners, which display in red at the top of the home screen.
