Week 7: Testing on Physical Devices
Hello again readers,
This week we were testing our app on an actual device. Before now, we had been using Android Studio's virtual devices to test the app. Right away we had multiple problems with using the app on a real device. The map itself wouldn't pop up at first, then after that issue, the current location feature would not work on the physical device. We found the bugs that caused these issues and fixed them.
The first problem that we had was that the physical devices were not able to use the current location button on the map activity. This was because it was returning null for the current location. We quickly researched the problem and found a solution by using the different kinds of location features on the device. We found the solution on Stackoverflow.
Another big problem we found was that the first time a physical device would load the app, map would load, but the app would crash if the user tried to do anything. We figured out that if the user reopened the app after this, the app would work completely fine! After some investigation, we figured out that the problem was with requesting access to the device location. We had the request access to device location on the map activity. The problem with that is that the map would already load in the background before the user had time to allow access to their location. This caused the crash with the app. You can see in the first image the map is loaded, but not with the start location that we wanted it to have (Camera zoomed to Augustana). This is because the map was not created correctly. Our solution to this is moving the allow access to the device location to the sign in screen before the map was even created. This way the map had access to the user's location when it was created. This fixed the problem! You can see the fix in the second image where it asks for access to the device location at the sign in screen instead.
The next big thing that we quickly realized is that we needed to change the different layouts for the activities. There will be different sized devices that will be using the app and we have to take the different dimensions into consideration. We first tested the app on a tablet our map layout was all over the place. The request ride button was small, the number of riders was over top of the button, and the start/end location text views were too small. Overall, the layout was a mess! We quickly switched the layout to a PercentRelativeLayout. This layout will change the height and width of attributes based on the size of the screen and the percentage value that you give it. For example, the start and end location text views will take up 75% width wise no matter what device the app is ran on. This allows for the map's current location button to be shown. We applied the percentages to all of the buttons and other fields in the map to make sure that this will be the same for them as well.
Hope you enjoyed the update! We only have one week left to work on the ACES app. Check back in next week to find out how our final presentation went and learn more about the final product!
--Team Aardvark
This week we were testing our app on an actual device. Before now, we had been using Android Studio's virtual devices to test the app. Right away we had multiple problems with using the app on a real device. The map itself wouldn't pop up at first, then after that issue, the current location feature would not work on the physical device. We found the bugs that caused these issues and fixed them.
The first problem that we had was that the physical devices were not able to use the current location button on the map activity. This was because it was returning null for the current location. We quickly researched the problem and found a solution by using the different kinds of location features on the device. We found the solution on Stackoverflow.
Another big problem we found was that the first time a physical device would load the app, map would load, but the app would crash if the user tried to do anything. We figured out that if the user reopened the app after this, the app would work completely fine! After some investigation, we figured out that the problem was with requesting access to the device location. We had the request access to device location on the map activity. The problem with that is that the map would already load in the background before the user had time to allow access to their location. This caused the crash with the app. You can see in the first image the map is loaded, but not with the start location that we wanted it to have (Camera zoomed to Augustana). This is because the map was not created correctly. Our solution to this is moving the allow access to the device location to the sign in screen before the map was even created. This way the map had access to the user's location when it was created. This fixed the problem! You can see the fix in the second image where it asks for access to the device location at the sign in screen instead.
The next big thing that we quickly realized is that we needed to change the different layouts for the activities. There will be different sized devices that will be using the app and we have to take the different dimensions into consideration. We first tested the app on a tablet our map layout was all over the place. The request ride button was small, the number of riders was over top of the button, and the start/end location text views were too small. Overall, the layout was a mess! We quickly switched the layout to a PercentRelativeLayout. This layout will change the height and width of attributes based on the size of the screen and the percentage value that you give it. For example, the start and end location text views will take up 75% width wise no matter what device the app is ran on. This allows for the map's current location button to be shown. We applied the percentages to all of the buttons and other fields in the map to make sure that this will be the same for them as well.
Hope you enjoyed the update! We only have one week left to work on the ACES app. Check back in next week to find out how our final presentation went and learn more about the final product!
--Team Aardvark
Comments
Post a Comment