I am planning to create sqlite table on my android app. The data comes from the the server via webservice.
I would like to know what is the best way to do this.
Should I transfer the data from the webservice in a sqlite db file and merge it or should i get all the data as a soap request and parse it in to table or should I use rest call.
The general size of the data is 2MB with 100 columns.
Please advise the best case where I can quickly get this data, with less load on the device.
My Workflow is:
Download a set of 20000 Addresses and save them to device sqlite database. This operation is only once, when you run the app for the first time or when you want to refresh the whole app data.
Update this record when ever there is a change in the server.
Now I can get this data either in JSON, XML or as pure SqLite File from the server . I want to know what is the fastest way to store this data in to Android Database.
I tried all the above methods and I found getting the database file from server and copying that data to the database is faster than getting the data in XML or JSON and parsing it. Please advise if I am right or wrong.
If you are planning to use sync adapters then you will need to implement a content provider (or atleast a stub) and an authenticator. Here is a good example that you can follow.
Also, you have not explained more about what is the use-case of such a web-service to decide what web-service architecture to suggest. But REST is a good style to write your services and using JSON over XML is advisable due to data format efficiency (or better yet give protocol-buffer a shot)
And yes, sync adapters are better to use as they already provide a great set of features that you will want to implement otherwise when written as a background service (e.g., periodic sync, auto sync, exponential backoff etc.)
To have less load on the device you can implement a sync-adapter backed by a content provider. You serialize/deserialize data when you upload/download data from server. When you need to persist data from the server you can use the bulkInsert() method in content-provider and persist all your data in a transaction
Related
I have just started taking a look at rocksdb and was able to build a small springboot based app to perform basic CRUD operations on it. However, I was wondering if there is a ui tool that can be used to query or browse the data in rocksdb.
I am not sure if this is a valid question, but something like pgadmin for postgres or a client utility that can be used to browse through the data in this db?
Thanks, HK.
No, there isn't.
The reason for that is that there is no way a GUI client can know how to deserialize your data format.
I might save my values as pure strings - you might have it as json bytes - someone else might use protobuf - how would the gui client know how to deserialize it and show it in the UI?
Or would it just show the bytes? Which is unlikely to be useful
I am new to spring framework. I would like to pull data from database and set that data in application context. When ever we change data in database according data should be refresh. Please help me out what would be the best approach.
If you want to refresh your data in application context on change in the database I have a bad news for you - that's not really possible (or easy and straightforward, at least).
Most of the common databases are passive in a sense that they won't let you to subscribe for specific events (like data update) because this will require some additional IPC between database and subscribed application and this is generally not the main purpose of database.
In any case something like this will be database-specific, so if you really want this - it is better to check api docs of your database - there is a chance that you'll find means for doing something like this there. Again, this probably won't be very flexible and robust solution.
In general case you go one of 3 routes:
Pull your data from database every time it is needed
Pull your data from database every time it is needed but add some cache
Implement application-level component that will manage data. When data is requested - it will fetch it from the database if it is missing in cache. When data is updated it will update it both in cache and database.
(1) and (2) are are pretty much your only options if your data can be updated not only from your applications. (3) is a good way if data can only be updated from within your application and if amounts of data are small enough to justify it's caching.
Hope this will help.
I am developing a Spring Based Web Application which will handle large volume of requests per minute and this web app needs to respond very quickly.
For this purpose, We decided to implement a flat-file based queuing mechanism, which would just write the requests (set of database columns values) to flat files and another process would pick this data from flat files periodically and write it to the database. I pick up only those files that am done writing with.
As am using a flat file, For each request I receive, I need to open and close the flat file inside my controller method.
My Question is : Is there a better way to implement this solution ? JMS is out of scope as we don't have the infrastructure right now.
If this file based approach seems good, then is there a better way to reduce the file I/O ? With the current design, I open/write/close the flat file for each web request received, which I know is bad. :(
Env : SpringSource ToolSuite, Apache/Tomcat with back-end as Oracle.
File access has to be synchronized, otherwise you'll corrupt it. Synchronized access clashes with the large volume of requests you plan.
Take a look at things like Kestrel or just go with a database like SQLite (at least you can delegate the synchronization burden)
I've been having nothing but problems with Blackberry development and SQLite for Blackberry in general.
I'm thinking of alternatives for storing data on the device.
First of all the data stored on the device comes from web service calls 99% of the time. The web service response can range from less than 0.5kB up to 10 or maybe even 20 Kb.
A lot of the trouble I've been having revolves around the fact that I use threads to make my web service calls asynchronous, and many conflicts arise between database connections. I've also been having trouble with a DatabaseOutOfMemoryException, which I haven't even found in the documentation.
Is storing the web service response in it's raw XML (as an xml or txt file on the device) and just reading it from there everytime I want to load something on the UI a good idea?? Right now I just get the raw XML in a string and parse it (using DocumentBuilder etc...), storing the contents into different tables of my SQLite.
Would doing away with SQLite and using XML exclusively be faster?? Would it be easier?? Would there be conflicts with read/write access to open files? My app has a lot of read/write going on, so I'd like to make it as easy as possible to manage.
Any ideas would be great, thanks!!
You can use the persistent store, instead of SqLite. One big advantage of the persistent store is that it is always available - no worries about missing SDCards or the filesystem being mounted while the device is USB connected. By "big", I mean this is absolutely huge from a support perspective. Explaining all the edge cases around when a SqLite database is usable on BlackBerry is a huge pain.
The biggest disadvantage of the persistent store is the 64kb limit per object. If you know all your XML fragments never exceed that, then you're fine. However, if you might exceed 64kb, then you'll need to come up with a persistable object that intentionally fragments any large streams into components under 64kb each.
I am soon to embark on a medium scale project. Although this isn't a very high priority in my large list of things to do but I have been trying of how I could affectively handle data concurrency.
I will be using a stateless EJB backend to my flex application.
Ideally I am looking for a simple method to deal with data concurrency. e.g. if data is saved on one interface it is refreshed in another. Or it warns that the data has been changed before saving a new version of the data.
Has anyone any ideas as I am at a loss at the moment. As I mentioned its not a high priority but I would feel a lot better if I had some mechanism to improve the process.
If you are planning on using AMF channels for communication you can use the long polling feature to effectively give your application "push message" type support. Both the BlazeDS and/or GraniteDS data services support this capability for exactly the reasons you mentioned.
Version control systems store user_id and datetime for every revision. You can use same method. Client app get current datetime for requested data and save it. App send on changed data with saved datetime. Server checks datetime of last revision and received datetime. And reply to app accordingly.
Second method is using broadcast messages from server to clients. But I don't think it's applicable in your case. This method put into practice in LAN (environment with stable connect) usually.