So, there’s 6GB on the DTPO databases, 6GB on the DTTG devices
But on my computer, that 6GB now takes up 19 GB because of the iOS device backups stashing the data.
Maybe everyone has lots of drive space on their startup volume, but I don’t. I see no reason for the DTTG files to be stored in the iOS backup. No reason at all. The only files that should go into the iOS backup made by iTunes are modified files that have not been synced back to DTPO yet. However, after being synced back to DTPO, they shouldn’t persist in the backup files of the device.
This question has already come up, and so perhaps we should put it to users on the Forum:
Apple offers developers only three kinds of disk storage on iOS devices: folders that are regularly purged, folders that offer some persistence but liable to be purged at any time (without warning), and persistent folders. Persistent folders are guaranteed as such because they are subject to backup in iTunes. We chose the guaranteed persistence approach as we felt users would not be happy if their DT data ‘disappeared’ (along with any changes they had not yet synced back to their desktop DT product) on OS updates, device restores, or subject to Apple’s rules on disposable data.
The downside, as you point out, is that keeping your data in a persistent folder means longer, and larger, backup operations when syncing with iTunes. Since we are not operating in a desktop paradigm, we as developers and you as users have very limited options in this matter.
If users on the Forum believe that sacrificing “always available” access to your DT data is a reasonable trade off in return for a return to faster, smaller backups in iTunes, we would take that into consideration for future updates of the product. If not, we are stuck with the current situation until Apple offers more flexibility in its storage options or allows users to selectively determine what is to be backed up in iTunes.
Scroll down from the table to the “What is Backed Up?” Section and we see the following two statements from Apple:
Then, set apart from the rest of the text as an emphasis, Apple gives this prominent notice:
Thus it looks like you can separate data between the backed up and not backed up locations.
Backups would seem necessary only with option settings, logs, and the situation where a record is modified (or hence created) on the iPad. I think everyone would expect, and agree, that this data, because it represents work that has not yet been put back to the DTPO repository needs to be backed up until synced.
So why not store modified (but yet unsynced) records in the /Documents folder, and store the rest of the synced records in the /Library/Caches?
Couldn’t this behavior be set with a user option switch? I realize this would introduce a decision tree into the file operations, but it seems like Apple has not made this impossible, and you guys really are wizards at scripted logic and file operations. I can attest to that by the soundness with which I see DTPO operate.
I guess I’m not seeing the either/or proposition you suggest by what Apple has on the online reference.
I would support the idea of a user preference, but am also conscious that there are other areas/suggestions mentioned already on this board where some aspect of user preference may have greater support. Where do we vote
Having a default of a full backup may be the safest option, I suppose.
with all due respect, all of the unmodified data in DTTG is backed up on your mac because it exists in DTPO, is it not? Thus, you are making a back up of a mobile backup. Never mind if you backup your DTPO databases, then you have four copies of the data, plus two more each for each iOS device.
How many copies of those unmodified record do you need? isn’t two enough? why make a third?
the only thing necessary to back-up per se is the modified files, right?
This issue has become a major problem for me. I have had to turn off the backup (using BackOff) so that I can sync my calendar information etc. with my iPad and iPhone However, with the new iOS imminent I need one full backup, so I started one last night and it took 10 hours to complete! The backup file has 55000 items and is 5GB in size. There must surely be another way…
As I described in my earlier post, the “Application Home/Library/Caches” directory is temporary storage - it is not regularly purged, but it is subject to purging under a number of conditions. We do appreciate that this is a set of least evil options, but our decision was based on making sure your data remains persistent under all conditions. The purpose of a mobile application is to take your data with you - always. That promise would be broken if we place your data in a directory that Apple can and will, under certain conditions, empty or purge. The Apple document cited above appeared a few months ago and vaguely contradicts earlier Apple guidelines on the matter. That said, the semantic definition of a “cache” is storage that is more persistent than a temp directory, but nonetheless holding data that can be eliminated since by definition it can be restored from the source. We will look into making this a user option in a future release of DTTG, with the caveat that your data will eventually disappear under certain circumstance - the above Apple documentation “guarantees” this fact.
Mike, with all due respect, there is only one circumstance in which the caches directory is purged: a restore operation. The way you describe it makes it sound like you understand it to be arbitrary, when the Apple doc above says it happens at a known time: during a device restore ( which, by the way, for us non-developers happens when we get a new phone, not frequently). I have only performed one device restore ever, and that was after I installed a dev release of ios 3 early and had to restore in order to downgrade to 2 and await the official release of ios 3.
Once in 3 years. So if I had DTTG, the only time in three years that my DTTG unmodified records would have been deleted was the one time I restored it. That’s hardly as arbitrary and unpredictable as you seem to imply it to be.
You also seem to describe the expectation to be that the DTTG repository should be permanent. I agree in so far as I wouldn’t want records arbitrarily disappearing, but that wouldn’t happen in the apple suggested location in the caches directory.
So, it’s kind of hard to reconcile what you are saying against what Apple says about the caches directory. Moreover, if I have to go through a full restore of the device, I would expect that I would need to resync DTTG afterward. Thus, let’s not forget what the reality of the only time the records would be purged would be. After all, DTTG is described as a “companion” app, not as a backup device of redundancy.
Moreover, with my suggestion above that only records modified by DTTG but not yet synced to DTPO be stored in the persistent documents folder, the modified records would survive a restore because they were backup up in the device mdfiles by iTunes.
So, I’m still not seeing the rationale you are proposing. Either apple is not describing the caches purge correctly when they say it happens at a known event: a device restore; or, you are selecting a data storage schema that is inconsistent with the application’s purpose, which has the downside of the things I mention above, besides the other concerns of so many replicated data stores all over the places introducing error probabilities.
I think it’s clear that Apple provided the right place for unmodified records in the caches directory because the user can remake those files by pressing sync. The only time the user would be forced to do that is after a traumatic device restore. It seems reasonable that the user would not be relying on the DTTG device to be a backup of the DTPO database, but you seem to describe it like you want it to be one.
Again, the only data that would need to survive a full device restore would be records modified on the DTTG and settings. Everything else is restored with a sync operation, right? Or is there some other problem you aren’t saying here?
The best response we have to this discussion is as follows:
Some users are requesting they be given an option to store their DTTG data in an area that is not subject to ‘secondary’ syncing with iTunes. Without making promises, this feature is high on the list of proposed changes to forthcoming updates to DTTG.
Further discussion of the technical aspects of this matter skirt, or cross over, the line imposed by Apple’s Developer NDA. We are more than happy to continue the technical discussion on Apple’s Developer Forums, where Apple engineers can clear up any misunderstandings (on our part) with respect to the internal OS policy regarding the persistence policy imposed upon the storage facilities available to iOS developers. If you start or join a thread on those Forums, just send us a link and we will further discuss the technical approach needed.
For the record, and for Pete’s sake, NOTHING I have posted contravenes Apple’s NDA. I cited the iOS dev reference guide from google and I am not a developer. Apple has thereby disclosed the material I cited for public use. To imply some sort of impropriety here is outrageous.
Moreover, I dont understand what you are trying to say in the rest of your post. Are you telling me to shut up?
EDIT: I see now that you were referring to some sort of apple forum. I’m assuming that’s a thing for developers, of which I am not. As I pointed out above, I cited material apple puts out for public use. I posted here because it amazed me that a devontechnologies product didn’t seem to operate in a way apple proscribed. After so much experience with the DT team here by lurking for so long prior to ever posting, I was scratching my head and still am.
Devontechnologies usually has the handle on apple Guidelines and the inconsistencies I saw between DTTG and other iOS apps caused me to find out if apple would really be as ambiguous as you implied. I’m still not convinced that there is any ambiguity on apple’s part. In fact, apple itself says to use the caches folder for the precise use DTTG has for unmodified records. There’s nothing NDA related or ambiguous about it.
That leaves the apparent contradiction in DTTG that you describe it to be a bulletproof repository of records rather than a companion app as advertised. There’s nothing wrong with allowing that persistent backup to happen but by forcing it as default behavior seems incorrect as even Apple warns against the approach chosen because it creates the problems encountered.
I apologize if any offense was taken to my previous post - certainly none was intended. As I understand it, the issue at hand concerns the added time and size of iTunes backups when DTTG data is stored in iTunes as well. As stated in the post above, we are working on offering an option in a future update to DTTG that allows users to choose how they wish to store their DT data. My role in this discussion is to listen to customer feedback and improve this product to meet the needs of our users. I welcome further discussion on this subject and all others directed towards making DTTG the best iOS application you own.
If I knew this I would have saved my time and money on DTTG , the first time heard of "banana ware " was on DT forum explaining why it took so long to release DTTG , ie software that ripen s by releasing software that ripens by making customers beta testers rather than releasin "quality"products
