[ `Android` ] : Rewrite app in google material design.

[baseplate-admin]

So currently the app is running kivy + webview.

This approach is suitable for our case, but i have seen slowdown in the app startup. So in this sense its better to go with something more native. By that i mean something thats not webview.

To do it our backend needs no change ( i presume ).

Now for our choices we have :

1. Kivy + KivyMD ( this is my preferable stack )
2. React-Native + React Native Paper
3. Ionic
4. Java | Kotlin

Now this is not our main priority so lets have a discussion before settling on anything final.

[baseplate-admin]

Hey @AKindWorld, i have profiled this Frontend we are making. Though it feels awesome on desktop. The performance on mobile phone ( specially with low end androids ), is very unsatisfactory.

So in near future we might need to make an android app to give a better experience to our users (lets keep it in our plan)

[AKindWorld]

i have profiled this Frontend we are making. Though it feels awesome on desktop. The performance on mobile phone ( specially with low end androids ), is very unsatisfactory.

ah yeah I checked it too. Lighthouse (Google's profiler) is of the same opinion it seems [for mobile].

Link: https://web.dev/measure/?url=https%3A%2F%2Fcoreproject.vercel.app

A big part of the performance & network issues may be caused by the image sizes & formats too. Currently the images I chose are very (very) large. The BSD poster alone was 11 MB in size. So we'll need to optimize it somehow - one way is to serve different image sizes for different device resolutions.

For example - load very small res images for mobile (~ 400x400), medium sizes for laptop screens (~ 1920x1080), and the larger ones only on 4K & higher screens (~ >2000x3000). This is not a complete solution since screen resolution is very deceptive, it's also the pixel resolution that matters a lot - but we'll have to do with what we have.

I'll also work on decreasing the image sizes and using better image formats. For now, you can also use this tip from Lighthouse - not sure if there are any limitations & other stuff though.

But yeah, all in all, an android app seems to be the best solution here. The design is pretty easy & adaptive (in fact the homepage & anime-info pages are already pretty much ready for native android apps). Another advantage is that we can use Material 3 built-in components to spice up the app's design to an extent - kinda like TachiJ2K. So all in all, yup I get your point.

^^

[baseplate-admin]

A big part of the performance & network issues may be caused by the image sizes & formats too. Currently the images I chose are very (very) large. The BSD poster alone was 11 MB in size. So we'll need to optimize it somehow - one way is to serve different image sizes for different device resolutions.

Actually "google" complains because we are not using "google" invented formats. JPEG is efficient enough. AVIF is not yet mature.

Also this is not the case at all. Check the profiler i have sent you. The CPU usage ie stuck at 99% in the JS engine. Its Javascript thats slow.

Check, in this image the last graph is for JavaScript. You can clearly see the spikes in CPU usage. The first tab is for network usage. So clearly network is not the main issue we are facing.

For example - load very small res images for mobile (~ 400x400), medium sizes for laptop screens (~ 1920x1080), and the larger ones only on 4K & higher screens (~ >2000x3000). This is not a complete solution since screen resolution is very deceptive, it's also the pixel resolution that matters a lot - but we'll have to do with what we have.

This is not a good solution in my opinion. Because we are delaying the inevitable.

---

A big reason of our performance issue lies in the stack we chose.

i. React ( The slowest JS Framework )
ii. Swiper
iii. Mantine.

This slowness was not visible with the v3 Branch because we didnt do so much with JavaScript ( adding css in JS, dynamatically calculating div size, dom diffing ). Now as the number of operations Have increased, we are starting to see the slowness in weaker processors.

Monkey patching image to get more performance will bring slight benefit IMHO. But i will take a look

---

But yeah, all in all, an android app seems to be the best solution here. The design is pretty easy & adaptive (in fact the homepage & anime-info pages are already pretty much ready for native android apps). Another advantage is that we can use Material 3 built-in components to spice up the app's design to an extent - kinda like TachiJ2K. So all in all, yup I get your point.

I will start working on the app after webpage is finished :D

---

Thanks :D

[AKindWorld]

ah yup, that makes sense.

For the images, even more than performance, network might become an issue. We will need to compress the images one way or the other, but yup. that can wait a bit more. Tbh the only times we need large images is for the carousel & the anime-info pages. Other than those, we're using pretty small & low-sized images.

As for performance, I'm not sure about the underlying tech stuff, so I can't say much about it.

One thing we can maybe do to improve performance is reduce the number of carousel entries & make the number optional in settings. If an user wants more, they can have it.

But yeah, overall I understand what you mean - I checked it too. My chromebook (with a pretty bad CPU - Intel Celeron N400 @ 1.1 GHz & pretty bad RAM & other overall stats) stutters a lot after opening the webpage, even when it's the only process running (other than basic system stuff). Everything works but it lags severely. On the other hand, my PC (with Intel i7-10700 @ 2.9GHz & a massive amount of RAM) has no problems at all, on top of several thousand other processes running. So low-end devices would face this issue pretty badly. Unfortunately as far as I know, there's no way to patch stuff just for lower end devices, so we'd have to optimize the whole thing. sigh

I will start working on the app after webpage is finished :D

Yup no worries! Feel free to take your time. It's not possible to work on both at the same time too, so yup.

I think we can start by temporarily reducing the image sizes & seeing if that improves performance or not. Don't worry, I'll send you the compressed images myself, so you can focus on the other stuff.

Good day to you :)

