Re: [sqlite] Mac development question

[Igor Korot]

List,
Apologies for moving off-topic.
The discussion is now moved to be on PM.

Thank you.

On Wed, Oct 24, 2012 at 3:39 AM, Simon Slavin  wrote:
>
> On 24 Oct 2012, at 5:29am, Igor Korot  wrote:
>
>> It looks like you are "Apple person" that I got suggeted to talk to. ;-)
>> The situation is as follows: I am developing an application that will
>> utilize not just SQLite but some other library.
>> According to the "development standards" on *nix-like systems programs
>> should use dynamic linking (use .so), and
>> not static linking (not use .a). Since Apple Mac OS X follows *nix,
>> this will be the approach.
>> According to the same guidelines all those libraries should go to
>> /usr/lib (or /usr/local/lib).
>
> Well, for SQLite the recommendation is that you just compile the .h and .c 
> SQLite files into your application.  Doesn't need a library.  And it ensures 
> that you know which version of SQLite your app is using.
>
>> Now how else I can place everything in the proper place without
>> installer/distribution package? On Mac they have
>> dmg extension IIRC.
>
> For other libraries you want to install, do what I previously described and 
> include a copy of the library in your application.  When the application is 
> run, it looks for a copy of the library in the right place, and if it doesn't 
> find one it copies its own copy from its bundle into there.  In other words, 
> your application does its own installation of any support files (including 
> libraries) that it needs, if they don't already exist.  Then, if your 
> programming language makes it necessary, it restarts itself so it can use 
> them.
>
> My /usr/lib folder does have files in.  They have '.dylib' extensions, not 
> .so, except for the PAM stuff which is '.so.2'.  I don't know what that means.
>
>> Now AFAICS, those distribution packages (or dmg) files can be called
>> installation packages.
>
> dmg is a disk image.  They can be compressed which makes for smaller 
> downloads, which is why they're popular.  You might distribute your 
> application, documentation, sample files, etc. all in one disk image.  That's 
> standard.  But application installers as separate apps or packages are 
> frowned on in the Mac community.  They're used only when you have a large 
> suite of applications all of which share common components, e.g. Microsoft 
> Office, where building support installation logic into each individual 
> application would be wasteful.
>
>> This will be one copy for all users.
>> The database will be populated originally by me and will be supplied
>> alone with the application bundle and those additional library.
>
> You explained it clearly now.  Your application can include a copy of that 
> file with starter information inside its own bundle.  The writable version 
> belongs in the shared application support folder, which on an English-based 
> standalone locally-mounted Mac is
>
> /Library/Application Support/
>
> However, there is a system call which use should use to get that path, and 
> the system call takes into account what your user has named your application, 
> what language they are using, and whether they have a non-standard setup 
> which keeps their support files on a network drive or something.  So rather 
> than hardwire this path into your app you should use the system call
>
> URLsForDirectory:inDomains:
>
> and feed it
>
> NSApplicationSupportDirectory
>
> as described in the 'Locating Items in the Standard Directories' section of
>
> 
>
> Listing 2-1 on that page is a pre-written function you can use to find 
> exactly that directory we've been discussing.
>
> Hope this helps.  We have drifted far away from matters to do with SQLite, so 
> if you want to pursue the more Maccish side of this, you might email me 
> directly.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Mac development question

[Simon Slavin]

On 24 Oct 2012, at 5:29am, Igor Korot  wrote:

> It looks like you are "Apple person" that I got suggeted to talk to. ;-)
> The situation is as follows: I am developing an application that will
> utilize not just SQLite but some other library.
> According to the "development standards" on *nix-like systems programs
> should use dynamic linking (use .so), and
> not static linking (not use .a). Since Apple Mac OS X follows *nix,
> this will be the approach.
> According to the same guidelines all those libraries should go to
> /usr/lib (or /usr/local/lib).

