Rosalyn

Detecting Risky Zones on a Route: Lessons from Old Notes

Sat, 26 Sep 2026 12:01:35 +0000

Detecting Risky Zones on a Route: Lessons from Old Notes

While cleaning at home the other day, I found a stack of old notebook pages filled with sketches and scribbled ideas from years ago. They belonged to a navigation project where the goal was to generate safer routes by avoiding high-crime areas. Looking through them again made me realize how much manual research and trial-and-error went into something that, with today’s AI tools, would probably be solved far more quickly. Still, the core concepts remain interesting, so I decided to share them.

Starting with GeoBounding Boxes

The process began with the fastest route returned by the routing engine. I extracted its bounding latitude and longitude values and used them to request nearby Red Zones from the backend. Those zones were then treated as banned areas so the engine could apply a dynamic penalty and return a safer alternative.

The real question came next: once a route polyline arrived from HERE, how could I reliably detect whether it crossed a Red Zone?

A typical sketch looked like this: a large rectangle representing the overall map bounds, a diagonal line running from point A to point B (the route), and a shaded irregular polygon sitting in the middle that the line cut through. The problem was obvious—polylines often contained more than a thousand points, so a naïve check would be too slow.

Orientation and Bounding Boxes

To keep things efficient I first calculated the orientation of travel (bearing) for each segment and built a tight bounding box around it. The box was defined by its southwest (SW) and northeast (NE) corners:

SW = minimum latitude + minimum longitude
NE = maximum latitude + maximum longitude

Bounding Box

I also had to understand the different “norths”:

True North – the Earth’s rotational axis; meridians of longitude converge there.
Magnetic North – the direction a compass needle points.
Grid North – the direction of the map’s grid lines (usually close enough to True North that it can be ignored for most navigation).

The angular difference between True North and Magnetic North is called declination. Map bearing itself is simply the horizontal angle measured clockwise from north to a given direction (for example 45° or 320°).

When the route segment ran almost parallel to one axis, the bounding box needed to be kept thin; otherwise the overlap test became too loose.

Declination

Map Bearing

Precise Intersection Tests

After the quick bounding-box filter, more accurate algorithms were required:

Ray-casting
Winding-number
Angle summation

These answered the fundamental geometric question: does a given point (or line segment) lie inside the Red Zone polygon?

Practical Constraints

HERE imposed strict limits—only about 40 coordinates were allowed for a banned area—so I had to run a polyline simplification algorithm (Douglas-Peucker style) before sending the zones. There was also a 128-waypoint limit on routes that was expected to be raised in later releases.

Polyline points in a Polygon

Because the same routes needed to appear on both Android and iOS, the HERE API calls were moved to the backend. Traffic data, speed limits and voice guidance were layered on top of the geometric checks.

Density of risk was sometimes estimated by counting the number of incident points that fell inside a search radius, giving a quick visual sense of how “hot” an area was.

Density based on the number of points inside the circle

All of these pieces—bearing calculations, carefully constructed SW/NE boxes, polygon simplification, and classic point-in-polygon tests—worked together so the app could decide, in real time, whether a route should be labelled risky or safe.

That’s it! Going through those old notes was a reminder of how much pure geometry and careful constraint handling went into something that felt straightforward on the surface. It was overwhelming at the time getting all the pieces to fit, but looking back it was also a lot of fun—and definitely something I’m glad I dug into!. 🚀

From Kotlin to Flutter: My Journey Building an iOS App in 2 Months

Thu, 30 Jan 2025 12:01:35 +0000

At my job, I was given an exciting challenge: to develop a new iOS app in Flutter, with just two months to deliver an MVP. The catch? I had only dabbled in Flutter before with small experiments here and there (my main experience is in Kotlin/Java).

Despite the learning curve, I embraced the project head-on. One of the most time-consuming parts of the process was configuring flavors, setting up Xcode, and navigating Apple’s requirements for publishing. Understanding the nuances of the iOS ecosystem took some effort, but once I got through it, everything started falling into place.

Other of the biggest shifts I had to adapt to was moving from imperative UI development to declarative UI with Flutter’s widget-based approach. Coming from a world where UI updates are done through direct manipulation of views, thinking in terms of widgets, state, and composition took some time to grasp.

What I love about imperative programming is the fine-grained control it offers over UI construction and state management since it operates at a lower level, so you can dictate exactly how and when things should happen. However, this also makes it more complex, with a higher risk of tightly coupled logic that can be harder to maintain and easy to mess with the app’s performance.

