Jetpack Compose session handling: God, protect me ლ(ಠ益ಠლ)ლ(ಠ益ಠლ)
Hi, there. I think I’ve been trying to journal a little bit of my life for a while now. Actually, I think I’ve tried to do so more than 5 times to this point. I tried writing on a notebook and recording videos. And, for some reason, I always quit it, LOL.
There’s a way I haven’t tried out so far, though. Andddddddddd, yes, you guessed it right. Writing on a website.
This thought of having a diary-like website has been on my mind for almost a year now, but I never really gave it a chance because I didn’t feel like using HTML and CSS or even React to build the website. Andd yes, I know It sounds contradictory, specially because I would like to make web development my bread and butter, but that’s different. I just didn’t want to build a personal website using React or HTML. Sooooooo, I decided to use WordPress instead, and, as I don’t really know too much about it, I will learn even moree and in a more refreshened way. Sooo, let’s cut to the chase, to the juicy gossip ლ(´◉❥◉｀ლ)ლ(´◉❥◉｀ლ), shall we
DUDEE, where do I even begin. I feel frustrated, I feel bad, I feel like jumping off of a buildinggggg.
As of now, April 28th, I have a project to submit. It is a Kotlin android app with Jetpack Compose.
Now, the thing is not that the project’s an android app itself (although we have to build it from a Behance template we like, and, to be honest, almost all designs look intimately cool for me, lol), but the fact that, for bad or good, I “decided” to complicate it a little TOO much.
I made the beautiful decision of trying to make a Weekie Mochi app for android. Weekie Mochi is an image board app, like 2chan or 4chan. I usually refer to it as a forum app.
The website of Weekie Mochi itself is built in React. So, it doesn’t handle database interactions or such. Instead, it consumes an API (a weekieMochi API btw, not a third-party’s one).
The thing is, the API we chose to consume from the website (because there are two options: JWT API and Cookies API) was the one that handled sessions through JSON WEB TOKENs. Andddd, as anyone who’s familiar with APIs might know, when you use JSON WEB TOKENs for authentication, you normally send them in an “Authorization” header with each request. And well, I worried so much about the Authentication thing that ended up making Unauthenticated Users able to just access two endpoints in the WHOLE API.
My professor told us to consume a little table from the app with, maybe, just 10 records in it. But, nope, sir. I cannot. Because our beautiful API restricts access to unauthenticated users, so we cannot access any data unless we authenticate ourselves. Holy. And, yes, I could try adjusting the API. But it would be a lot of time. And I cannot afford that, and deep down I don’t want to, lol. It would be cool to have an android version of Weekiemochi after all. It would be useful for my CV ( ͡° ͜ʖ ͡°) ( ͡° ͜ʖ ͡°).
Even worse, I have to do it using Android Studio through Virtual Machines, which my school gives us access to (from Monday to Saturday, 2 hours of use at most and just 3 times a day), and using firebase studio (On Sundays).
Yes, I know if you do the math it is a good amount of time. But, there’s a lot of dead time in between. When I switch from one Virtual Machine to another, I have to upload the files I will use (because each booking will have a different Virtual Machine), fix the problems the VM’s android studio might have and also wait for the actual Gradle building and all that once the Android Studio works.
I had made a plan to complete a screen (an activity) each day, starting from today. So, by the end of this day, APRIL 28TH IN 2025 (actually, April 29th now because it’s 00:27), I was supposed to have finished at least one activity. Anddddd guess what? I was not able to do it.
I tried to implement the login functionality because, as you might’ve realized, we’ll use the Weekie Mochi API (the JSON WEB TOKEN’s one). Basically, I just built a simple login activity with a button and two TextField elements: One for the email and the other for the password. The main idea was to send a POST request to the “/users/login” of the API with the corresponding data when the button was pressed, and, in case there was an error, show the errors array on the screen (the API returns an errors array when an error occurs), otherwise, which would suggest it went well, show the generated token on the screen.
And It worked, but just for errors. It shows the errors elements just fine. Now, I will have to change some lines tomorrow to fix whatever is the reason why we don’t get the token on screen when credentials are correct.
I feel anxious because I will have to learn how to persist the token properly once I fix the error I mentioned before. All of this, tomorrow, there is no more chances. Tomorrow, not only will I have to fix the code (that I am not too familiar with either because our professor hasn’t taught us how to send bodies or data through POST methods from Jetpack Compose using the retrofit library), but also will I have to learn how to persist data in the app (Maybe, storing the token locally or sending it through bundle objects, I have no idea).
This is a huge thing that I have gotten into. But I have to do it. I want to achieve it.
Let’s gooooooooo, faith is unlimited thank God. So, let’s hope the best. I will try my best.
Omaiga gif to wrap this beautiful post up.
We’re out