Well, for SQLite the recommendation is that you just compile the .h and .c 
SQLite files into your application.  Doesn't need a library.  And it ensures 
that you know which version of SQLite your app is using.

> Now how else I can place everything in the proper place without
> installer/distribution package? On Mac they have
> dmg extension IIRC.

For other libraries you want to install, do what I previously described and 
include a copy of the library in your application.  When the application is 
run, it looks for a copy of the library in the right place, and if it doesn't 
find one it copies its own copy from its bundle into there.  In other words, 
your application does its own installation of any support files (including 
libraries) that it needs, if they don't already exist.  Then, if your 
programming language makes it necessary, it restarts itself so it can use them.

My /usr/lib folder does have files in.  They have '.dylib' extensions, not .so, 
except for the PAM stuff which is '.so.2'.  I don't know what that means.

> Now AFAICS, those distribution packages (or dmg) files can be called
> installation packages.

dmg is a disk image.  They can be compressed which makes for smaller downloads, 
which is why they're popular.  You might distribute your application, 
documentation, sample files, etc. all in one disk image.  That's standard.  But 
application installers as separate apps or packages are frowned on in the Mac 
community.  They're used only when you have a large suite of applications all 
of which share common components, e.g. Microsoft Office, where building support 
installation logic into each individual application would be wasteful.

> This will be one copy for all users.
> The database will be populated originally by me and will be supplied
> alone with the application bundle and those additional library.

You explained it clearly now.  Your application can include a copy of that file 
with starter information inside its own bundle.  The writable version belongs 
in the shared application support folder, which on an English-based standalone 
locally-mounted Mac is

/Library/Application Support/

However, there is a system call which use should use to get that path, and the 
system call takes into account what your user has named your application, what 
language they are using, and whether they have a non-standard setup which keeps 
their support files on a network drive or something.  So rather than hardwire 
this path into your app you should use the system call

URLsForDirectory:inDomains:

and feed it

NSApplicationSupportDirectory

as described in the 'Locating Items in the Standard Directories' section of



Listing 2-1 on that page is a pre-written function you can use to find exactly 
that directory we've been discussing.

Hope this helps.  We have drifted far away from matters to do with SQLite, so 
if you want to pursue the more Maccish side of this, you might email me 
directly.

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

Re: [sqlite] Mac development question

[Darren Duncan]

Igor Korot wrote:

Darren,

On Tue, Oct 23, 2012 at 8:53 PM, Darren Duncan  wrote:

