I want to know the feasibility of these things:
1) Is it possible to download 200MB audio files to our application?
2) How much RAM can be accessed from an iPhone app? What is the largest amount of RAM an app can expect to use?
Anyone's help in this regard is deeply appreciated.
Thanks to all,
Monish
1) Yes, although you might make users angry who are not on Wifi + fast DSL. Also you will need to handle interrupted downloads.
2) No, since ARM is a 32bit processor a maximum of 4GB RAM can be addressed. Anyhow, iDevices have a maximum of 512MB right now (iPad 2). Your application will get killed by iOS if your app takes about 75% or so of the available RAM which means in reality you shouldn't use more than, say, 80MB of RAM. And if you need to address 8GB then your design is totally flawed to begin with.
There are always ways to work with a lot less (e. g. either by using better algorithms and/or by caching to disk). On the disk, you are only limited by the available space left on the device. So if you have an iDevice with just 8GB you're naturally out of luck as the system itself and other apps/data are reducing the available space. Same if you're on a 64GB iDevice which is packed with movies. You will need to be able to work with the space that is available. You can, for example, try to "reserve" the necessary space by creating a file and making it as big as you need it (via a seek and a write) but be prepared for angry customers.
Related
I recently learned that GPU can do operations as CPU do, although there is tradeoff in the operation latency. Regardless the latency, can a GPU run an OS by its own?
Imagine a computer with no persistent storage, no user input, no networking and no sense of time/date. For this hypothetical computer, there's no way for anything in the real world (e.g. a user) to influence its behavior, and no way to tell if it has an OS or is merely showing a predetermined slide show.
In theory, if you can write an OS for this hypothetical computer, you wouldn't because there's no possible reason to bother. This describes a typical "GPU + video card memory" scenario (where a host OS running on the CPU is the only means of influencing the work done by the GPU).
Now imagine a "GPU" with various devices attached to it (some persistent storage, some networking, something for user input, a graphics card, ...) so that the "GPU" is able to manage (and abstract, and maybe even allow multiple programs to securely share) these devices. In this case, the "GPU" has become a central unit that does processing (a CPU!). It'll probably be a relatively awful CPU (with poor flow control and over-powered SIMD), but it's no longer a GPU.
Can we run OS in a gpu only device?
I don't know. If a tree falls in the woods, but nobody is around to hear it, does it make a sound?
My application requires at least 40MB of RAM, so earlier iPhones (like 3G, first iPod touch versions) just do not have it (they have max about 20MB for my app). Is there a proper way to disable installing it to 3G devices? I know UIRequiredDeviceCapabilities, but it does not have parameter for minimum available memory.
First, are you sure that your application actually uses 40 MB of RAM on the older devices? I've found (by using the Memory Monitor instrument) that the same application uses less RAM on my iPhone 3G than it does on my iPhone 4 or iPad. The latter two devices have more pixels within their interfaces, so my application chews up more memory when running on them.
If it does, figure out if you can optimize memory usage to get it within a safe (< 30 MB) range for the older hardware. If you can do this, I think you'll see an across-the-board performance improvement in your application, even on the newer hardware.
Finally, if you absolutely cannot run on an older iOS device, I'd recommend using the UIRequiredDeviceCapabilities keys armv7 or opengles-2. Either will filter for the newer (iPhone 3G S and greater) hardware. While not keyed on memory size, the iPhone 3G S launched with significantly more RAM than the older models, and not a device since has had less. It's hard to imagine Apple reducing this specification at any point in the future.
I am testing my app in two different devices. My app is relies heavily on images(allocating and deallocating). I know I have a leak but I am just curious why I observe this.
The behavior between the two devices is different. Device A crashes after 4 cycles of switching between views and Device B after 10 cycles, yet Device A has more free memory than Device B.
Device A: Device B:
Type iPhone 3G 16GB iPhone 3G 8GB
Capacity 14.64GB 7.08GB
Audio 5.32GB 1.18GB
Video 48.8GB -
Photos 267.3GB 46.8GB
Apps 1.08GB 505.5MB
Other 343.9MB 370.7MB
Free 7.60GB 5.0GB
Any insights why this is the case?
I am not sure if I understand this correctly, but the figures on the last row (7.6/5 GB) refer to available flash memory, not to the RAM. Therefore they say nothing about the expected performance of a memory-intensive application. Neither the amount of free RAM is exactly telling, because the system will start killing large applications when the memory is scarce and the amount of free memory will go up.
My iPhone app will download a large amount of data from a remote server. What is the maximum amount of data that an iPhone application can store? If you try to store too much data, what happens?
Like a computer, iPhone has RAM and hard disk space. The disk space is advertised on the box (8GB, 16GB, or 32GB). Apple does not advertise the amount of RAM, but the iPhone and iPhone 3G have 128MB and the 3GS has 256MB.
If you fill up memory, your app will receive a Memory Warning notification. If you don't free up enough memory, your app will be terminated.
If you fill up the disk, your app will probably receive disk full errors when you try to write more data.
See this excellent article on memory on the iPhone.
When you first buy an iPhone it will say 8GB, 16GB, 32 GB, or 64 GB on the package. Usually they use 3 GB for something that I don't really know what for. My iPhone 4S has 64 GB on the package but on the usage settings it says that I have 62 GB still a lot but I think that apple uses some GB for some kind of settings. I Hope this Helped :)
For my understanding there are always two types of memory:
the working storage
the "disk space"
So when you have a 16 GB iPhone, does it have 16 GB of working storage? or 16 GB of "disk space"? Which "Memory" is Apple talking about in his Docs, when it comes to performance and memory management? It looks like the working storage, but I am not sure. Actually I thought the iPhone is a huge brick of working storage, since all that stuff is just a solid block of chip memory (no hard drive).
The iPhone has 16GB (or 8 or 4, depending on the model) of non-volatile flash memory that persists even when the power is turned off. It also has 128MB of volatile DRAM that gets lost when the power is turned off. The relative differences are:
Flash memory is cheap, DRAM is expensive
Flash memory is slow, DRAM is fast
Flash memory is non-volatile, DRAM is volatile
The flash memory is essentially like a hard drive, except it's a solid-state memory, not a rotating platter of magnetic dipoles.
Generally, in iPhone development, when you're talking about memory, you're talking about DRAM. DRAM is a more limited resource and more likely to run out, since it's very easy for an app do eat up megabytes by poor memory management. It's a lot harder to run out of flash memory, since doing so would involve writing very large files into the file system.
A simpler way of explaining it:
Every iPhone has 128 MB of RAM. Your application generally can't use more than ~22 MB of it, and it does not use a swapfile for RAM expansion.
The advertised storage capacities (4/8/16 GB) are "disk" space for the filesystem.
The flash memory that makes up most of the iPhone's advertized "memory" is a kind of hybrid between RAM and "disk space" in its most important characteristics:
Less expensive than RAM, more expensive than a harddisk
Sequential transfer rate is lower than RAM's, about the same as a harddisk's (though this really depends on the type and quality of flash memory)
Random access delay is higher than RAM's, but much lower than a harddisk's
The last point is the most important one from a programmer's point of view. All kinds of basic programming techniques and an incredible amount of effort hinges on the fact that compared to most other things that happen in a computer, random access to harddisk memory takes eons because it involves physical movements - and that's where most of your storage is.
This basically means that in an environment with flash memory instead of a harddisk, you can get away with a lot of shit that would absolutely kill an app operating with a harddisk. There aren't really any downsides except for the limited amount of storage. Of course, conversely, it may mean that an app ported from the iPhone to a PC may exhibit godawful performance. Then again, the PC's OS might hide this by caching HD accesses in the more plentiful RAM.