On the other hand, declarative programming feels like a breath of fresh air. The higher level of abstraction allows you to simply describe what you want the UI to look like, rather than worrying about how it gets there. While it took some time to rewire my thinking, I found it much cleaner and more intuitive once I embraced it.

To put it in simple terms:

Imperative programming is like manually assembling a LEGO set piece by piece, deciding exactly how each block connects. You have total control, but it requires careful planning.

val button = Button(this).apply {
    text = "Click me"
    setTextColor(Color.WHITE)
    setBackgroundColor(Color.parseColor("#4CAF50")) // green
    setPadding(32, 16, 32, 16)
}

layout.addView(button)

Declarative programming is like giving instructions to a 3D printer—you describe the final object, and the system figures out the best way to build it for you.

ElevatedButton(
  onPressed: () {},
  style: ElevatedButton.styleFrom(
    backgroundColor: Color(0xFF4CAF50), // green
    foregroundColor: Colors.white,      // text color
    padding: EdgeInsets.symmetric(horizontal: 32, vertical: 16),
  ),
  child: Text('Click me'),
)

And in just 6 weeks, I not only completed the MVP but also successfully published the app to the App Store 2 weeks ahead of the deadline. It was a rewarding experience that pushed me outside my comfort zone, reinforcing that adaptability and problem-solving matter just as much as technical expertise.

This project not only deepened my understanding of Flutter but also proved that with the right mindset, shifting tech stacks isn’t as daunting as it seems. Looking forward to more cross-platform adventures! 🚀

Strategy Pattern

Wed, 19 Apr 2023 12:01:35 +0000

Imagine you’re driving to a destination, and you have several routes to choose from: the highway, the scenic route, or the city streets. Each route has its own way of getting you there, with different speeds, views, and potential traffic. Here, the goal is to reach your destination, and the strategy is the route you choose. Depending on the situation (like time of day or traffic), you might decide to change routes to fit your needs. This way, you can adapt your approach at any time without changing the main goal—just like the Strategy Pattern lets you change specific behaviors in your code without altering the overall structure.

Something similar happens on an app, you may have several sources that you want to interchange without requiring major updates to the code. Let’s say an app stores data locally using a database like SQLite, but later decides to switch to Room. Ideally, this change would only require swapping out the database layer without affecting the rest of the code. The Strategy Pattern makes this possible, allowing your app to switch between different implementations of a specific function without breaking or changing the code that depends on it.

Let’s say your app stores data locally using a database like SQLite but later you decide to switch to Room, imagine the update if all the code is highly attached such as, you have to make changes is every single class that connect and calls the database (what a pain!). Ideally would be something like unplugging a black cable and plugging a red one to the outlet, well, this is where the Strategy Pattern comes to rescue.

So, what is exactly the Strategy Pattern?

The definition says that, Strategy Pattern is a behavioral design pattern that defines a family of algorithms, encapsulates each one as a separate class, and makes them interchangeable. In other words, the Strategy Pattern lets you switch between different behaviors or algorithms at runtime by swapping out the implementation behind the scenes, without needing to modify the main code.

It consists of three main components:

Context: The main class that uses different strategies. It holds a reference to the strategy interface and delegates the work to the current strategy.
Strategy Interface: The common interface that each strategy implements. This interface ensures that the Context can use any strategy without knowing the specifics of each.
Concrete Strategies: Classes that implement the strategy interface, each containing a unique way to execute the algorithm or behavior.

When Should You Use the Strategy Pattern?

The Strategy Pattern is perfect when:

You have multiple ways to perform a similar action and want flexibility in choosing which to use.
You want to avoid large conditional statements (e.g., if-else or switch-case) for choosing between behaviors.
You want to enable interchangeable components in your app, so switching between them is seamless.

Enough of concepts, let’s code!

We’re going to create a pattern for sending user’s event to different analytics providers (let’s say Google Analytics, Amplitude, Amazon PinPoint), this allows you to measure and understand how users interact with your website or app.

Step 1. Create the strategy interface:

interface AnalyticsHelper {

    fun sendEvent(event: Event)
    fun sendUserProperties(key: String, value: String?)
    fun setUserId(id: String)
}

Step 2. Context

class AnalyticsManager(private val providers: List<AnalyticsHelper>) {
    fun sendEvent(event: Event) {
        providers.forEach {
            it.sendEvent(event)
        }
    }

