Persist:: Adam King
For the Persist homework involving the utilization of a database, I created a baseline for a Calorie Counter that allows a user to insert, update, delete, and search entries in a user-made database. The overall concept of the app is simple, but I ended up finding and utilizing a number of new concepts which took a fair amount of debugging. I’d like to eventually go back when I have time and add some other features, but several that I had in mind ended up creating a number of issues I didn’t have time to resolve. To share one of the bigger issues I encountered, having an onListItemClick listener on the ListView and trying to use a checkbox in each entry of the list created an issue where either the listener or the checkbox wouldn’t work (this also applied for a widget named something like CheckedTextEdit). Having checkboxes would’ve made it easy for me to create a progress bar on the same activity tracking calories consumed without having to create a separate activity or method of storage. A simpler feature I did have time to add is the ability to sort based on food name or calorie count.
As far as the new concepts go, there were three I found notable:
To allow users to update or delete entries I decided to use an onLongClick format. However, after some searching I found it was just as easy to register the ListView for a context menu (registerForContextMenu()). With this, the context menu works very similar to the options menu. When using this, there was a bit of a stumbling point in finding the “AdapterContextMenuInfo” object required to actually retrieve what entry you originally selected.
In passing foods around between activities, I considered using Shared Preferences, but had read about Parcelable during the first assignment. This actually ended up being very simple; by having an object implement Parcelable and creating the methods in that object to write the variables out, you can then define a constructor that creates and object by reading in a parcel. This allows you to use the Intent’s putExtra() to store these parcelable objects and send them across activities, and I’ve read that it’s (supposedly) quite fast compared to querying databases or other methods. This also allowed me to have only two activities; the ListView activity and one activity that was able to handle inserts and updates by controlling whether or not the information was editable.
XML is extremely powerful. I was struggling with fitting all of the information on the screen, then I found you can create a res/layout-land directory and create default landscape layouts. This allowed me to have two layouts completely differing in structure between portrait/landscape. It probably would’ve easily solved my issue with foreign languages having unreasonably long translations as well, if I have time to go back and research someday. Along with this, in XML layouts you can specify input types for every edit text and “imeOptions” which relates to focus. It can dictate how focus is passed to other widgets, and probably more importantly, in landscape an EditText has a bad habit of expanding to fill the entire screen. ImeOptions can solve this with flagNoExtractUi.
Overall, this app took way longer than I expected when I started on it and resulted in having fewer features than I originally planned, but this was due to all of the roadblocks I encountered and all of the concepts I worked with in order to find fixes.
