|
| 1 | +# Changelog |
| 2 | +This document is intended to be a place to list changes in technical |
| 3 | +detail, ignoring the limits imposed on release notes by Google when |
| 4 | +uploading to the play store. As with everything related to Vialer, this |
| 5 | +document will be open for anybody to read who wishes to. However, this |
| 6 | +is not targeted at end-users but rather at people who work on the |
| 7 | +project to some extent and are very familiar with the entirety of the |
| 8 | +project. |
| 9 | + |
| 10 | +Not every version will need expanding on, if you cannot find changes |
| 11 | +listed here for a version then please refer to the official release |
| 12 | +notes on Google Play. |
| 13 | + |
| 14 | +## [6.4.0] - 2019-09 |
| 15 | +### Onboarding |
| 16 | + |
| 17 | +Onboarding has been completely overhauled from a back-end perspective, |
| 18 | +instead of using a complicated chain of callbacks between fragments it |
| 19 | +uses the new ViewPager 2 library to guide the user through a number of |
| 20 | +steps (which are implemented as fragments). The critical difference |
| 21 | +between this approach and the previous approach is that each "step" is |
| 22 | +completely responsible for all the processing it needs to do. |
| 23 | +Previously, each fragment would send data back to an activity which |
| 24 | +would dispatch and handle HTTP requests and all other processing, |
| 25 | +meaning all the logic for every step is muddled into a single class. |
| 26 | + |
| 27 | +Adding steps to onboarding has become significantly easier as we now |
| 28 | +have a literal list of steps that can be found in the OnboardingActivity |
| 29 | +that the onboarder will progress through, this did not exist before and |
| 30 | +would require each fragment to progress to the correct place. |
| 31 | + |
| 32 | +The main area of complexity is the fact that some steps are optional, |
| 33 | +for example, the step to enter a 2FA code obviously should only show up |
| 34 | +if the user has 2FA enabled. There are two passes to check whether a |
| 35 | +step should be included, initially when all the steps are added (before |
| 36 | +we know anything about the VoIPGRID user) and just before it is |
| 37 | +displayed. This is implemented via the shouldThisStepBeSkipped() that |
| 38 | +can be added on each step, this defaults to FALSE if it is not included. |
| 39 | + |
| 40 | +From a user point of view, we have also added all the required |
| 41 | +permissions to the onboarding process, this presents the user with |
| 42 | +reasoning for why we need this permission and the ability to skip it. |
| 43 | +This means that while the onboarding is marginally longer, we can have |
| 44 | +the app in a completely ready state for the user without having to worry |
| 45 | +about permissions at other points. |
| 46 | + |
| 47 | +### Contact Searching (T9) |
| 48 | + |
| 49 | +The previous implementation of contact searching (this is so a user can |
| 50 | +search for contacts in the Dialer via a T9 search) involved a lengthy |
| 51 | +import process when the user first logged in, even for less than 1000 |
| 52 | +contacts this could take minutes to complete. We would also need to keep |
| 53 | +Vialer alive to regularly monitor any contacts changes so we could |
| 54 | +update this database. |
| 55 | + |
| 56 | +It became clear pretty quickly this could be simplified significantly, |
| 57 | +this searching is now performed as a regex query on-the-fly against the |
| 58 | +actual call records database. This is highly performant even against |
| 59 | +10,000 contacts and has reduced the complexity of the app significantly, |
| 60 | +the net result of this changed was removing 1600 lines of code and |
| 61 | +removed multiple database tables that no longer need to be maintained or |
| 62 | +considered. |
| 63 | + |
| 64 | +### Call Records |
| 65 | + |
| 66 | +There have been a few different implementations of call records, before |
| 67 | +6.2 there was a complex caching mechanism in-place but this caching did |
| 68 | +not allow us to query records or anything more complex, it was simply so |
| 69 | +call records could be viewed offline. In 6.2 this was changed so call |
| 70 | +records were displayed directly from the API, meaning they couldn't be |
| 71 | +viewed offline but it was also possible to provide "endless scrolling" |
| 72 | +and other features. |
| 73 | + |
| 74 | +The next stage has been to import call records into a database, this |
| 75 | +database is easily queryable which means we can actually display a |
| 76 | +subset of data (such as missed calls) without having to query a large |
| 77 | +chunk of data from the api. |
| 78 | + |
| 79 | +The way this has been implemented is that upon first log-in the app will |
| 80 | +make a large number of requests to the api to import all historic call |
| 81 | +records, this will essentially mean going from the current month all the |
| 82 | +way back to the start of 2015 and importing everything it finds. When a |
| 83 | +month has been imported, this will be flagged and requests won't be made |
| 84 | +again. This process is run on log-in as well as periodically to make |
| 85 | +sure our local database has been properly synced. |
| 86 | + |
| 87 | +The call records displayed to the user is a live view of the database, |
| 88 | +so if they select missed calls they can actually view their entire |
| 89 | +history of missed calls rather than the previous implementation which |
| 90 | +would only show a very limited amount and would sometimes cause very |
| 91 | +unexpected things due to the "hacky" nature of the implementation. |
| 92 | + |
| 93 | +The user can still refresh call records, this will make a query to the |
| 94 | +api for all records between now and the last call in the database which |
| 95 | +should result in a minor speed increase. |
| 96 | + |
| 97 | +Behind the scenes it has also been simplified significantly as there now |
| 98 | +only exists a single call record fragment rather than having multiple |
| 99 | +fragments for each type of data being displayed, when a different tab is |
| 100 | +selected or a toggle is changed that fragment will just be told to |
| 101 | +update its data. |
| 102 | + |
| 103 | +### Android 10 |
| 104 | + |
| 105 | +Android 10 support has continued to improve with what can be considered |
| 106 | +a final implementation of incoming call flow. |
| 107 | + |
| 108 | +- If the user is in Vialer already, they will see the incoming call |
| 109 | + screen. |
| 110 | +- If the user is using their phone (i.e. it is not locked) they will see |
| 111 | + a notification, they are able to answer/hang-up the call directly from |
| 112 | + the notification. If they click on the notification it will take them |
| 113 | + to the incoming call screen. |
| 114 | +- If the user has locked their phone, they will see the incoming call |
| 115 | + screen. |
| 116 | + |
| 117 | +### Changed |
| 118 | +- The error message displayed when there is an issue with call records |
| 119 | + (no internet/permissions) has been made much more readable and |
| 120 | + visually pleasant. Under the hood the confusing system for displaying |
| 121 | + these error messages was completely removed and instead a much clearer |
| 122 | + and readable api was created. |
| 123 | + |
| 124 | +- Several improvements have been made to the XML layout files to make |
| 125 | + them cleaner and easier to work with. The actual design presented to |
| 126 | + the user should remain unchanged. |
| 127 | + |
| 128 | +### Fixed |
| 129 | + - There was an issue where the sound played when the third party ended |
| 130 | + the call sounded "corrupted". The cause of this was because we were |
| 131 | + playing the busy tone and then immediately resetting the sounds back |
| 132 | + to how they are outside the call which caused a bit of distortion. To |
| 133 | + circumvent this we are simply sleeping for the same length as the |
| 134 | + tone so we will no longer begin tearing things down until the tone |
| 135 | + has finished played. |
| 136 | + |
| 137 | +- When you connected to a bluetooth device other than a headset, a |
| 138 | + notification would remain saying Vialer was running. This was |
| 139 | + because we were ignoring any keys that didn't look like a headset, |
| 140 | + but not shutting down the service when doing so. |
| 141 | + |
| 142 | +- When a Vialer call was in progress and a GSM call was received, it |
| 143 | + would show/hide the icon in the notification bar multiple times. This |
| 144 | + was because we were checking for in-progress Vialer calls when the |
| 145 | + push notification came in, while we were checking for in-progress GSM |
| 146 | + calls after we had already booted up SIP (much further in the |
| 147 | + process). Both of these checks will now be performed immediately as |
| 148 | + the push notification comes in. |
0 commit comments