[baseplate-admin]

For the images, even more than performance, network might become an issue. We will need to compress the images one way or the other, but yup. that can wait a bit more. Tbh the only times we need large images is for the carousel & the anime-info pages. Other than those, we're using pretty small & low-sized images.

Yes thats true. But Network is not the main problem we are facing...

One thing we can maybe do to improve performance is reduce the number of carousel entries & make the number optional in settings. If an user wants more, they can have it.

I will take a look into this. But.... Lemme rant a bit more..

But yeah, overall I understand what you mean - I checked it too. My chromebook (with a pretty bad CPU - Intel Celeron N400 @ 1.1 GHz & pretty bad RAM & other overall stats) stutters a lot after opening the webpage, even when it's the only process running (other than basic system stuff). Everything works but it lags severely. On the other hand, my PC (with Intel i7-10700 @ 2.9GHz & a massive amount of RAM) has no problems at all, on top of several thousand other processes running. So low-end devices would face this issue pretty badly. Unfortunately as far as I know, there's no way to patch stuff just for lower end devices, so we'd have to optimize the whole thing. sigh

Yep yep. In my I5-7400 i see no slowdowns. But as soon as i switch to my samsung a71. The performance goes downhill rather quick...

I think we can start by temporarily reducing the image sizes & seeing if that improves performance or not. Don't worry, I'll send you the compressed images myself, so you can focus on the other stuff.

Spoiler : Lowering the image size gives us 200-300ms worth of savings at a significantly lower User Experience..

All in all we should focus on android app with our website :D

---

Also swiper uses Framework7 in the background. Its like running React in react. Both are fighting for true dom control. And both tries to do calculations independent of others. #392 might fix it but its not playing nice

---

Anyways thanks for profiling stuff. I wish you a good day too..

[baseplate-admin]

See all the mantine components?

They are the ones making the slide slow :)

[baseplate-admin]

Hey @AKindWorld

We are going app route right?

Can you test kivy apps?

[AKindWorld]

Hi!

We are going app route right?

For mobile version, yeah- pretty much. Optimizing everything for the mobile web is a painful and redundant task, and most users prefer apps anyway.

Can you test kivy apps?

I think I would be able to- does it require simply installing an APK or needs compilation/etc.?

^^

[baseplate-admin]

I think I would be able to- does it require simply installing an APK or needs compilation/etc.?

I am afraid its a little more than that. But you are on windows right? I can send you exe. To remove some work on your part..

Optimizing everything for the mobile web is a painful and redundant task, and most users prefer apps anyway.

Ahh yes. But lets not abandon our responsive website

^_^

[AKindWorld]

I am afraid its a little more than that. But you are on windows right? I can send you exe. To remove some work on your part..

Aha I see, sounds good to me. Feel free to send it to me anytime - here or Discord, whichever you prefer.

Ahh yes. But lets not abandon our responsive website

Haha indeed xD

^^