You should not have an application installer, at all.  Instead, you can ask
the question on where to store the database when the user opens your
program.  Or better yet, your application should have menu commands like
"new database" and "open database", where if they choose the former then you
ask them (using Apple's standard method) where that database goes.  If they
chose "open database", then you can let them open an existing one, or one
should be able to double-click the database file in the Finder to open that
one instead, which is what Mac users expect.  As such, your application
should support having multiple databases per user, even if they may
typically just use one.  If users open your program directly and not by
double-clicking on a database file, you could automatically bring up a
prompt to make a new one, as if they used the "new database" menu. -- Darren
Duncan


I doubt the user of the application will wait couple of minutes while
the database
will be created and the data will be populated for about 5000 records.
They won't come from the internet and I'm planning to insert them as a bulk
procedure from the Excel file I have.

Thank you.


Why would it take that long?  Creating a database with 5000 records on a modern 
machine shouldn't take more than about 1 second or so.  But even if it takes 
longer, my comment is about letting the user choose from the application itself 
where the data they edit goes, and your comments about the user waiting have 
nothing to say against that. -- Darren Duncan

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

Re: [sqlite] Mac development question

[Igor Korot]

Darren,

On Tue, Oct 23, 2012 at 8:53 PM, Darren Duncan  wrote:
> Igor Korot wrote:
>>
>> 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.
>>
>> 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.
>
>
> You should not have an application installer, at all.  Instead, you can ask
> the question on where to store the database when the user opens your
> program.  Or better yet, your application should have menu commands like
> "new database" and "open database", where if they choose the former then you
> ask them (using Apple's standard method) where that database goes.  If they
> chose "open database", then you can let them open an existing one, or one
> should be able to double-click the database file in the Finder to open that
> one instead, which is what Mac users expect.  As such, your application
> should support having multiple databases per user, even if they may
> typically just use one.  If users open your program directly and not by
> double-clicking on a database file, you could automatically bring up a
> prompt to make a new one, as if they used the "new database" menu. -- Darren
> Duncan

I doubt the user of the application will wait couple of minutes while
the database
will be created and the data will be populated for about 5000 records.
They won't come from the internet and I'm planning to insert them as a bulk
procedure from the Excel file I have.

Thank you.

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

Re: [sqlite] Mac development question

[Igor Korot]

Simon,

On Tue, Oct 23, 2012 at 5:24 PM, Simon Slavin  wrote:
>
> On 23 Oct 2012, at 11:41pm, Igor Korot  wrote:
>
>> On Tue, Oct 23, 2012 at 3:10 PM, Simon Slavin  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.

It looks like you are "Apple person" that I got suggeted to talk to. ;-)
The situation is as follows: I am developing an application that will
utilize not just SQLite but some other library.
According to the "development standards" on *nix-like systems programs
should use dynamic linking (use .so), and
not static linking (not use .a). Since Apple Mac OS X follows *nix,
this will be the approach.
According to the same guidelines all those libraries should go to
/usr/lib (or /usr/local/lib).

Now how else I can place everything in the proper place without
installer/distribution package? On Mac they have
dmg extension IIRC.
Now AFAICS, those distribution packages (or dmg) files can be called
installation packages.

>
>> 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.

OK.

>
> 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.

This will be one copy for all users.
The database will be populated originally by me and will be supplied
alone with the application bundle and those additional library.

>
> 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 '

Re: [sqlite] Mac development question

[Darren Duncan]

Igor Korot wrote:

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.

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.


You should not have an application installer, at all.  Instead, you can ask the 
question on where to store the database when the user opens your program.  Or 
better yet, your application should have menu commands like "new database" and 
"open database", where if they choose the former then you ask them (using 
Apple's standard method) where that database goes.  If they chose "open 
database", then you can let them open an existing one, or one should be able to 
double-click the database file in the Finder to open that one instead, which is 
what Mac users expect.  As such, your application should support having multiple 
databases per user, even if they may typically just use one.  If users open your 
program directly and not by double-clicking on a database file, you could 
automatically bring up a prompt to make a new one, as if they used the "new 
database" menu. -- Darren Duncan

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

Re: [sqlite] Mac development question

[Simon Slavin]

On 23 Oct 2012, at 11:41pm, Igor Korot  wrote:

> On Tue, Oct 23, 2012 at 3:10 PM, Simon Slavin  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

Re: [sqlite] Mac development question

[Igor Korot]

Hi,

On Tue, Oct 23, 2012 at 3:10 PM, Simon Slavin  wrote:
>
> On 23 Oct 2012, at 10:35pm, Igor Korot  wrote:
>
>> On Tue, Oct 23, 2012 at 2:26 PM, Doug Currie  wrote:
>>>
>>> On Oct 23, 2012, at 4:58 PM, Igor Korot  wrote:
>>>
 1. I know on Mac I need to build an application bundle. Where do I
 store the .db file relative to the bundle?
 Inside it? Home directory? Somewhere on the hard drive? What is the
 usual place for it?
>>>
>>> If the database is read-only, you can sore it inside the bundle.
>>
>> Nope. There will be new records insertion/old record update/delete.
>>
>>> If it is application configuration, you should store it in the 
>>> application's directory in the user's ~/Library/Application 
>>> Support/
>>
>> Nope. It is for an application data.
>>
>>> If the database is a document, you should store it wherever the use directs 
>>> via a file dialog.
>>
>> So then user home directory (~) should be fine, right?
>
> No.  Never put anything in the home directory.  That's just for other things 
> Apple has already put in there.  Most user's don't realise they have a home 
> directory and will arbitrarily delete things they find there: "I don't know 
> what this is for and I don't care about it.".

OK.
>
> 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.

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.

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.

Thank you.

>
> If your SQLite database is used to support the inner workings of your 
> application that the user knows nothing about and never has to manipulate 
> themself (e.g. a web browser might keep an internal database of DNS 
> addresses) then there are two possibilities.  If you only need one of these 
> files, no matter which user is using your app, then it belongs in 
> "/Library/Application Support/".  If each user needs their 
> own file then it belongs in "~/Library/Application Support/ name>" as Doug wrote.  Apple provides an API which will provide the correct 
> pathname for you, as Petite wrote.  You would never have to know the above 
> path yourself unless you're writing in a language which cannot access Apple's 
> standard API.  If one of these documents disappears between runs of your 
> program then your application must be able to recover from this situation 
> itself, perhaps by creating a new empty database or by duplicating a copy 
> from its application bundle.
>
> If your SQLite database is used to store the user's own preferences about how 
> the application should work which change with the user's own preferences, 
> then the file should be stored in the user's Preferences folder.  Again, 
> Apple provides an API which will produce the right path for you, and you 
> should never generate it yourself.  However storing preferences in a SQLite 
> database is non-standard: Apple already provides a standard mechanism for 
> storing user preferences.  If one of these documents disappears between runs 
> of your program then your application must be able to recover from this 
> situation itself, perhaps by creating a new empty database or by duplicating 
> a copy from its application bundle.
>
> All of the above is second-nature to any Macintosh programmer.  They don't 
> even have to think about this stuff, just like a Windows programmer expects 
> to see their application show up in the Start menu and on the Taskbar.  It 
> may be that you should talk to an experienced Mac programmer before porting 
> your application across so you do this 

Re: [sqlite] Mac development question

[Simon Slavin]

On 23 Oct 2012, at 10:35pm, Igor Korot  wrote:

> On Tue, Oct 23, 2012 at 2:26 PM, Doug Currie  wrote:
>> 
>> On Oct 23, 2012, at 4:58 PM, Igor Korot  wrote:
>> 
>>> 1. I know on Mac I need to build an application bundle. Where do I
>>> store the .db file relative to the bundle?
>>> Inside it? Home directory? Somewhere on the hard drive? What is the
>>> usual place for it?
>> 
>> If the database is read-only, you can sore it inside the bundle.
> 
> Nope. There will be new records insertion/old record update/delete.
> 
>> If it is application configuration, you should store it in the application's 
>> directory in the user's ~/Library/Application Support/
> 
> Nope. It is for an application data.
> 
>> If the database is a document, you should store it wherever the use directs 
>> via a file dialog.
> 
> So then user home directory (~) should be fine, right?

No.  Never put anything in the home directory.  That's just for other things 
Apple has already put in there.  Most user's don't realise they have a home 
directory and will arbitrarily delete things they find there: "I don't know 
what this is for and I don't care about it.".

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. 

If your SQLite database is used to support the inner workings of your 
application that the user knows nothing about and never has to manipulate 
themself (e.g. a web browser might keep an internal database of DNS addresses) 
then there are two possibilities.  If you only need one of these files, no 
matter which user is using your app, then it belongs in "/Library/Application 
Support/".  If each user needs their own file then it belongs 
in "~/Library/Application Support/" as Doug wrote.  Apple 
provides an API which will provide the correct pathname for you, as Petite 
wrote.  You would never have to know the above path yourself unless you're 
writing in a language which cannot access Apple's standard API.  If one of 
these documents disappears between runs of your program then your application 
must be able to recover from this situation itself, perhaps by creating a new 
empty database or by duplicating a copy from its application bundle.

If your SQLite database is used to store the user's own preferences about how 
the application should work which change with the user's own preferences, then 
the file should be stored in the user's Preferences folder.  Again, Apple 
provides an API which will produce the right path for you, and you should never 
generate it yourself.  However storing preferences in a SQLite database is 
non-standard: Apple already provides a standard mechanism for storing user 
preferences.  If one of these documents disappears between runs of your program 
then your application must be able to recover from this situation itself, 
perhaps by creating a new empty database or by duplicating a copy from its 
application bundle.

All of the above is second-nature to any Macintosh programmer.  They don't even 
have to think about this stuff, just like a Windows programmer expects to see 
their application show up in the Start menu and on the Taskbar.  It may be that 
you should talk to an experienced Mac programmer before porting your 
application across so you do this and other things in the way a Mac user would 
expect.

>> SQLite itself doesn't care where the database is stored as long as the 
>> directory it is in is read/write.
>> 
>>> 2. When I done on Windows I should be able to just copy the file and
>>> drop it on the Mac HD, right?
>> 
>> Yes.
> 
> Good.

Right.  SQLite database file format is cross-platform.  If you have one that 
works on one platform, you can just copy it over and it'll work.

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

Re: [sqlite] Mac development question

[Petite Abeille]

On Oct 23, 2012, at 11:35 PM, Igor Korot  wrote:

> So then user home directory (~) should be fine, right?

No. Don't. Lookup NSApplicationSupportDirectory and check the documentation. 
Apple has clear APIs and guidelines about where to put what. Learn them.

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

Re: [sqlite] Mac development question

[Igor Korot]

Hi, Doug,

On Tue, Oct 23, 2012 at 2:26 PM, Doug Currie  wrote:
>
> On Oct 23, 2012, at 4:58 PM, Igor Korot  wrote:
>
>> 1. I know on Mac I need to build an application bundle. Where do I
>> store the .db file relative to the bundle?
>> Inside it? Home directory? Somewhere on the hard drive? What is the
>> usual place for it?
>
> If the database is read-only, you can sore it inside the bundle.

Nope. There will be new records insertion/old record update/delete.

>
> If it is application configuration, you should store it in the application's 
> directory in the user's ~/Library/Application Support/

Nope. It is for an application data.

>
> If the database is a document, you should store it wherever the use directs 
> via a file dialog.

So then user home directory (~) should be fine, right?

>
> SQLite itself doesn't care where the database is stored as long as the 
> directory it is in is read/write.
>
>> 2. When I done on Windows I should be able to just copy the file and
>> drop it on the Mac HD, right?
>
> Yes.

Good.

Thank you.

>
> e
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Mac development question

[Doug Currie]

On Oct 23, 2012, at 4:58 PM, Igor Korot  wrote:

> 1. I know on Mac I need to build an application bundle. Where do I
> store the .db file relative to the bundle?
> Inside it? Home directory? Somewhere on the hard drive? What is the
> usual place for it?

If the database is read-only, you can sore it inside the bundle.

If it is application configuration, you should store it in the application's 
directory in the user's ~/Library/Application Support/

If the database is a document, you should store it wherever the use directs via 
a file dialog.

SQLite itself doesn't care where the database is stored as long as the 
directory it is in is read/write.

> 2. When I done on Windows I should be able to just copy the file and
> drop it on the Mac HD, right?

Yes.

e

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

[sqlite] Mac development question

[Igor Korot]

Hi, ALL,
I'm developing a program that will be cross-platform and utilize
SQLite database.
My main development platform is Windows and when I finish I will  move to Mac.

My question is:

1. I know on Mac I need to build an application bundle. Where do I
store the .db file relative to the bundle?
Inside it? Home directory? Somewhere on the hard drive? What is the
usual place for it?

2. When I done on Windows I should be able to just copy the file and
drop it on the Mac HD, right?

Thank you.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users