    fun sendUserProperties(key: String, value: String?) {
        providers.forEach {
            it.sendUserProperties(key, value)
        }
    }

    fun setUserId(id: String) {
        providers.forEach {
            it.setUserId(id)
        }
    }
}

Step 3. Concrete strategies

class AnalyticsFirebaseImpl(private val application: Application): AnalyticsHelper {

    private var firebaseAnalytics: FirebaseAnalytics? = null

    init {
        initializeFirebaseAnalytics()
    }

    private fun initializeFirebaseAnalytics() {
        firebaseAnalytics = FirebaseAnalytics.getInstance(application)
    }

    override fun sendEvent(event: Event) {
        firebaseAnalytics?.logEvent(event.name, convertToBundle(event))
    }

    override fun sendUserProperties(key: String, value: String?) {
        firebaseAnalytics?.setUserProperty(key, value)
    }

    override fun setUserId(id: String) {
        firebaseAnalytics?.setUserId(id)
    }

    private fun convertToBundle(event: Event): Bundle {
        return Bundle().apply {
            putString("Description", event.description)
            event.parameter_string?.let {
                for ((paramKey, paramValue) in it) {
                    putString(paramKey, paramValue)
                }
            }
        }
    }

}

Now you’re ready to customize it! Thanks for reading.

You can find a sample here GitHub

Sending data to other apps with Sharesheet

Thu, 23 Jun 2022 12:01:35 +0000

A few days ago I needed to be able to send a link to an external app, and Intents are perfect for such task, Android through the Sharesheet allows you to do so (unless you want to implement a custom one).

Just need to call Intent.createChooser(intent, null) and start the activity; now, if you want to be able to detect which app the user chooses to share the link with, we would need to include the broadcaster (only available from API 22) and once the onReceived is called, obtain the ClickedComponent by getting the extra from the intent with Intent.EXTRA_CHOSEN_COMPONENT, this will give you access to the package name of the app selected.

The main call would look something like this (Don’t forget the MIME type, in my case is “text/plain”):

val pendingIntent = PendingIntent.getBroadcast(context, 0,
   Intent(context, ShareSheetBroadcastReceiver::class.java), PendingIntent.FLAG_MUTABLE)
Intent.createChooser(intent,  null, pendingIntent.intentSender)

On your BroadcastReceiver onReceived method:

val clickedComponent = intent?.getParcelableExtra<ComponentName>(Intent.EXTRA_CHOSEN_COMPONENT)

clickedComponent?.let { componentName ->
    packageManager?.let {
        val appInfo = packageManager.getApplicationInfo(
            componentName.packageName, PackageManager.GET_META_DATA)
        packageManager.getApplicationLabel(appInfo) as String
    }
}

What about if I want to listen when the user decides to just copy the link? In that case, we could do so by listening changes on the clipboard:

val clipManager = context?.getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager
clipManager.addPrimaryClipChangedListener {
    Timber.tag("FirstFragment").d("Link shared via Copy link")
}

The logcat output would be:

D/FirstFragment: Link shared via copy link
D/ShareSheetBroadcastReceiver: Sharing the link via: WhatsApp
D/ShareSheetBroadcastReceiver: Sharing the link via: Messages

You can find a mini example here GitHub

Pigeon image credit: iStockphoto/IEEE Spectrum

My encounter with Unreal Engine

Sat, 19 Mar 2022 12:01:35 +0000

Once, at one of my jobs we had a brief period where we were allowed to experiment with any side project we’d like, so I decided to go with the AR (Augmented Reality) and see what could bring for the company, that’s how I ended up creating some demos with Unity and Vuforia. Why Unity and not ARCore? Well, basically I felt that ARCore with Android Studio didn’t have enough documentation, nor the community is large enough in comparison to Unity, which is vast. At the end, I enjoyed the experience with AR and wanted to continue to explore it.

Few years later, a friend of mine told me about this platform named Unreal Engine; although he uses it for architectural purposes, this engine created by Epic Games is also used for AR, game creation, animation, 3D content, movies… I mean, it was used to create the landscapes for The Mandalorian (enough to get my attention? Hell yeah!).

Images credit Unreal Engine

I then decided to follow some tutorials. As a beginner, I looked for those that teaches you the basic functionality and helps you to, step by step, create a small game (as you might know, the best way to learn is with your hands on!).

