Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Since I have asked this question, I have implemented the following solution:</p> <ul> <li>I have redesigned my app so that it now immediately processes a file handed over to it via documentation interaction, without involving the user at all. Unless the app crashes, or is suspended and killed, in the middle of processing the file, this should always leave me with a clean <code>Documents/Inbox</code>.</li> <li>To cover the (rare) case of a crash or suspend/kill, my app removes the <code>Documents/Inbox</code> folder when it is launched normallly (i.e. without the purpose of document interaction). To achieve this the <code>Documents/Inbox</code> folder path is necessarily hardcoded.</li> </ul> <p>Here are the thoughts that went into the solution:</p> <ul> <li>Redesigning the app <ul> <li>Initially it seemed like a good idea to offer the user a choice how she wanted a file to be processed - after all, offering a choice would make the app more flexible and provide the user with more freedom, right?</li> <li>I then realized that I was trying to shift the responsibility for deciding how document interaction should be handled to the user. So I bit the bullet, made the hard decisions up-front, and then went happily on to implement a simple and straightforward document interaction system in my app.</li> <li>As it turns out, no user interaction also means that the app is easier to use, so here's a win-win situation, both for me as a developer and for the users of my app.</li> </ul></li> <li>Removing <code>Documents/Inbox</code> folder during app launch <ul> <li>Removing the <code>Documents/Inbox</code> folder during app launch is just an afterthought, not an <em>essential</em> part of how my app handles document interaction</li> <li>Therefore I am quite willing to take the risk that Apple might change the filesystem path of the inbox folder at some point in the future. The worst thing that can happen is that my app will start to accumulate a few files that are leftovers from crash or suspend/kill scenarios.</li> </ul></li> </ul> <p>And finally, a few thoughts for further development:</p> <ul> <li>If it ever turns out that there <em>really</em> should be more than one way how the app can handle document interaction, I would add a user preference so that the user has to make a decision up-front, and the app does not need to stop its processing to ask the user for a choice.</li> <li>If it ever turns out that user interaction is absolutely unavoidable in the middle of the document interaction handling process, I would look at this approach: 1) Before the user is allowed to interact, move the file from <code>Documents/Inbox</code> to some sort of "staging" folder; 2) Let user interaction take place; 3) Process the file in the "staging" folder, in whatever way the user chose. The important thing here is that the "staging" folder is <em>in a known location and is completely managed by the app</em>. Should the user suspend and then kill the app in the middle of the user interaction step, an appropriate action can simply be taken when the app is launched for the next time.</li> </ul> <hr> <p><strong>EDIT</strong></p> <p>In iOS 7 it is no longer possible to remove <code>Documents/Inbox</code> once it has been created. The <code>NSFileManager</code> method <code>removeItemAtPath:error:</code> returns Cocoa error 513 which resolves to <code>NSFileWriteNoPermissionError</code> (cf. <a href="https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Constants/Reference/reference.html" rel="noreferrer">this list of Foundation constants</a>). The error does not seem to be related to POSIX permissions, however, it rather looks as if the system itself interferes with the attempt at deletion (possibly protection of the app bundle structure?).</p> <p>Also noteworthy is that nowadays Apple explicitly names <code>Documents/Inbox</code> in the documentation of the <code>UIApplicationDelegate</code> method <code>application:openURL:sourceApplication:annotation:</code>. They also say that</p> <blockquote> <p>[...] Your app has permission to read and delete files in this directory but does not have permission to write to them. If you want to modify a file, you must move it to a different directory first.</p> </blockquote> <p>There is more stuff about possible encryption of the files in <a href="https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplicationDelegate_Protocol/" rel="noreferrer">the docs</a>, but you should read up on that yourself.</p>
    singulars
    1. This table or related slice is empty.
    1. POGood way to manage the Documents/Inbox folder in an iOS app
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USherzbube
    1. USherzbube
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POGood way to manage the Documents/Inbox folder in an iOS app
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO"...I bit the bullet, made the hard decisions up-front..." - good for you! Too often developers handle complexity by throwing up their hands and deferring decisions to the user, which can rapidly lead to a hard-to-understand and frustrating app experience. This solution is very close to what I would've responded with.
      singulars
      1. PO
      1. USTim
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload