Pizza PYDroid

A new minor version of PYDroid is released which changes some internal behavior and some consumer level API changes that warrant a minor version bump.

Consumer API changes have to do with the doOnSaveState, doOnInflate, and doOnInit hooks on the UiView and UiViewModel classes. These hooks used to be inconsistent, doOnInit and doOnInflate would pass a UiBundleReader as an argument, while doOnSaveState would pass the current state as an argument (in the UiViewModel only) and the UiBundleWriter as a receiver. These have been made more consistent for consumers, though this does require a slight API change. The doOnSaveState hook has been changed, to pass both its UiBundleWriter and current state as arguments, making it more consistent with the doOnInit and doOnInflate hooks.

A more significant change is a library internal one, but one which may affect the behavior in applications. The way that a UiViewModel processes setState changes and withState callbacks has changed, and the hooks themselves have also changed slightly.

Hooks are not thread safe, but were not previously enforced in any way though attempting to multithread on hooks would cause errors. Hooks are now strict about the fact that they are UI related events, and so a hook must be called on the UI thread. For most consumers, nothing changes, but if you call a hook within a coroutine that uses a different dispatcher, you must switch context back to Dispatchers.Main before attempting the hook or the function will throw.

The setState and withState calls have some important behavioral changes. One thing that has not changed is that the functions are still asynchronous. However, the dispatcher used for both is a unique single threaded instance, so there will always be a FIFO ordering guaranteed for setState calls. A significant integration change is that withState calls will always yield to setState calls, so withState follows a FIFO ordering within the context of other withState calls, but will always run after all other setState calls. Because the setState and withState calls use their own dispatcher internally, they will not fill the IO or Default queue. While the setState and withState functions used to be backed by a MvRx inspired double queueing behavior, now they are implemented as a single queue, which will make single setState and withState calls simpler to reason, but can lead to confusion with nested calls. Nested ordering is not explicitly guaranteed, but you can generally expect the ordering to be by call nested level - all outer setState, followed by inner setState, followed by outer withState, and finally inner withState.

Another important change deals with the result publishing for setState changes. Previously, multiple setState calls would run and coalesce the result into a single call to render. While perhaps more efficient, this lead to issues where states could be missed as a result of the actual state change not being sent in render. Now results are published after each state change and rendered, and the view layer will provide back pressure to avoid excessive render calls, as well as a more expected order of render operations.

Finally the Activity extension function stableLayoutHideNavigation used to accidentally overwrite all other systemUiVisibility flags in favor of its LAYOUT_STABLE flags, but now it adds these flags onto the already existing systemUiVisibility flags.

The new PYDroid efforts can be seen in the latest developer build of FridgeFriend - which today gained a bunch of color theming polish and better iconography. Some crashes were also fixed and the application got an overall smoother performance thanks to rendering changes on the PYDroid end, as well as some UI optimizations and reduction of redrawing on opaque surfaces.

It is sadly, still not ready for prime time - but it's getting closer every day. I know, feels like a broken record, but I promise, once I get to a good stopping point to cut a initial release I can begin working on the new features I have in mind, which involve using your previously inputted purchase dates and expected expiration dates to derive a guess about when an item you purchased for a second time will expire. As clarification - this is not some fancy AI, since I don't know how to do that. This will be a very naive, on device math that will be simple to understand because I only have a simple grasp of concepts. It will not be invasive, and it will not be annoying. I also wish to get OCR support in for barcode scanning so that you do not have to interact with the software keyboard as much because typing on a touchscreen is hell. Geofencing will hopefully return after the use of a WorkManager powered foreground service loop, which will allow FridgeFriend to be battery efficient and also useful in regards to notifying you about nearby stores with items you need to purchase. I have plenty of ideas, I just need time.

Stay tuned.

=======================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?

Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com

Follow my Facebook Page
Check out my code on GitHub
=========================