Coming from a world where I code everything (even the UI), I felt weird coding visually: dragging the nodes, the wires for connection, setting properties, etc (my brain thinks of them as classes, functions…); and that’s one advantage, you don’t need to know a programming language (in this case C++ for Unreal) to be able to release an app. Here some of basic concepts I have grasped:

1. Actor

Is any object that can be placed into the world (or level).

2. Blueprints

Is an asset that contains data and instructions, allowing you to add behaviors to the object; since it’s based on a node system, you just need to create nodes and connect them (that’s your “coding” time). In a game is used to track the score, health, energy of a character, etc.

3. Node

Can have inputs and outputs. So it’s like a function that receives parameters, processes the data and returns the result

4. Mesh

Is a collection of vertices, edges, and faces that describe the shape of a 3D object, for example, an apple. There’s 2 types:

Static mesh: doesn’t bend, deform or change shape in any way. Can move on the screen, but can’t be animated
Skeletal mesh: which is for objects with moving parts, such as a character

5. Material

Determines how the surface of something looks, is like a layer you wrap the object with; in the case of the apple, will define its color or the texture (a 2D image).

Something funny I struggled with? Handling the editor controls on my Mac! Even though I have a mouse, I’m more comfortable using just the trackpad

Move forward/backward

Single finger press on the trackpad and drag

Move left/right

Single finger press on the trackpad and drag to the left or right

Move Up/Down

Single finger press on the trackpad + key press (Q for down, E for up)

You can find more controls here: UE Viewport Controls

Time to install the APK

Deploying the project on my device was straightforward (connect the device to the laptop and hit Play), now I wanted to build the app; went to the Package Project and selected the option for Android… nice! Just take the .apk and install it as usual, right? Well, no, here is the difference with a project built on Android Studio: if you drag the file into your device and try to execute it, you will receive errors such as: “No Google Play Store Key. No OBB found and no store key to try to download. Please set one up in Android Project Settings”

Why this occurs? Because the option “Package game data inside .apk?” was unchecked, the project built into different files (.apk, .command, .obb), all necessary for the project to run. You can check the option, and the apk will be generated with all those files contained within.

I must admit being shocked when I noticed that my basic project’s size was around 700MB!, on Android you are always fighting to keep your app as light as possible.

So what’s the way to install the apk? Through terminal, by running the .command file while the device is connected to the laptop.

 $ Install_[ProjectName]_Development_armv7-es3.command

That’s it! Was overwhelming getting all the information needed to start and understand UE; nevertheless, it has been fun, something I’ll definitely continue digging into.

Custom Switch

Thu, 11 Nov 2021 00:00:00 +0000

The Switch or Toggle is a widget that defines the state of a button between 2 values: selected and not selected, although typically is used to define the ON/OFF state. On Android you can use:

SwitchCompat. From the Appcompat library, is a subclass of CompoundButton.
SwitchMaterial. From the Material library, extends from the SwitchCompat. [Update: deprecated from v1.7.1 to MaterialSwitch to follow naming convention of MaterialButton and MaterialCardView]

Anatomy of the switch:

But what if you don’t want the style that comes by default? What if you want to customize it? Well, let’s see how we can approach it:

Step 1: Add the switch to your activity/fragment xml

<androidx.appcompat.widget.SwitchCompat
        android:id="@+id/customSwitch"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="42dp"
        android:text="@string/switch"
        android:textSize="16sp"
        app:switchPadding="10dp"
        android:checked="false"
        app:layout_constraintTop_toBottomOf="@+id/titleText"
        app:layout_constraintStart_toStartOf="parent" />

Step 2: Add a drawable for the track

Create a drawable file, let’s name it “switch_track”, add <selector> as its root element and here we’ll define 2 more drawables for its false and true state:

<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_checked="true"
        android:drawable="@drawable/track_on"/>
    <item android:state_checked="false"
        android:drawable="@drawable/track_off"/>
</selector>

The true/false drawable states are going to be the similar, the difference will be the icons to display for each one of them (if you want a more sharped angles, you can remove the radius attribute):

For track_on.xml:

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_checked="true">
        <shape android:shape="rectangle">
            <gradient
                android:startColor="@color/purple_200"
                android:endColor="@color/purple_700"/>
            <size android:width="20dp"
                android:height="9dp"/>
            <corners android:radius="20dp"/>
        </shape>
    </item>

    <item android:drawable="@drawable/ic_music_on"
        android:right="77dp"
        android:left="18dp"
        android:top="7dp"
        android:bottom="8dp"/>
