I have a tableview where i need to show around 10,000 rows (data stored locally in sqlite)
But when we jump to that view, app is getting blocked (freezed) as its loading all those rows.
Is there anyway to load data without freezing UI?
PS. Our app is rejected, is it because of this reason?
Thanks
EDIT:
They rejected and given following info
"Hello.
We noticed your app lacks native iOS functionality.
Please check out the videos for app design information,: "Getting Started
video: The Ingredients of Great iPhone Apps" and "iPhone User Interface
Design," available on the iOS Developer
Centerhttp://developer.apple.com/devcenter/ios,
and the iOS Human Interface
Guidelineshttp://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdfin
particular, the sections, "Great
iOS Apps Embrace the Platform and HI Design
Principles"http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.htmland
"Human
Interface Principles"http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Principles/Principles.html%23//apple_ref/doc/uid/TP40006556-CH5-SW1."
With ten thousand rows you have no choice but load your data on demand. Otherwise, your app has no chance of performing at a decent level. A freeze like you describe would definitely be enough to see your app rejected1.
This approach is rather wasteful with memory, too, because out of ten thousand rows you need at most two dozen at any given time.
A reasonably simple way to speed things up is to prepare an NSCache for your pages of data (say, ten items per page), add code that gets the total count of records, and modify the code that retrieves the data to read records from a single page (use LIMIT/OFFSET). When your table shows rows, it should try getting a page of the row from the cache. If the page is not there, it should load it from sqlite, and put in the cache. Using pages will minimize the number of roundtrips to the database; using cache will let you manage an optimal use of memory.
1 It does not look like your app has been rejected for a freeze this time around, but once you fix the "lacking native iOS functionality", the freeze will trigger another rejection.
Check this demo for lazy loading of all data along with images.
This sample demonstrates a multi-stage approach to loading and displaying a UITableView. It begins by loading the relevant text from an RSS feed so the table can load as quickly as possible, and then downloads the images for each row asynchronously so the UI is more responsive.
Related
I'm making an app where the user can take a picture and add a title and description. But now I need to store the picture and the titles. I’ve tried making an object that contains title, description and image properties.
When it’s done I save an array of custom objects with the information on it with UserDefaults. My idea is showing in another view a table view with all the content and pictures the user has taken on the cells. I tried getting back the information with user defaults. It was working well until the user saves too many pictures. When the viewController with the tableview loads, then my app gets slower, and eventually it crashes.
I suppose the problem is when I load all the array with all custom objects, all the pictures are loaded into memory although they aren’t used and displayed for users. So I think it isn’t the best way to make what I want to make.
Is there any way better to make what I’m making or store data more efficiently and use it in tableview without using all the memory of the device?
I’m making the app from 0 again.
Can you show me how to store data and images efficiently?
There are several options for permanently storing user data on the device such that it will survive app and phone restarts. NSUserDefaults typically is for small amounts of data, such as user preferences.
When it comes time to store a lot of data, in particular big binary objects like photos, you need to decide which design you want to use. One option:
store all the photos in one directory in your apps documents and then use some simple lookup store (perhaps Core Data, or SQLite, or even a flat file) to index the photos and their metadata. Or if you don't care about indexing you can read the list of file names from the directory and sort them by time.
The other problem you are maybe having is that you are trying to load all of the photos at once for the user. As you have discovered, once you have more than a handful of photos this system falls apart. You need some mechanism to load only a few photos at a time, preferably only the ones the user needs to be displayed at that moment.
So, for example, if you are displaying the photos in a tableview, you want to only load the 10-15 photos that are visible in the table at any given time.
When storing this kind of data, you have 2 options (In fact you have more than 3 options, but saving image to the disk is IMHO complicated for this.) -
UserDefaults
Database like CoreData/Realm/FireBase...
The first one is recommended when there is not much data to save... For operating with more data, I would use database - CoreData...
For you operation you can use CoreData and NSFetchedResultsController (which is designed especially for fetching objects from the database)...
you can read the FetchedResultsController doc here... and core data basics here
Wish you best luck!
I have an iOS app that presents content in a tableView. I've added a 'like/dislike' feature that interacts with my database (I use Parse.com). Every time someone likes/dislikes a piece of content, the specifics are sent to the Parse database. For each piece of content, I'd like to calculate and display the percentage of 'likes' over 'likes' + 'dislikes'. This is pretty simple math, but I can't wrap my head around the best way of designing my database table and the most efficient way to calculate the 'liked' percentage for each piece of content before the tableView physically appears.
As it is, I already have a loop in my tableView's viewDidLoad which compares the content from another database table to the 'like/dislike' table to restore the 'like/dislike' button state of the user (if they already liked/disliked a piece of content).
At first, I thought of creating an array in the initial viewDidLoadloop. However, using the whereKey: equalTo: type of query for each piece content to simply find the amount of likes/dislikes takes forever. As predicted, it is very slow in cellForRowAtIndexPath as well.
Worst case, I can make these calculations server-side and just pull the 'liked' percentage. However, I'd like to implement this in the app somehow. I'm a complete beginner, so I may be going about this all wrong.
Here is the basis of my database table:
Edit: I've managed to build a server-side program that calculates the percentage of users that 'like' pieces of content. My app pulls this percentage from the database at runtime. To make the percentage change more responsive when the user 'likes' something, I locally calculate an updated percentage. The problem here is when the user exits the app and reopens, the data reloads. If the server-side program had not run recently, the app will display an old 'liked' percentage (the most up to date % would not be calculated yet). The two solutions I see to fix this are:
Run the server-side program every 1-3 min
Post more data to the database when someone likes content (this would involve additional database queries for every single 'like').
I think both of these options are way too expensive for what I'm trying to accomplish.
I'd suggest leaving the calculations to the server side, and responding with the information to utilize in the app. This will save you from processing and parsing the incoming results.
You have greater processing power on a Server than on a device.
I have to make an iphone app for some customer.
He should be able to add some data to the app using a HTML form that update an XML file.
So I think this XML file may contain over 1000 item by the time.
Is that normal or should I work with other data storage techniques?
The XML file is used to display some information in UITableView.
1000 items doesn't seem like a lot if it's simple textual information.
I worked on an application that displayed several hundreds of complex items using UITableViews on a 1st gen iPad, the amount of data pulled from the webservice was never a problem. The problem I faced was scrolling performance and proper cell reuse.
Of course, you have to be rigorous with memory management if you expect a lot of data to be displayed in your app, else leaks will very quickly make your app crash.
I have a small APP which allows users to view information on Beers and Beers they have tried for a local Bars Beer Club.
I have 4 Views. Beer Menu, All Stats, My Stats and Settings.
Originally, I thought to pull all of the data via a web service and return xml at initial load of the app, and use it throughout.
OR...
I could just pull what I need when I need it. This would result in just pulling the data I need, which would be faster, but it would result in more requests. What would be better:
a) pull all data, store globally, build views as needed.
b) pull only data I need, when I need it. This means if they click on a beer, I would make a request for that beers info. If they clicked on 10 different beers, then that would be 10 different requests.
What is better? Or does it even matter.
yeah, I think on mobile devices these kind of decisions to matter.
With these kind of concerns I think sometimes there is no right answer but here are a few pointers:
Use json, not xml (if you can)
it's less verbose and, depending on the data, could make a difference to the speed.
Do not block the UI thread
This is really a general guide to all app development, in my opinion. The worst thing you can do is block the UI thread.
Coding for a progressive UI that loads data separately will always be more fiddly than just doing a batch load, and then returning everything. But the extra work will really make your User Experience a lot more pleasurable.
Be clever about your requests
This kinda of carries on from the last point. I'm not saying do a million request, but do try and find a balance before less requests, and loading data as needed (which would suggest more requests).
Try and really think about how the user is going to use your app, and see if you can do some clever pre-fetching based on what you THINK the user might need more in the certain view.
i.e What is the most likely view to be used next? can you pre fetch the data for that?
This last part is really the fine tuning, and will result in a lot of trial and error. But the end result will hopefully be a really great app that just feels fast, and feels right.
I'd go with loading cached data on launch (if it exists) and then load fresh data in the background as needed. This keeps your app as responsive as possible. it's a balance between draining battery life on requests VS responsiveness and data availability. I think the balance is caching information with a timestamp (if the data changes, if not it's even better) and then update as needed.
My app has various pins that drop onto a map and when you click on the pins you get more information about this entity.
Each time you click on the entity it retrieves the information from a web service. Should I only retrieve this information once and store it in memory or should I retrieve it each time that page loads?
It's a small about of text and 3 small images?
If its just 3 small images and some text that will not change i would probably cache them in the application instead of retriving them over and over, it will provide a better user expirience in my opinion...
Also I have a Core Data application that uses images...
I tried both methods but I chose to retrieve it every time because for my goal is the best practice. However this method causes me to write some code and a lot of if and else!
How Daniel said, cache each image can be a better solution for your problem because if an user would like to retrieve these images from internet but the connections isn't fast, he'll wait a lot of time...