Event-Driven Programming – CraftWithCodeWiz

November 4 2023

The Essence of Event-Driven Programming in Android App Development

sanjaybhatikar AppInventor Android, Animation, Callback, Canvas, Event-Driven Programming, Event-Handler, Molemash, Sprite 0

Imagine you are eagerly awaiting a package delivery at your doorstep. In this scenario, you have two distinct approaches to staying informed about when your eagerly anticipated package arrives. First, you could repeatedly venture to your doorstep, hoping to catch a glimpse of your precious cargo. Alternatively, you could simply relax and await the familiar sound of the doorbell, which signals the arrival of the deliveryman and your package. The moment the doorbell rings, you spring into action, promptly picking up your long-awaited package.

These two methods of package monitoring are symbolic of different paradigms in the world of programming. The event-driven paradigm, often exemplified by the doorbell scenario, is akin to following a set of instructions as if they were a “mad-lib,” constructed as follows: “WHEN event occurs, DO action.” In this construct, the first part represents the event, while the second part signifies the callback or action to be executed in response to the event. But how does this analogy relate to the realm of Android app development?

In the context of Android app development, this paradigm is of paramount importance. It hinges on the execution of a callback function when a specific event transpires. These events can be intrinsically tied to the actions of the phone’s user, such as tapping the screen or swiping a finger across it. However, user interactions are just one facet of the vast spectrum of events. Another category of events revolves around time, driven by clocks and timers. The callback function springs into action when a predetermined time interval lapses, and the timer signals its completion.

To illustrate this concept, let’s consider an app known as “Mole Mash”. This app employs a timer to move the mole to a random location on the screen. The objective is to stab the mole and score points. In this instance, event-handler implements the logic as follows: WHEN timer goes off DO move the mole to a random location. In AppInventor, the green block represents the event-handler that sets off the timer at regular intervals. The interval is a configurable property and can be set manually or programmatically. The purple block inside is the callback procedure that moves the mole to a random location. The callback uses a canned procedure for random number generation to set the X and Y coordinates of the mole independently. Thus, the mole comes to life!

In essence, event-driven programming in the context of Android app development hinges on the idea of responding to various events, whether initiated by the user’s actions or the passage of time, by executing predefined actions or callbacks. This flexible and dynamic paradigm enables developers to create interactive and responsive applications that cater to a multitude of scenarios and user experiences.

📱 Explore Android App Development with AppInventor! 🤖

Discover the exciting world of Android app development with AppInventor, where you can build practical skills while crafting innovative apps. Our class offers a hands-on approach to learning key software concepts, such as event-driven programming. Throughout the course, students have the opportunity to create a new app every week, gaining valuable experience and insights into the world of app development. Join us on this coding journey and unlock the potential of interactive, responsive applications. Dive into the world of possibilities with AppInventor! 💡👩‍💻📦

September 11 2023

Handling UI Events in Jetpack Compose

sanjaybhatikar Android Native, Jetpack Compose, Kotlin Event-Driven Programming, Jetpack Compose, Model-View-View-Model, Responsive UI, View Model 0

When crafting an Android app, one essential aspect to consider is the seamless handling of user-generated events within the User Experience. The Model-View-ViewModel (MVVM) architecture provides an elegant solution for streamlining event-handling by centralizing it within the View Model. Let’s explore the structure of an onEvent function, which serves as the hub for managing these events.

	fun onEvent(event) {
	/* TODO */
}

To effectively register callbacks for each event, a when block is utilized. This block checks the event’s signature and triggers the associated callback when a match is found. However, identifying event signatures can be complex due to the diverse nature of events, including button clicks, phone rotations, finger drags, and keyboard inputs.

	fun onEvent(event) {
		when(event) {
			is OnTextClicked -> {
				
			}
			is OnKeyboardInput -> {
				
			}
			is OnButtonPressed -> {
				
			}
			else -> Unit
        }
    }

To address the challenge of passing a multitude of diverse events to the onEvent function while preserving the uniqueness of each user action, a sealed class is introduced, to wrap around various events while offering a unified interface for event handling. Here is an example:

	sealed class ScreenEvent {
    data class OnItemClicked(val item: Item): ScreenEvent()
    data class OnItemNameChanged(val itemName: String): ScreenEvent()
    object OnItemAdded: ScreenEvent()
}

In this example, the ScreenEvent class encapsulates various events, each represented by a subclass. It encapsulate events like OnItemClicked, which might represent a user’s interaction with a UI element, OnItemNameChanged, signifying keyboard input, or OnItemAdded, indicating an action initiated through a floating button. Essentially, ScreenEvent comprehensively covers all permissible user actions mediated by the UI

Within this structure, data classes play a crucial role by holding event-specific information, ensuring that the View Model can process and respond to these events effectively. Conversely, objects within this class serve as signals, indicating when an event occurs without requiring additional data.

Typically, the ScreenEvent class is placed within a presentation package, along with the screen components and View Model, to maintain a clean and organized project structure.

With the groundwork laid by ScreenEvent, we are now well-prepared to further expand the functionality of the View Model, enabling it to seamlessly handle a wide range of user interactions and events.

	fun onEvent(event: ScreenEvent) {
        when(event) {
            is ScreenEvent.OnItemClicked -> {

            }
            is ScreenEvent.OnItemNameChanged -> {
                
            }
            is ScreenEvent.OnItemAdded -> {
				
			}
            else -> Unit
        }
    }

What remains now is to flesh out the callbacks. There are two types of code that go in here:

CRUD operations: These are operations to create, retrieve, update, or delete app data. Such data are typically found locally in the app’s database or remotely in Cloud storage. These operations are not directly implemented in the View Model. Instead, the MVVM architecture employs a repository pattern, offering methods for CRUD operations within the repository. This separation ensures that any changes or modifications to the management of storage can be isolated to the data layer where the repository is implemented.
One-time UI events: These events involve actions such as displaying a message in a Snackbar or navigating to a different screen. Achieving this necessitates the use of LaunchedEffect() within the Composable to observe UI-triggered events. Additionally, a dedicated class, UIEvent, is introduced to encapsulate the variety of View Model-triggered events.

The final step in the process involves calling these methods within the Composable, associating them with specific UI elements to create a cohesive and responsive User Experience.

In conclusion, the Model-View-ViewModel (MVVM) architecture, with its central onEvent function, offers a comprehensive solution for managing user-generated events in Android app development. By encapsulating event-handling within the View Model, developers can streamline the process of responding to diverse user actions, from button clicks to phone rotations and keyboard inputs.

Notably, any changes in UI state variables, neatly encapsulated within the View Model, are efficiently reflected in the User Interface, ensuring a responsive and dynamic user experience. In our upcoming post, we’ll delve deeper into View Model-triggered events, often referred to as one-time events. These events encompass crucial aspects like navigation events, showcasing how the MVVM architecture seamlessly bridges the gap between the View Model and the UI, providing a robust foundation for creating exceptional Android applications. Stay tuned for more insights into this exciting topic.