</layer-list>

For track_off.xml:

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_checked="true">
        <shape android:shape="rectangle">
            <solid android:color="@color/purple_200"/>
            <size android:width="20dp"
                android:height="9dp"/>
            <corners android:radius="20dp"/>
            <stroke android:color="@color/purple_200"
                android:width="1dp"/>
        </shape>
    </item>

    <item android:drawable="@drawable/ic_music_off"
        android:right="18dp"
        android:left="77dp"
        android:top="7dp"
        android:bottom="8dp"/>
</layer-list>

Why do we add a layer-list on above examples? Because we want to shape the track and we want to add an image to it, so we would need for that a list of drawables represented by the <item> element.

Step 3: Add a drawable for the thumb

Same process as with the track, create the “switch_thumb” xml file and add the custom drawables with the <selector> as root element:

<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_checked="true"
        android:drawable="@drawable/thumb_on"/>
    <item android:state_checked="false"
        android:drawable="@drawable/thumb_off"/>
</selector>

And let’s define the true/false states:

For thumb_on.xml:

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_checked="true"
        android:top="2dp"
        android:bottom="2dp"
        android:right="2dp"
        android:left="2dp">
        <shape android:shape="rectangle"
            android:dither="true"
            android:useLevel="false" android:visible="true">
            <solid android:color="@color/white"/>
            <size android:width="15dp"
                android:height="9dp"/>
            <corners android:radius="20dp"/>
        </shape>
    </item>
</layer-list>

For thumb_off.xml:

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_checked="true"
        android:top="2dp"
        android:bottom="2dp"
        android:right="2dp"
        android:left="2dp">
        <shape android:shape="rectangle">
            <solid android:color="@color/white"/>
            <size android:width="55dp"
                android:height="24dp"/>
            <corners android:radius="20dp"/>
        </shape>
    </item>
</layer-list>

Step 4: Add your custom drawables to the switch

Now that we have created our xml files, we need to reference them in the switch through the attributes app:track and android:thumb:

    <androidx.appcompat.widget.SwitchCompat
        android:id="@+id/customSwitch"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="42dp"
        android:text="@string/switch"
        android:textSize="16sp"
        app:switchPadding="10dp"
        android:checked="false"
        android:thumb="@drawable/switch_thumb"
        app:track="@drawable/switch_track"
        app:layout_constraintTop_toBottomOf="@+id/titleText"
        app:layout_constraintStart_toStartOf="parent" />

It should look like this

Now you’re ready to customize it! Thanks for reading.

You can find a sample here GitHub

Switch image credit: Electrical Expert

Printing Text and Images on Zebra.

Mon, 09 Aug 2021 12:01:35 +0000

This basic project helps to connect, via bluetooth, to a Zebra’s printer and emit a text and an image.

When I was brand new on the Android world, I got my first work challenge: to print the receipts with the Zebra’s printers; as with any receipt, I needed to print the company’s logo and all products bought with their prices and total. These printers are compact and easy to carry, ideal for receipts, barcodes, labels, etc.

It took me a while to understand the manuals, the language and how to work with margins and format text on the printers; this is the reason why I decided to create a project, so I could publish it and give access to anyone else that was struggling just like me.

The project consists of a library and a simple app that consumes it by printing with CPCL language, and it was tested on a Zebra RW420. Currently is not maintained because I don’t have access anymore to the Zebra printers; nevertheless, I hope it helps you to create a base.

At the end I was able to print a more formatted receipt, like this:

You can find the code here GitHub

Rosalyn

Detecting Risky Zones on a Route: Lessons from Old Notes

Detecting Risky Zones on a Route: Lessons from Old Notes

Starting with GeoBounding Boxes

Orientation and Bounding Boxes

Precise Intersection Tests

Practical Constraints

From Kotlin to Flutter: My Journey Building an iOS App in 2 Months

Strategy Pattern

So, what is exactly the Strategy Pattern?

When Should You Use the Strategy Pattern?

Sending data to other apps with Sharesheet

My encounter with Unreal Engine

1. Actor

2. Blueprints

3. Node

4. Mesh

5. Material

Dealing with Navigation Controls

Time to install the APK

Custom Switch

Anatomy of the switch:

Step 1: Add the switch to your activity/fragment xml

Step 2: Add a drawable for the track

Step 3: Add a drawable for the thumb

Step 4: Add your custom drawables to the switch

Printing Text and Images on Zebra.