Today I’d like to share with you how we can design a serverless app to be able to invoke third-party APIs outside of its native scope, without the need for a dedicated backend and its server management.
Let’s suppose we have a mobile app written natively for Android and we’re about to roll out an iOS version. Excluding using some cross-platform technology, it would be useful to abstract the business logic from our native apps and having it available, to both, in a dedicated place.
For this, we might want to implement some (or all) of the following…
Today I’d like to share with you how we can create a CRUD design for our apps’ access to (local) database resources.
Let’s assume we’re going to implement this in an E-Commerce Marketplace app.
This article’s valid for any database provider, but, for this exercise, we’re going to use ObjectBox. I’m using it in my MapCrumbs app and am quite happy with it because it fulfills the requirements I usually have for a database:
As for the coding part, we’re going to use Kotlin for this tutorial.
The first thing we need to do is to configure the project to include ObjectBox. To prevent deviating from this article’s aim, please follow the steps listed here. …
Today I’d like to share with you some examples of different types of OOP (Object-Oriented Programming) inheritance and where each might be useful to use.
When talking about inheritance, I like to separate between what I call Structure inheritance (SI) from Functionality inheritance (FI). The first one, as the name suggests, is to what family (structure) a type belongs to, whereas the latter relates to what sort of abilities (functionalities) a type needs to have.
There are several types of inheritance, but we’re going to focus on the ones I find more useful:
Let’s suppose we have a list of currencies that our program supports, and we’re representing them in a typical fashion: using an enum.
Now, for every currency available, we’ll have certain functionalities associated with it (getting its name, symbol, its value against another currency, etc).
We could be tempted to create a single type, with functions for each functionality and using a switch/case statement in every one of them.
Even though we cannot (and should not) fully escape from using that approach, we should minimize its use, for at least the following…
Today I’d like to share with you how we can make use of the EventBus pattern, a subset of the Publish-Subscribe pattern, for decoupled communication between different components.
This pattern can be a good approach when you want to send (publish) data from ComponentA and receive and react to it (subscribe) from ComponentB.
The best analogy I could think of for this was of a ticket machine providing you your ticket number - after you’ve ordered that delicious meal at your local fast-food chain restaurant -, and then presenting on a screen what ticket number holder can go and collect their meal. …
Today I’d like to share with you how we can make use of the Builder Pattern to get more code flexibility, which can be very useful when presented with certain technical challenges.
This pattern can be a good approach when you have to create (assemble) an object that has one of these two structure types:
The best analogy I could think of for this was of a car assembly line. You can assemble it differently, one having an automatic transmission and another one having it manual (etc), but, at the end of the assembly line, it will still be a car, whatever the characteristics it has with it. …
Today I’d like to share with you how I use intents to launch some of the most popular navigations apps from my own Android app.
First of all, you should identify your own requirements, and ask yourself the following questions:
If you find yourself in the first scenario, then perhaps this is not the tutorial for you, for that situation. But, if you need help implementing for the second one, then keep on reading.
I’m sure this will not be anything you’ve never heard before…but social networks have the potential to be either incredible or the opposite.
For starters, I can say that I’ve never been a true social player, being more of an observer user, just doing some of these basic tasks:
Having said that, I still managed to spend a lot of hours just, you know, scrolling through.
For quite some time, this felt right for me and of no concern. But, this was in a major conflict with another part of myself: the wanting I felt to use my time in a more useful way. …
I recently had the challenge to add a React-Native (RN) app to an existing Android app.
While searching for any supporting documentation, I came to realize that everywhere I looked advised/instructed the developer to take the existing app and just put it inside a new/existing RN project.
This includes the official documentation from Facebook, when they say:
1. Set up directory structure
To ensure a smooth experience, create a new folder for your integrated React Native project, then copy your existing Android project to an
And for many developers, I’m sure that’s an acceptable choice to take. But, in my case, I had more to lose than to gain from that, from having to adapt both native teams to a new repository, a new way of working, to lose track of previous changes, to have to change the build pipelines and tasks, etc. …