Home

#Welcome to the harbour-ostos wiki!#

##This is an initial Wiki page.##

The project initiator is on summer leave now in summer 2016 for july at least. There are also some hindering issues like home move (the project will stay here, however).

In September 2016, the home move was quite done. It took past mid-October to get back to this.

Now in December I see the need for improvement. I'm using the app almost every day, and see that it becames slow when the list length is past the screen height. Memory consumption is also huge.

One theory was that the context menus are too heavy to hide, which proved to be a nice clue. I changed the list items' context menus to be dynamically created and destroyed. The clogging performance of earlier may be because of garbage collection's dump trucks driving in the background. Now I might even putting in some animations, to waste some time!

The roadmap is to be done##

###Please take care of database compatibility### Changes to database should be done so that updating the app keeps user's data unspoiled. Easier said than done, you'll have to: a) leave old fields unchanged b) add new fields to new tables c) or, implement database conversion. Read table in old format and write it back in new format. Once.

##New highlights of v1.06##

• Significiantly improved performance
• Eliminated some bugs in shop handling; also name swith dots and single quotes work now OK.

##New features in v1.05##

• Swedish translation

##Incoming features##

• I have noticed some performance issues, as the list gets a little longer the update lasts annoyingly too long and the user interface becomes unresponsive. This must be addressed with priority. => I have found out that couple of things could be done: showing view placeholder during list update and putting update a few seconds ahead of last tap. So the annoyance of update will be when one has really stopped ticking away bought items.

• Improved German translation. I see, it's on the way! Alle Leute will be thankful whenever it comes.

• There was a request for price counting / followup. Good idea, but it makes everything a bit more complicated.

• Simplicity / clutter tradeoff: simple app or all the features.

• The database boilerplate code in dbaccess.js is a bit dumb, I admit. Surefire yes, profiling showed that it's not propably the performance bottleneck, but GUI. One could optimize SQL access only to app startup and shutdown, or developing even smarter startegy. At times I like to have both belt and suspenders, so Every Change Is a SQL access on the first version.

• The page change animation seems to clog in the middle, but it looks that some other apps may have the problem too, so this isn't so specific to Ostos. Is the Android emulator and many Android services running in the background the culprit?