Violoncello and Optimization

I was about ready to release Violoncello. I felt like I had finally finished this huge project that I started over a month ago. However, there was one major obstacle left in my path: optimization. This had been something I struggled with throughout Violoncello’s development, but I had fixed a lot of issues in that area. At this point, I only had one major issue left: Violoncello was incredibly slow.

Unfortunately, that’s where the story ends. As of the morning I am writing this, I still need to fix this issue. Unfortunately, if I want better loading speeds, I’m going to have to rewrite a lot of code. Here’s why...

The Enemy: Html.fromHtml

To convert the HTML to a thing called a Spannable, necessary to load it in a TextView, Android offers Html.fromHtml. Problem is, it’s not very fast. Sure, it’s fine for loading simple pages, but if you want to load a decently-sized Wikipedia article, it can take a very long time. As long as 30 seconds in my testing, in fact. Put simply, loading speeds are too slow for my liking.

Why not use an alternative to Html.fromHtml?

This could certainly be a decent way of doing things, but I can’t find a viable alternative to Html.fromHtml. Plus, even if I were able to, the Android TextView just isn’t really designed for super long articles loaded from the internet with complex styling, as I have now realized.

Is this the end of Violoncello?

No. I am not giving up on it now. However, I’m also not accepting mediocre performance. Fortunately, there’s a faster and better alternative to using a TextView, and it’s quite obvious now that I think about it! Why not just use a WebView?

Speed improvements

At the time I’m writing this, I haven’t actually written any code to test this, but I’m certain there will be speed improvements with the switch to a WebView. I can keep the code that removes non-text elements from the HTML, and simply have the WebView load it like a normal page. No converting HTML to a Spannable would be required, which was the main thing slowing loading pages down. Plus, with a little CSS magic, I should hopefully be able to keep features like custom fonts and colors. It’s a really good alternative, but there is one major downside to it that I know of at the moment.

The bad news

Implementing this is going to require a lot of rewriting of code. I am okay with this, as I really want this app to turn out well. However, this will likely result in the app’s release being somewhat delayed. I’m very sorry about this, and I look forward to moving on myself. However, I can’t in good conscience release a slow, unoptimized app when a better alternative clearly exists.

Ending on a high note

On the bright side, I have a feeling Violoncello will turn out really well when it is eventually released. Again, I’m really sorry for the delay, but I hope you understand why I feel it necessary to make these improvements. Thanks for reading, and expect to see more updates soon.

Popular posts from this blog

Late 2014 Mac mini in 2022 - Still Worth Buying?

Violoncello for Windows is finally here!

September 2023 Photo Dump