Mac development question

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Doug Currie-2

On Oct 23, 2012, at 4:58 PM, Igor Korot <[hidden email]> 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/<application name>

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Igor Korot
Hi, Doug,

On Tue, Oct 23, 2012 at 2:26 PM, Doug Currie <[hidden email]> wrote:
>
> On Oct 23, 2012, at 4:58 PM, Igor Korot <[hidden email]> 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/<application name>

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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Petite Abeille-2

On Oct 23, 2012, at 11:35 PM, Igor Korot <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Simon Slavin-3
In reply to this post by Igor Korot

On 23 Oct 2012, at 10:35pm, Igor Korot <[hidden email]> wrote:

> On Tue, Oct 23, 2012 at 2:26 PM, Doug Currie <[hidden email]> wrote:
>>
>> On Oct 23, 2012, at 4:58 PM, Igor Korot <[hidden email]> 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/<application name>
>
> 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/<application name>".  If each user needs their own file then it belongs in "~/Library/Application Support/<application 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 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Igor Korot
Hi,

On Tue, Oct 23, 2012 at 3:10 PM, Simon Slavin <[hidden email]> wrote:

>
> On 23 Oct 2012, at 10:35pm, Igor Korot <[hidden email]> wrote:
>
>> On Tue, Oct 23, 2012 at 2:26 PM, Doug Currie <[hidden email]> wrote:
>>>
>>> On Oct 23, 2012, at 4:58 PM, Igor Korot <[hidden email]> 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/<application name>
>>
>> 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/<application name>".  If each user needs their own file then it belongs in "~/Library/Application Support/<application 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 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Simon Slavin-3

On 23 Oct 2012, at 11:41pm, Igor Korot <[hidden email]> wrote:

> On Tue, Oct 23, 2012 at 3:10 PM, Simon Slavin <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Darren Duncan
In reply to this post by Igor Korot
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Igor Korot
In reply to this post by Simon Slavin-3
Simon,

On Tue, Oct 23, 2012 at 5:24 PM, Simon Slavin <[hidden email]> wrote:

>
> On 23 Oct 2012, at 11:41pm, Igor Korot <[hidden email]> wrote:
>
>> On Tue, Oct 23, 2012 at 3:10 PM, Simon Slavin <[hidden email]> 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 'Save', and any user may have multiple copies of the data, because they can hit 'Save' lots of times ?

It goes by scenario 1 - one database file for everybody.

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

Thank you.

>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Igor Korot
In reply to this post by Darren Duncan
Darren,

On Tue, Oct 23, 2012 at 8:53 PM, Darren Duncan <[hidden email]> 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Darren Duncan
Igor Korot wrote:

> Darren,
>
> On Tue, Oct 23, 2012 at 8:53 PM, Darren Duncan <[hidden email]> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Mac development question

Simon Slavin-3
In reply to this post by Igor Korot

On 24 Oct 2012, at 5:29am, Igor Korot <[hidden email]> 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/<app name>

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

<https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW3>

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

>
> On 24 Oct 2012, at 5:29am, Igor Korot <[hidden email]> 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/<app name>
>
> 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
>
> <https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW3>
>
> 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users