Simon, On Tue, Oct 23, 2012 at 5:24 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > 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.
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 > 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
