2.3 Dev Log (old)

Some things I've learnt along the way

• I need to abandon ideas faster when they don’t work out.
• I really should have used a branch for adding in the default rounds functionality. There were a lot more code changes than I expected
• Java libraries work in Kotlin
• JUnit can classes can be grouped into suites
• Letting yourself get stuck on the same bug for hours on end just makes you not want to code. Work around it or come back to it. I worked around the view rounds not hiding columns properly by manually removing them (rather than using the library’s hideColumn), and I created a bug card for the delete row resizing itself after I delete a row. Not ideal but for now it’s keeping me going. Maybe later I’ll think of another way to possibly fix it.
• To define an inner class in Kotlin it needs the key word inner. Not sure what type of class is created when you just define a class within another class as you would in Java. Maybe just a nested class.
• I need to be careful with alert dialogs that they’re only being called once (otherwise it looks like you have to press the OK button twice to dismiss it)
• The adapter in the TableView is the thing holding all the cell information, not the recycler views
• Exporting the database schema allows you to test the migration
• suspend keyword basically makes a function run async. LiveData achieves the same effect
• Database datatypes can be whatever you want then you use a TypeConverter to define how to convert the custom datatypes into SQL types. The TypeConverter can be global, local to a DAO, or even local to a DAO method.
• Android Room Repositories are split by DAO (i.e. if DAOs are large, have one Repo per DAO. Otherwise, combine smaller DAOs into one Repo). Whereas, ViewModels are split by UI elements (i.e. each Fragment gets its own based on what it needs)
• Repositories are for abstracting the DAO which directly access the database. This allows there to be multiple data sources. Repo also handles caching.
• Using ViewModels means that when a Fragment is destroyed and recreated (for example when rotating the screen) the data for the Fragment is not lost.
• For dimensions, dp is used for everything except text which uses sp. Dp will scale with screen size, sp will also scale with what a user has set as their text size
• When you update something in the database and need to immediately retrieve it, this should be done in using the callback on the observer of the LiveData. The cache won’t have updated between the calls for insert and get.
• Unlike Java, it seems Kotlin implicitly calls getters. I’ve noticed when I’ve tried that Android Studio flags it up as unnecessary, recommending that I just call variable = newValue rather than setVariable(newValue). Looking into it, directly calling it will actually call the getter, which is defined slightly differently to Java (see code snippet below). I think it’s quite neat :)
• A lot about fixing errors. I’ve started to get used to the error messages the app throws.
• Using fragments and a navigation resource for defining transitions between said fragments and SafeArgs for passing arguments
• Found out about layouts for grouping UI elements
• Room (DBMS) is great, thought I was going to have to make a database wrapper myself again
• Be careful to separate calculations and view logic so that unit tests can be implemented
• How to make a style so that the buttons could have common properties
• An activity’s XML should only contain view logic. All the button listeners should be defined in a kotlin file (don't use android:onclick in the XML)
• Toast is the name of the little popup message at the bottom

---

"Time you enjoy wasting is not wasted time" - Unknown