On 23 Oct 2012, at 11:41pm, Igor Korot <ikoro...@gmail.com> wrote:

> On Tue, Oct 23, 2012 at 3:10 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> 
>> If your user considers these SQLite databases to be their own documents 
>> (i.e. like a word processor saves text documents, your application saves 
>> SQLite databases) then you must use Apple's standard 'Save' and 'Open' APIs 
>> to allow the user to decide where the files go. This gives the user all the 
>> facilities they're used to, like drag-and-drop and automatically picking the 
>> most recently used directory.  Most users will chose to keep their documents 
>> on the desktop or in their own Documents folder, but will regard any 
>> application which doesn't give them the ability to choose as weird and 
>> broken and will not use it.  If one of these files disappears between runs 
>> of your program then the application just considers that saved document to 
>> have been deleted.
> 
> However, from you response I gather I will need an application
> installer which will ask the user "Where
> do you want to store the database with the data?" Am I correct?
> If yes, what I can use in order to create such distribution package? I
> presume it should be something
> like XCode installer, which asks couple of questions first and then
> copy everything.
> If no, then could you clarify, please.

Okay, you nearly got it.  First, Macs don't use installers.  Your user drags 
your application to wherever they want to keep it.  Then they run your 
application.  Your application is responsible for creating support files 
wherever it needs them to be.  If it starts up and notices that its support 
files are missing (which they definitely will be the first time, and may be 
subsequent times) then it's responsible for making new ones. It can make these 
files by you writing complicated software which creates exactly the right files 
in the right place, or by simply copying a pre-made file or folder structure 
from its bundle straight into the user's filespace (far simpler and faster).  
The only time I see installers is from programmers used to non-Mac and Mac 
users hate them.

> Well, that the closest definition of the data I'm about to put into
> this database.
> I am making a sport related application and need to store the data
> about the teams, players etc.
> User should be able to add/edit/delete this information and this
> information will be presented
> in the GUI.
> Now the application is not creating the database - I am. The
> application/user is just uses the data
> in it.
> So on the first start there should be records in the db already.

Sorry but I need clarification of the above.  This database that you say you 
start off creating -- "I am" in the above.  Pretend that the Mac this 
application is installed on one computer shared by two different people, each 
with their own user account, and both of whom like using your application.

Your starting data can be got from anywhere.  You can copy it from inside your 
application bundle.  Or you can download it from a page on a web server.  Or 
your program can create some random starting data.  What governs where the data 
should be kept is whether you need one copy that's used for all users, or one 
copy per user, or one copy for each time a user hits 'save'.  Ignore what the 
source of the 'starting' data is, and pretend your two users sharing one 
computer have both been using your application for months.

After a couple of months of use is there just one copy of the database for the 
application, and all users share the same data no matter who is logged in, and 
changes made by one user show up when the other user uses your program ?  Or do 
both users need their own copy of this database, but this database doesn't 
represent a specific save, it's more like background information not related to 
any 'Save' the user has created ?  Or is this a particular copy of the user's 
data, created when they hit 'Save', and any user may have multiple copies of 
the data, because they can hit 'Save' lots of times ?

The answer tells us where the data should be saved, and which API function you 
use to get the unix path your program should use.  For the first two options 
above, there's an API call you make which hands back the appropriate folder 
without user interaction.  For the third option, where your user is making 
their own save files, you call a different API which lets the user pick where 
they want their new saved file.  It presents the folder structure to the user, 
let's them pick a folder, then hands back to your program the path for the 
folder the user picked.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to