creating a listing component(a tabl view) for iPhone app, the list content must be dynamic (can be read from a web service or local file system) and the app should only fetch the content that is viewable in the list(table) view and each scroll will request for more data from the server(file system or web service). The viewable content should auto-refreshed every 30 seconds.
till now i am successfull in creatin table view with dumy data(from an array).
But what approach should i take foe requesting web service only viewable to the current cell ,
any guidence here will be very appreciated.
To solve your problem I will suggest following steps.
1. Keep one data array and keep refreshing you table sing that every 30 sec, as you have already done.
2. Make a separate thread for calling web service and update you array when response comes available.
Thus, even if internet is down some time or slow, your GUI will not be affected with that.
3. Make sure your array is being accessed synchronously between threads.
4. if web service content is too big, then keep version number for data and send request with current version no. so if web service has updated version of data it will send you only updates or difference. OR it will send you all the data on condition that your current version is older.
If answer is not relevant than please post further details so that I can have better understanding of problem.
Related
i want a make a feed reader...i want load politics news from multiple data dource in one tableview synchronously.
what do i do?
i went to this link: table view with multiple data sources/nibs
but this solution is not synchronously
So basically what should be the approach when we have multiple data source but single instance of table view to show the data?
What I would do is to create a backend service where the news are merged into one list. This allows you to easily edit the algorithm without the user having to update the app. And your backend also only have to crawl the websites once instead of every client having to do it every time a user wants to see the news.
When you fetch data from that service it will come in one list, and you already know how to do that :)
It shouldn't be synchronously, because you wait for the rss response.
You better show a spinner and reload the tableview data once you collect all the responses.
This is my first Cordova/Backbone application.
I have grasped the whole deal with Models, Views, etc. somewhat, and now I have gotten to actually making proper view structure for my app.
It is a user centered app, which means that views are dynamic depending on who the user is and their status in the app.
Could you please help me to understand what is a better choice: making one (large-ish) api call to the server to get the data for all user-related app views (that would get all user info, various menus for the current user etc) and put them in one User model or make several smaller api calls that each get a fragment of the information (let's say, profile information, newsfeed information and options for two menus, so 4 ajax calls total) and keep the models separate? All the relevant views (UserProfile, SideMenu, UserProfileMenu and ActivityFeed) are rendered on user login. Some of them are available for user at all times (SideBar menu for example), some get switched out as user navigates elsewhere.
I design the server-side API myself, so I can freely choose what data is returned and when.
"it depends". If you need all the info (from 4 ajax calls) from start, it would be better to create one big api call, because callig server 4 times will last longer than one big call - 4x server ping time. you could use the big call on app start and still create the 4smaller ones to refresh data when needed.
I have a Web Service and sqlite database. In this, web service will be used to store data inside database. Now I want to include sync functionality as - Whenever application starts at that time the database will start to load its table's data through web service.
Now after some time when I update my my web service the database will be updated accordingly. My question is that what are the best practices that I must follow for this update. Should I clear whole DB and start adding all rows again(I know this will take a lot time) but If not this then how do my database will add only particular data from the web service?
Thank you.
What I suggest you is:
store all your webservice content into db first when the app starts.
display your content on the screen from db only.
again when you need to refresh or recall your data just update the database.
Thus, you will always find all your fresh data into database.
Downloading and updating the entire server data will prove expensive. It will use more bandwidth and prove costly to your customer. Rather than pushing the entire load (even for minor update), send a delta. I will suggest you to maintain version information.
When application downloads the data from web service for a said version and store it successfully in the database, set the current updated version as well in the DB.
When app starts the next time, make a light weight header request to get just the version info from the server. The server should respond to this header request with the latest data version number.
Check the version from WS with the current application data version stored in the DB. If the server has an updated version, start the sync.
The version change information should be delta i.e.
For new version, server should send only the information that is changed since the version available with the device.
You server should have capability to calculate the delta between two versions.
Delta information will typically have sections like, new data, updated data, deleted data etc.
Based on this, the iOS app will make the necessary CRUD(Create, Read, Update and Delete) operations on the DB data.
Once the iOS app updates itself, then you can update the DB version to the latest received version from server. Until then let it remain dirty for proper error handling.
Hope that helps.
I would recommend you use RestKit's superb Core Data support.
By using RKEntityMapping you can map your remote objects from JSON or XML directly to Core Data entities in your database.
RestKit will automatically maintain the database for you, inserting and updating entries as appropriate from your web service. (In my experience, I've found deleting objects requires a tiny bit of extra work depending on how RESTful your web service is).
RestKit definitely does have a learning curve attached, but it's well worth it: having deployed it a couple of times now, is definitely a much better solution than manually writing your own SQLite/Web Service syncing code.
First you need to set all webservice content into your SQLITE.and what you want to display get that data from SQLITE.and perform opertaion into that sqlite table and when once all this done you need to changes made are saved it into webservice.
Follow this way.
I am very new to backbone.js (and MVC with javascript), and while reading several resources about backbone.js to adopt it in my project, I now have a question: how can I detect when multiple users(browsers) attempt to update? (and prevent it?)
My project is a tool for editing surveys/polls for users who want to create and distribute their own surveys. So far, my web app maintains a list of edit-commands fired by browser, sends it to the server, and the server does batch update.
What I did was, each survey maintains a version number and browser must request update with that version number, and if the request's version number does not match with the one in the server, the request fails and the user must reload his page (you know, implementing concurrent editing is not easy for everyone). Of course, when the browser's update was successful, it gets new version number from the server as ajax response, and one browser can request update to server only when its past update request is done.
Now, I am interested in RESTful APIs and MV* patterns, but having a hard time to solve this issue. What is the best / common approach for this?
There is a common trick instead of using versions, use TIMESTAMPS in your DB and then try to UPDATE WHERE timestamp = model.timestamp. If it returns zero result count - use appropriate HTTP 409 (conflict) response and ask the user to update the page in save() error callback. You can even use the local storage to merge changes, and compare the non-equivalent side by side.
Say I have a TODO list iphone app, that can be edited/viewed from both a web application and the iphone application.
When on the iphone, when a user views all his todo lists, or sub-items, I would think that each time the user views a particular list it shouldn't be hitting the web applications API every-time, but rather cache locally the values and only hit the web when things change.
What strategies are there for this type of scenerio?
I agree with you in your dirty-otherwise-do-not-contact-the-server point. And I think this point is pretty straightforward and easy to implement.
However, be careful in this scenario: it gets dirty but at the same time, the device cannot reach the internet. In this scenario, I suggest you check the internet accessibility on a frequent basis (even when your app is in the background), and try to reach your server and update whenever possible.
This is a tricky problem. I'm currently working on an app that needs to perform a similar synchronization, and I haven't decided how I want to handle it yet.
You're right in that you don't want to be hitting the web repeatedly. It would slow the app down considerably. Keeping a local cache is the way to go.
One drawback is that the user could change/add an item on the web and you wouldn't see it on the phone. You'd need to have a refresh button (like in the Mail application, for example) to allow the user to get the changes.
Then you have an issue with conflict resolution. Say the same item is edited on both the phone and on the web. How does the user pick which one to keep, or do they get duplicated?
I think the best way to do this is to replicated your server's schema in CoreData. Then load a given element from the local DB, and in the background go out and check that element for updates if the device has an internet connection. You're hitting the db each time, but the user is not slowed down by the process.
You should not query the internet everytime you view the list.
But when you make updates to it, or edit it, you should update the server as well. That will make your life a whole lot simpler. That way when the user updates an item that he deleted in the web server, the server will just throw that request out...