My applications requirement is to contact the webservice, get the xml, parse it and display it using a listfield. I am calling all this classes xmlhandler, objectmodel, displaying it using a lisfield from a class that extends mainscreen which is making my application slow.
Can anyone suggest me how to make it fast?
Is it a apt to popup a loading screen and start a thread for contacting the webservice, get the xml, parsing it and kill the thread, then populate the listscreen and display it?
suggestions of any kind is welcome!
Test the speed of every part of your program. What I usually use is System.nanoTime() and find the difference in time after every part of the program.
Find out which part is slow before you do anything else.
Otherwise, you'll waste a lot of your time on the wrong parts.
For doing this kind of timing work, I often will do internal logging into a StringBuilder, or maybe just into an ArrayList holding raw, unformatted data. After the test is over, I format and output the data. This minimizes the effect of the logging on the timings.
I can only gues so forgive me if I'm wrong - to me it seems more efficient to create the item of list field only when they're really viewed. So I'd try to keep in memory only the parsed strings and create only the UI items currently to be displayed, discard invisible. To make it more smooth you can you can extend it one or more pages before and after current page.
This way the number of displayed items is always constant. You may also add paging to the service layer to limit number of records trabsmitted at once.
Related
Am here not asking for someone to write out an example, am looking for more input on ways to accomplish this, and why. (Guidance as such)
I have been trying and reading about Listview, But from what i understand, Listview and using search with it, would only work with a relatively small data set. (I am having a hard time getting to grips with it)
I am wanting to search a table (Across the network currently using jdbc:jtds) and the table can contain anything from 1,000 - 500,000 lines.
(An i know people are going to advise against it, but its more for internal application usage than public release)
The way i understand SearchView is its Android Implementation of the Ajax live search, and if so then it would need an array of data to filter through.
To pre load 500,000 would be impracticable, Am i correct in thinking this?
The method i was thinking was creating a new activity with multiple Textfields, and a query behind each one or multiples and performing a search based on the text that has been inputted and the user pressing a Submit / Search.
The draw back of this, is its more old school with back and forth process if a typo has been made, Where the SearchView would be interactive display results straight away from what the user starts to type in.
Could someone advise what may be the best method to do this? There appears to be way too many ways to search for data in java / android and am getting lost in the number of ways to do this.
(There is no Database being held locally, this is all purely running of a local network only.
I have currently been trying with Listadapter and SearchBinding)
I want to preserve data during service restart, which uses a arraylist of {arraylist of integers} and some other variables.
Since it is about 40-60 MB, I don't want it be generated each time the service restarts(it takes a lot of time); I want to generate data once, and maybe copy it for next service restart.
How can it be done?
Please consider how will I go about putting a data structure similar to multidimensional array(3d or above) into file, before suggesting writing the data in a file; which when done, will likely take significant time to read too.
You can try writing your data after generation to a file. Then on next service restart, you can simply read that from the file.
If you need persistent data, then put it into database
https://developer.android.com/guide/topics/data/data-storage
or try some object database like http://objectbox.io/
So you're afraid reading from the file would take along time due to its size, the number and size of the rows (the inner arrays).
I think it might be worthy to stop for a minute and ask yourself whether you need all this data at once. Maybe you only need a portion of it at any given time and there are scenarios in which you don't use some (or maybe most) of the data? If this is likely, I would suggest that you'll compute the data on demand, when required, and only keep a memory based cache for future demand in the current session.
Otherwise, if you do need all the data at a given time, you have a trade-off here. Trade-off between size on disk and processing time. You can shrink the data using some algorithm, but it would be at the expense of the processing time. On the hand, you can just serialize your object of data and save it to disk as is. Less time, more disk space.
Another solution for your scenario, could be, to just use a DB and a cursor (room on top sqlite). I don't exactly know what it is that you're trying to do, but your arrays can easily be modeled into a DB. Model a single row as you'd like and add to that model the outer index of the array. Then save the models into the DB, potentially making the outer index field the primary key if the DB.
Regardless of the things I wrote, try to think if you really need this data persistent on your client, maybe you can store it at the server side? If so, there are other storage and access solutions which are not included at the Android client side.
Thank you all for answering this question.
This is what I have finally settled for:
Instead of using the structure as part of the app, I made this into a
tool, which will prepare data to be used with the main app. In doing
so, it also stopped the concern regarding service restart.
This tool will first read all the strings from input file(s).
Then put all of them into the structure one at a time.(This will be
the part which I was having doubts, and asked the question about.
Since all the data is into the structure here, as soon as program
terminates, this structured data is unusable.)
Now, I prepared another structure for putting this data into file,
and put all this data into file so that I do not need to read to all
input file again and again, but only few lines.
Then I thought, why spend time "read"ing files while I can hard code
it into my app. So, as final step of this preprocessing tool, I made
it into a class which has switch(input){case X: return Y}.
Now I will just have to put this class into the app I wanted to make.
I know this all sounds very abstract, even stretching the concept of abstract, if you want to know details, please let me know. I am also including link of my "tool". Please visit and let me know if there would have been some better way.
P.S. There could be errors in this tool yet, which if you find, let me know to fix them.
P.P.S.
link: Kompressor Tool
Background: I have done a bit of looking into Caching in Spring and it seems like a great way to save time for common read operations. My code currently has a loop over a large number of items, where I am performing logic to see if certain other objects are connected in a way through common items. A way to think about this is similar to a shopping website's related items showing up when you view a certain item. The values I use to determine this are complex, but that is the basic idea.
On loading the item page there is a very long load time trying to compute and figure out which other items are related in some way as to display links to them. Instead of computing this list every time an item page loads, I have started "caching" items with a list of their recommended items. Many things in the system can trigger a need to recalculate these relations: adding/removing properties to items, adding/removing items, etc.
Problem: My "cache" is simply a singleton object containing a Map for items and their related objects. The process of iterating through every item in the system when any change to the cache is needed is very time consuming and process intensive. Java Caches don't seem to be the right answer due to constant changes to items. Is there any other design patterns that I am overlooking for this design? Caches seem to be close, but I am not sure if this problem fits into the mold of caching, due to it being a little more complex then a bulk amount of reads to a single item.
Are caches the way to go with this? If caching isn't the right solution, what is?
It seems that caches are not a solution for your problem, but they might help you in reaching a solution.
For example instead of caching the created items another approach is to cache information that rarely changes but is crucial to create the lists.
Spring function based caching (ie #Cachable) might come in handy, either for caching or invalidation.
The next level is to examine different types of caches (ie. redis) and what they offer in terms of algorithms, sorting and Pub/Sub.
My application has a number of objects in an internal list, and I need to be able to log them (e.g. once a second) and later recreate the state of the list at any time by querying the log file.
The current implementation logs the entire list every second, which is great for retrieval because I can simply load the log file, scan through it until I reach the desired time, and load the stored list.
However, the majority of my objects (~90%) rarely change, so it is wasteful in terms of disk space to continually log them at a set interval.
I am considering switching to a "delta" based log where only the changed objects are logged every second. Unfortunately this means it becomes hard to find the true state of the list at any one recorded time, without "playing back" the entire file to catch those objects that had not changed for a while before the desired recall time.
An alternative could be to store (every second) both the changed objects and the last-changed time for each unchanged object, so that a log reader would know where to look for them. I'm worried I'm reinventing the wheel here though — this must be a problem that has been encountered before.
Existing comparable techniques, I suppose, are those used in version control systems, but I'd like a native object-aware Java solution if possible — running git commit on a binary file once a second seems like it's abusing the intention of a VCS!
So, is there a standard way of solving this problem that I should be aware of? If not, any pitfalls that I might encounter when developing my own solution?
Please deal with this naive question.
Objective is to create a UI and dynamically be able to change the basic workflows, add another option, add another steps etc.
As an example, one simple workflow could be as following:
What's the age of 'X'? TEXT_BOX
if(age>18) proceed to step 2.
else, go to next page (let's say, same processing happens again with different value of X).
What does 'X do?
a. Job
b. Business
Submit (Go to next 'X').
I wanted to keep this workflow in XML as complete tree (all branches of if/else-if/else) and pass it on UI for rendering. Some of the sub-trees will be populated as per action performed in previous step.
This way, small modifications or workflow changes will not require any code changes.
Other option is to use JSON and pass it directly (rather than converting XML to JSON and passing) but it will be loosely coupled and could be difficult to manage in future.
Is there any clearcut benefit I should think of before choosing any of them?
Will any of them provide any extra benefit in the problem I am trying to solve?
Thanks,
It is possible to mimic the structure that you plan to have in an XML, as a json string, without any hurdles as far as I think of. (If you think of any hurdles please point out, I might help you out with idea to handle that).
json will for sure save you lots of bandwith if the data you are planning to send is large. This will inturn also reduce the roundtrip time and make your application more responsive.