I have an iOS application and recently added Call Directory extension to my application in order to manage calls blocking & identification. I want to know the maximum amount of numbers that can be added to my Call Directory block list. I tried to do that test manually and added about 16.000.000 entries. I did that by adding them 100.000 chunks one by one and could add more. I also tried to find any documentations about this limits, but had no luck with that either.
Do you know how to determine it in a better way or should I just keep adding 100.000 chunks? Might be someone was facing this question in the past?
Did a lot of experiments and found out the following:
Call Directory Extension's limits depend from the device memory, so as was mentioned in the comments there are no any specified limits.
Amount of uploading data per time to Call Directory Extension also depends from the device memory. When testing on iPhone 6S, I could upload up to 100.000 entries at once. With newer device it scales up.
That's everything I found out for so far, hope that will help someone.
I'm in the middle of making an app that will end up needing somewhere between 300-500 different images. I don't know if a database is the right way to go about this, or storing them locally. I doubt locally could do it, seeing as the app size would get huge. Would I just download all the files necessary for an event, then unload them when the event is done
TIA!
I've already checked out this question (App size is too big because of too many images)
I used tinypng.com like it suggested for my images, and yet my files are still way too big, and with so many of them, my app is looking at possible gigs in size.
Essentially my plan is to have a car quiz type game, where simply I have an image of just about every car ever made(gotten through public domain off wikicommons), photoshop all the badges off(which I've already done over a thousand of), and you try and see if you can still guess the car.
Accounting for iPad Retina resolution, I'm seeing that this app will be huge in terms of memory space.
The average photo reduced is about 300kb. Does that seem high?
How can I make an ios app that has thousands of decent quality images?
Would I have to create some over the air database or something? I don't know anything about that.
Also I've only been coding for about a year, so if there's anything code related that might help, let me know.
Any tips or tricks would be greatly appreciated. Thank you!
You probably don't need a database or some robust online system for organizing and retrieving your photos, though it's obvious that storing all these files on the device is not going to work.
Purchase webhosting. For $5 a month you can get unlimited online storage and bandwidth. Godaddy, Bluehost, Hostgator, Dreamhost, etc...
Use one of their online file managers, or download a free FTP (file transfer protocol) client like Filezilla.
Using their online file manager, or connecting with FileZilla, just transfer your images onto the webserver.
Then, with a list of URLs in hand linking you to your car images, use the code below to load an image from a URL:
NSURL *url = [NSURL URLWithString:path];
NSData *data = [NSData dataWithContentsOfURL:url];
UIImage *img = [[UIImage alloc] initWithData:data cache:NO];
** When you're displaying an interface that relies on downloading information or photos, you should be showing some placeholder ("Loading...," a box, or a "loading spinner") where the content will go that stays until the image is downloaded.
have a look at this link, should provide the information how to download the images inside the app.
I already used AFNetworking which is really easy to handle. If you want to use it, have a look at the class:
#import <AFNetworking/UIImageView+AFNetworking.h>
and check the method setImageWithURLRequest:placeholderImage:success:failure:
For saving the UIImage after downloading, you could use this method and safe them local inside the apps directory. I think it would be the simplest way. If it will get bigger you could try to use a sqlite to store the paths of the UIImages.
I had a very similar issue. You may not be making the same mistake, but I will share anyway.
I was making images in Photoshop with very large dimensions, and I would just scale them down to the necessary size in Xcode's storyboard.
This was causing each image to be unnecessarily large in file size.
Therefore, the solution was to shrink each image to the precise dimensions needed for the application before uploading to Xcode.
This reduced the memory usage by images a whole lot.
You should probably use System File to store your images and save the path in the Database because:
Database storage is usually more expensive than file system storage
Difference of size of your photos can dramatically increase row sizes.
The best practise is then to name your images as the according primary key.
We're using Parse in our iOS app and we've discovered that our app is using an enormous amount of space -around 2.3GB in some devices- in storage. After downloading app data to my Mac, I've realized almost all of that data is the cached images in a folder called PFFileStaging, it contains highest resolution PNGs of all the PFFiles that the user has viewed in our app, ever. How can we disable this behavior, at least limit it? Is that the intended behavior? I heavily doubt using GBs of space is the intended behavior. Is this a bug?
Unfortunately this is not cache related (as per Parse's engineers: "this is used to ensure that no concurrent modification happens to the file after you request uploading").
They're planning to implement automatic trimming of PFFileStaging folder on every app start (as per road plan this should appear in next version 1.8.2).
See the the whole thread on GitHub.
This is absolutely driving me crazy. While I'm a fan of the availability of asynchronous calls in AIR, I'm finding that being forced to use them for something that should be SUPER simple is a severe limitation. So severe that I may end up abandoning AIR and writing native Android and iOS apps instead of using the shared AIR platform.
OK, now that I have that off my chest, here's what I'm trying to accomplish. I have an app that, when deployed, is relatively small. But once deployed to a user's device that user will log in using a login name/password. Once they log in, content specific to that user needs to be downloaded and saved to the local device. Since the content varies by user I can't include it in the package for deployment.
But I cannot figure out how to accomplish this: say I want to download 10 files and each file is 2-3mb and I want to show a "Downloading, please wait..." view during the download. The application cannot proceed until all 10 files are downloaded. But since from what I've seen URLStream and URLLoader are both async I cannot figure out how to block the app from opening the "View available content" and say on the "Downloading, please wait..." view. Can anyone point me in the right direction??
I am new to AIR/Actionscript, but am a seasoned developer. Perhaps too seasoned in my old ways to think of an elegant solution to the above!
I would take a look at BulkLoader with a combination of dispatching/listening for completion. That way you can update the progress meter if you want, so on. Hope this helps.