I am starting to develop my first Mac OS X application using Xcode. My background is LAMP, so I typically store everything in a MySQL database. What's the correspondent in OS X?
My application will simply allow the user to enter new data, and then to retrieve it based on filters.
I am not looking for specific code, but for some pointers as to how storing data into databases work in OS X. I have found very little resource on this subject.
SQLite is used in many situations where a database server isn't required. Apple uses it for things like their Mail app. You can use some of the built-ins of Xcode (like sqlite.h) or a command-line shim of some kind. Other variants of SQL will require a separate download.
Core Data uses an object model which may be more convenient in a storage sense, though it has a moderate footprint and learning curve, and it's not cross-platform. Which may be important for the data migration that's common with database work.
If you're just starting with desktop programming from a LAMP background, you could look into "wrapper" apps that let you package LAMP software on the desktop with a native GUI. Might be easier than going Objective-C from scratch since it's one of the more obtuse languages out there. Xojo is also nice if you're used to VisualBasic and need to do cross-platform work.
Related
I would like to embed a graph database in my application (shipping for windows, linux & MAC). I narrowed the search down to ArangoDB & OrientDB. I was able to get embedded OrientDB to work but I'd still like to try ArangoDB to make an informed decision. Documentation for OrientDB embedded version is pretty clear while I can't find anything for ArangoDB. ArangoDB is written in C++ so I also have to figure out how to make it be portable across platforms and how to install it with my application. The usage of ArangoDB (or OrientDB) should be transparent to the users of our application. Thanks!
Update: I forgot to mention, our application is in C++. We were looking for instructions that can help us build ArangoDB binary with our existing modules. We then can figure out how to load the binaries and talk to them.
It's possible to install an instance of ArangoDB with your application installation.
It installs into it's own directory, and its key assets are:
ArangoDB Binaries
ArangoDB Data files
ArangoDB Log files
ArangoDB Foxx Applications (optional)
ArangoDB can run as a service, and it is configured via a file called arangod.conf.
This file centrally controls settings like the ports it runs on, the IP addresses it listens to, the database engine to use, SSL and security settings, and much more.
Taking Windows as an example, you can do a silent installation of ArangoDB, and then use tools like PowerShell or DOS batch files to stop/start the ArangoDB service, copy in an arangod.conf file with your required configuration settings, etc.
It's even possible to generate an SSL certificate and apply it to the ArangoDB instance so that you can have SSL connectivity to the database if required.
Additionally you can utilise the ArangoShell via scripts which allows you to create databases, restore default data from a backup, create ArangoDB users, assign rights.
It sounds like you need to get more comfortable with ArangoDB as a product, and then start to mess around with installing, uninstalling, configuring, and backing up/restoring databases.
I've also evaluated ArangoDB versus OrientDB, and I picked ArangoDB because it runs faster, has many more updates, and their driver packs are well written.
When it comes to embedded databases, you really need a multi-model database, and being able to store standard documents as well as graph data in one database engine, is invaluable.
Additionally, have a really good look at the Foxx MicroService architecture of ArangoDB. It allows you to host business logic behind REST API's and Job Queues running right in the ArangoDB database. This means your application doesn't even need raw table access to the database, rather it can access your data via a REST API and your internal schema is hidden from users, and your business logic stops them doing silly things and wrecking the database.
By having a REST API data layer between your application and the database, it gives you more flexibility on how people consume your data, giving you more options about opening it up in a safe way, knowing your application logic will keep your data safe.
If you chose to use Foxx, there is a cool new tool ArangoDB has released called foxx-cli which lets you script the installation and configuration of Foxx MicroServices in your database. This is a super powerful tool as it's possible to fully install and configure an ArangoDB server, database, and internal settings via installation scripts.
Take time to learn ArangoDB, as with all skills it takes time to really get to know it. I'm still learning something every day and I've only been using it for 2 years :)
If you're using NodeJS (which I have to assume as you don't mention what programming language you're using) as your platform you can use Electron (https://electron.atom.io) and use the ArangoJS (http://npmjs.com/package/arangojs) Driver, if an ORM is necessary I'd recommend using (http://npmjs.com/package/caminte) which has built-in support for ArangoDB, although the documentation being to a poor standard, it should be suffice with some programming knowledge.
OFT: Electron lets you create cross platform Desktop applications in pure HTML, JS and CSS. You can also use Cordova if you're targeting the mobile platform.
You could also use Foxx to perform some of your application logic (this is down to your personal preference) or also create an API platform (with for example Restify).
Most of database systems are written in C++ but that does not mean can only access them via C++, additional drivers are provided for the popular languages. If you use a specific language then update the question so we can help further.
You might also want to read this: https://www.arangodb.com/2018/02/nosql-performance-benchmark-2018-mongodb-postgresql-orientdb-neo4j-arangodb/ as to why ArangoDB would be a better choice for you.
Edit
Due to my limited experience in C++ I can only provide some references which I've saved earlier, but I'm sure they'll be of use to you.
For C++ the driver you should be using is:
https://www.arangodb.com/2017/11/introduction-fuerte-arangodb-c-plus-plus-driver/
An example of the usage of the driver:
https://www.arangodb.com/wp-content/uploads/2017/10/C-Example-Source-Code-File.cc
A simple example / tutorial on how to use graphing in ArangoDB:
https://docs.arangodb.com/3.2/Manual/Graphs/
A free course by Arango on Graphing:
https://www.arangodb.com/arangodb-graph-course/
Hope they help!
I'm currently porting an Android app to codename one. For the new app it is a requirement to work on iOS, Android and Windows Phone. In the description of the default codename one Database class it says that Windows Phone is not supported and should only used for "very large data handling". Instead the more portable Storage class should be used for small storage.
The native App currently uses several SQLite tables with rather difficult queries. I wouldn't call the amount of data very large, but definitely more than "small".
In The Road Ahead post it said that you will work on better Windows Phone support and also that something better for database storage is needed. Is there anything new planned for this or do I have no other choice than porting it somehow to Storage?
As part of the Windows VM rewrite we will need some form of database whether it will be the builtin sqlite or some other solution for SQL. Unfortunately we are still not at that stage in terms of the implementation so its pretty hard to tell when this will launch.
So generally there should be an SQL solution for Windows coming at some point but it's really hard to tell when that point in time will be. Ideally we want it ASAP but there are physical time/resource constraints involved.
I have a database that I need to distribute to users (it's a directory of contact details) probably on CDs.
Users have varying platforms (OS and device wise - I'm willing to target desktops hence CDs).
I was thinking of some kind of deployable webapp that would provide a nice interface and a sqlite database. Does some kind of db interface exist with a highly customisable ui? Or does someone have a better way of doing this?
How big is the database? One simplistic option would be to generate a "contacts" webpage and burn this to the CD. Users can then search this from their browser or perhaps you could do it for them using javascript.
If you really need a DB then you're looking at an embedded database of some sort, however, since you've suggested sqlite I suspect you know this already and are looking at user interface options.
You have not specified a technology, so I'll just list several frameworks designed to develop database backed webapps:
Grails (Groovy/Java)
Rails (Ruby)
Django (Python)
All the above operate in a development mode that uses an embedded database (H2 or Sqlite). Your only challenge will be to ensure their runtime environments are properly configured, or shipped on the CD as well.
In conclusion, I pretty certain this has been done before. Have you also considered just shipping an installer for your webapp, rather than worry about the complexities of getting something to run from CD? For example you might wish to support more than one platform: Linux, Windows, Mac, etc.
Update
Someone has thought of doing this:
http://www.benjysbrain.com/misc/cdsite/
I'm looking to create software for Mac which is the front-end for a locally-created database.
What's the best way for me to do this in Cocoa?
Some more information:
The database will start simple, but eventually be fairly complex (I have 2-300 tables in my projected schema).
I want to save the database as a file (or bundle), so that from the user's perspective it's just a document.
I'm really just starting out with Cocoa, should I'd like to use a method that has a decent learning curve (so probably something built-into cocoa)
Potentially this would have to be distributed through the mac app store (sigh)
Thanks for any advice.
Core Data is an option, but it's not without trade offs. It's more or less a single-user solution. You can write multi-user apps with it, but unlike (say) Oracle or PostgreSQL, which are client-server from the start, you'd have to write your own server app that would marshal the client requests. It also (intentionally, by design) makes it difficult to gain direct SQL access to the underlying data store.
On the other hand, the learning curve is easy, and it's part of Cocoa and well-integrated into the standard document-based architecture.
Our company has a point of sale system with many extras, such as ordering and receiving functionality, sales and order history etc. Our main issue is that the system was not designed properly from the ground up, so it takes too long to make fixes and handle requests from our customers. Also, the current technology we are using (Progress database, Progress 4GL for the language) incurs quite a bit of licensing expenses on our customers due to mutli-user license fees for database connections etc.
After a lot of discussion it is looking like we will probably start over from scratch (while maintaining the current product at least for the time being). We are looking for a couple of things:
Create the system with a nice GUI front end (it is currently CHUI and the application was not built in a way that allows us to redesign the front end... no layering or separation of business logic and gui...shudder).
Create the system with the ability to modularize different functionality so the product doesn't have to include all features. This would keep the cost down for our current customers that want basic functionality and a lower price tag. The bells and whistles would be available for those that would want them.
Use proper design patterns to make the product easy to add or change any part at any time (i.e. change the database or change the front end without needing to rewrite the application or most of it). This is a problem today because the Progress 4GL code is directly compiled against the database. Small changes in the database requires lots of code recompiling.
Our new system will be Linux based, with a possibility of a client application providing functionality from one or more windows boxes.
So what I'm looking for is any suggestions on which database and/or framework or programming language(s) someone might recommend for this sort of product. Anyone that has experience in this field might be able to point us in the right direction or even have some ideas of what to avoid. We have considered .NET and SQL Express (we don't need an enterprise level DB), but that would limit us to windows (as far as I know anyway). I have heard of Mono for writing .NET code in a Linux environment, but I don't know much about it yet. We've also considered a Java and MySql based implementation.
To summarize we are looking to do the following:
Keep licensing costs down on the technology we will use to develop the product (Oracle, yikes! MySQL, nice.)
Deliver a solution that is easily maintainable and supportable.
A solution that has a component capable of running on "old" hardware through a CHUI front end. (some of our customers have 40+ terminals which would be a ton of cash in order to convert over to a PC).
Suggestions would be appreciated.
Thanks
[UPDATE]
I should note that we are currently performing a total cost analysis. This question is intended to give us a couple of "educated" options to look into to include in or analysis. Anyone who could share experiences/suggestions about client/server setups would be appreciated (not just those who have experience with point of sale systems... that would just be a bonus).
[UPDATE]
For anyone who is interested, we ended up going with Microsoft Dynamics NAV, LS Retail (a plugin for the point of sale and various other things) and then did some (and are currently working on) customization work on top of that. This setup gave us the added benefit of having a fully integrated g/l system, which our current system lacked.
Java for language (or Scala if you want to be "bleeding edge", depending on how you plan to support it and what your developers are like it might be better, but also worse)
H2 for database
Swing for GUI
Reason: Free, portable and pretty standard.
Update: Missed the part where the system should be a client-server setup. My assumption was that the database and client should run on the same machine.
I suggest you first research your constraints a bit more - you made a passing reference to a client using a particular type of terminal - this may limit your options, unless the client agrees to upgrade.
You need to do a lot more legwork on this. It's great to get opinions from web forums, but we can't possibly know your environment as well as you do.
My broad strokes advice would be to aim for technology that is widely used. This way, expertise on the platform is cheaper than "niche" technologies, and it will be easier to get help if you hit a brick wall. Of course, following this advice may not be possible if you have non-negotiable technology already in place at customers.
My second suggestion would be to complete a full project plan, with detailed specs and proper cost estimates, before going with the "rewrite from scratch" option. Right now, you're saying that it would be cheaper to rewrite the system than maintain it, and you don't really know how much it would cost to re-write.
I suggest you use browser for the UI.
Organize your application as a web application.
There are tons of options for the back-end. You can use Java + MySQL. Java backend will save you from windows/linux debate as it will run on both platforms. You won't have any licensing cost for both Java and MySQL. (Edit: Definitely there are a lot of others languages that have run-times for both linux & windows including PHP, Ruby, Python etc)
If you go this route, you may also want to consider Google Web Toolkit (GWT) for creating the browser based front-end in a modular fashion.
One word of caution though. Browsers can be pesky when it comes to memory management. In our experience, this was the most significant challenge in doing browser based POS You may want to checkout Adobe Flex that runs in browser but might be more civil in its memory management.
What is CHUI? Character-UI, as in VT terminals? Or even 3270 style?
It sounds like you need a 3-tier system - the database backend, a middle-layer that runs the bulk of the back-end business processes, and a front-end layer for the CHUI / GUI / data-gateway.
All three layers can reside on one machine; or you can distribute the tiers out to various servers. The front-end layer would control the actual terminals, whether they are VT-terminals, or a web-browser, or a custom-written 'client' application.
Make sure you have considered the hardware needs here -- are you going to have barcode scanners, cash drawers, POS debit/credit terminals, et cetra? If you are using a standard browser, it might be hard to reliably integrate those items. (At the very least, you're likely going to have to write special applets to handle them.)
Finally, consider the possibility of a thin-client technology on Windows. It greatly simplifies system management, since you only have to upgrade the software centrally. Thin-client PC's are cheap -- sub $200.
Golden Code Development (see www.goldencode.com) has a technology that does automated conversion of Progress 4GL (the schema and code... the entire application) to a Java application with a relational database backend (e.g. PostgreSQL). They currently support a very complete CHUI environment and they do refactor the code. For example, the conversion separates the UI, the data model and the business logic into separate Java classes. The entire result is a drop-in replacement that is compatible with the original (users don't need retraining, processes don't need to be modified, the data is migrated too). This is possible because they provide an application server and a set of runtime classes that provide that compatibility. The result of the automated conversion is not something that needs further editing before you can compile and run it. True terminal support is included so hardware terminals still work (it requires a small JNI library to access NCURSES from Java). All the rest of the code in the runtime is pure Java. No Progress Software Corp technology is used in the resulting system and it runs on Linux.
At least one converted system is already in production, running a 24 by 7 mission critical environment. It is a converted ERP system that their mid-sized pilot customer uses to run their entire business.