💡
It is crucial to remember that in a real-world, production environment, you should always enable secure connection and set up proper certificates. The setup I’m showing here is used for testing and experimentation only.
**Next** - in the manifest, add this file under networkSecurityConfig
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766399284676/7c9b4627-a24f-438d-8516-7c9f6e8c8e1c.png align="center")
---
## Create a Foreground Service
Creating a foreground service with a restart mechanism ensures the server will run continuously. The order matters here so…
1. Create a notification channel.
2. Build a notification.
3. Start a foreground service.
If the service is killed by the system, it will be recreated and **onStartCommand()** will be called with a **null** intent.
```kotlin
private fun createNotificationChannel() {
val serviceChannel = NotificationChannel(
CHANNEL_ID,
"Server Service Channel",
NotificationManager.IMPORTANCE_DEFAULT
)
val manager = getSystemService(NOTIFICATION_SERVICE) as NotificationManager
manager.createNotificationChannel(serviceChannel)
}
private fun buildNotification(): Notification {
return NotificationCompat.Builder(this, CHANNEL_ID)
.setContentTitle("Server Service")
.setContentText("Running...")
setSmallIcon(R.drawable.ic_download)
.build()
}
private fun startForegroundService() {
startForeground(NOTIFICATION_ID, buildNotification())
}
companion object {
const val CHANNEL_ID = "ServerServiceChannel"
const val NOTIFICATION_ID = 1
}
```
### Restart Foreground Service
When the system restarts a service that returned **START\_STICKY**, it calls **onCreate()** and then **onStartCommand()** again. In this restarted onStartCommand() call, the intent parameter will be null (there should not be any pending start commands here). Then **createNotificationChannel()** and **startForegroundService()** will re-establish the service as a foreground service with its persistent notification.
```kotlin
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
Log.d("ServerService", "restarting server service")
startForegroundService()
return START_STICKY
}
```
### Run the Foreground Service
The easiest way is to start the service from the main activity in the onCrated() method.
```kotlin
private fun runRestfulService() {
val intent = Intent(this, ServerService::class.java)
startService(intent)
}
```
At this point you should see a notification from the foreground service informing about the running server.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766399312668/c68fc6e4-6813-4375-8616-c95dfab501dc.png align="center")
---
## Data aggregation and display
Before we jump into the service portion, I want to emphasize that aggregating and displaying data from APIs, while running the service concurrently, is perfectly acceptable with this setup. This is a key benefit of running an Android and Ktor service simultaneously.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766399333124/c61f3bf8-b6c0-4d5c-8f23-aa0a8fbbd47a.png align="center")
---
## Local CRUD operations
While my Google and Outlook calendars contain numerous events, not all include notifications, making it easy to overlook some. Having a single home for all these events would definitely help me stay on top of things.
To implement this, I created a POST endpoint in the service that accepts multiple events. When it comes to a **concurrent writes** to the database, several alternative solutions exist:
* **PostgreSQL**, which utilizes Multiversion Concurrency Control (MVCC).
* **MongoDB**, which employs MVCC and internal locking mechanisms.
* **Firestore**, which implements optimistic concurrency.
A simpler alternative when using Room is to use a **Mutex**. If data loss during unexpected service termination is acceptable, periodically or conditionally (e.g., when a ConcurrentHashMap reaches a specific size) persisting data from a **ConcurrentHashMap** to the Room database is another viable option.
The GET endpoint retrieves all events from the database, splits them into old and new based on the current time, deletes old events in a thread-safe way, and responds with the list of new (upcoming) events.
```kotlin
get {
try {
val now = Clock.System.now()
val events = eventDao.getEvents().map { it.toEventDto() }
val oldEvents = events.filter { it.date < now }
val newEvents = events.filter { it.date >= now }
// Delete old events from the database in a batch operation
if (oldEvents.isNotEmpty()) {
eventMutex.withLock {
oldEvents.map { it.id }.forEach { id ->
eventDao.deleteEvent(id)
}
}
}
call.respond(newEvents)
} catch (e: Exception) {
call.respond(HttpStatusCode.InternalServerError, "Failed to retrieve events: ${e.message}")
}
}
```
We also use eventMutex.withLock for `post("/single")` and `post("/multiple")` POST events endpoints to ensure thread-safe operations when writing to the database.
```kotlin
post("/multiple") {
try {
val newEvents = call.receive