Steemer app update, gearing for a new release

Repository
https://github.com/hispeedimagins/steem

---

steemer is and will remain the first native android app which is and will be forever completely free for the people to use.

Why free?

Because @steemit needs it. A quick way to interact with the blockchain. One that will not eat into the users rewards.

---

Bug Fixes and Performance improvements

No new features this time.

---

Articles are processed via an async task

Articles were earlier processed on the main thread. Which is bad, I know. It was fine then, but now since I have been trying to make the app butter smooth it had to be changed. The process has been changed and a lot of code written for callbacks to work as they were. It now calls the database entry point from the background thread, which is fine as room will not crash. If need be a list is made and returned to the calling activity/fragment and it all works like a charm.

What do we get? No more stuttering while scrolling, no more ui freezes and a better experience.

We also return a new field for showing the main image of the article from the database.

Some commented code remains along with the old non-async methods, those will be removed out after more testing.

This also unifies a lot of code for processing the json object.

commit

1. commit

---

Articles will update, ram consumption reduced

This update also shows a very unique and mysterious bug which as of now may not be easy to fix, but is fixed partially.
In the last update for processing a list of data while saving into the db a return was placed at the wrong place which would have the effect of only updating the first article and not the rest.

Now for the bug. The app works by saving the articles in the db then returning them via a paged list when needed. This is fine. Until it is not. Steem returns the first 20 articles when requesting new ones. Via feed or blog. So when you get the first 20 you can update them in the database and the user sees fresh data. But what about the articles after the first 20? Those will be directly loaded from the database and a call will not be fired to load from the server. This reduces load on the servers but shows user stale data. This is the mysterious. The user can of course open the article and refresh it manually but most won't and keep seeing stale data. Any thoughts on how to solve this? or is this behaviour fine?

The second part of this update is to not load jsonarray fields like links, images and users from the metadata of a post from the db. We only save it for future use but not load it while the articles are being viewed in a feed or a blog. This reduces the amount of data in ram giving a performance boost.

commit

commit

---

Fix same article in blog or feed bug and shift likes to db

Another weird bug was that if the same article existed in the db as a blog and we were now saving the feed of the user and if the article is resteemed and now exists in the feed as well, this would cause the blog item to be updated as a feed item and vanish from the blog page. This was wrong and confusing. To stop this we now check if the item exists as a blog and if yes we make a new unique id which is done by this function

fun doubleTheId(id:Long,isBlog:Boolean):Long{
val reId = Integer.parseInt(isBlog.toString().get(0).toString(),35)
return (id.toString() + reId).toLong()
}

basically adding the int of true to the id making it accessible in the future as well.

A lot of minor changes as pointed out by android lint optimizer have been done.

commit

commit

---

Shift likes to db and not load them

Likes were loaded as well and saved with the list, then transferred to a different activity when needed. This was not needed and caused excess ram usage and performance hit because of the number of likes being saved for each article. This is not fixed as from the db the likes are not loaded along with the article. We simply save them in the db and then wait for the user to click on upvote view. Then the database Id is forwarded and only the likes are loaded and displayed. This makes things sleeker and easier.

Also this and the one above this have the same git message, sorry about that, android studio did not clear it and I did not check.

commit

commit

---

Scrolling behaviour change and check entire object before updating

For updating an item in a paged list you have to check or their specific values against the old and the new. I was checking only certain terms but as a lot of them can change now we simple match the objects.
For scrolling the items on intial load behaviour is changed to fire once but is not perfect, will change later.

commit

commit

GitHub account

https://github.com/hispeedimagins

---

I forgot to add documentation this time, eep, will do the next time.

Also since this app was not open source when I started it, I did not comment much. Only after I have put it on Github have I started adding comments.

---

Want to contact me?

Discord server for steemer - https://discord.gg/GkNZCGu
My discord username - hispeedimagins#6619
email - hispeedimagins@gmail.com