iOS iOS & Databases

[Futhark]

I'm going to start a project for logging hours worked on my iPad, The sign in/out times will need to be kept so they can be looked up at any time via some sort of search feature, also the times will need to be editable possibly with an admin backend feature if an error was made logging the times originally. I want it to allow new staff to be added as and when needed and it will password protect each employee, I've never worked with connecting a database in an app before and hoped someone could give me a few tips or suggestions on how i should go about this?

Many Thanks

 

[dejo]

Are you talking about a remote database, hosted on a server somewhere, or a database that is "cooked into" the app?

 

[Futhark]

Hi Dejo that's what I'm unsure of? I'd imagine external linking to a MySQL database but as this is all new to me I'll take any advice given

 

[dejo]

How many users / devices will be using this app? If more than one, will each user need to be accessing (and staying in sync) with the same database, or can each device have their own, disconnected database?

 

[Futhark]

105 staff and 1 iPad to start with but would like to eventually get another one so regardless of which iPad is used it will allow to enter data or search data. So this sounds like server side right? Is this easy to do?

 

[dejo]

105 staff and 1 iPad to start with but would like to eventually get another one so regardless of which iPad is used it will allow to enter data or search data. So this sounds like server side right? Is this easy to do?

Yes, that sounds like a remote database will be needed. Beyond the most simple implementation, to me, no database integration is "easy" to do.

I suggest you will need to set up your DB on a server and then create some web-services to access that DB remotely (don't forget to secure those). Then you will need to implement code in your app to consume those services. You need to consider if your app can run offline (and then resync when it goes back online) or if you want to require the remote-DB to be accessible at any point. This will influence whether you need some kind of app-side local-database-"mirror" or not. Oh, and I'm sure I'm probably missing a bunch of other things to consider. Hopefully, other members can chime in with their thoughts.

P.S. What experience do you have with database engines? Is MySQL the extent of your knowledge?

 

[Futhark]

You've raised a lot of very good points there and something I'm going to have to sit down and consider.

I've 2 database driven apps at present but the iOS device is only reading from the database and not actually adding or editing data or allowing searches so this is all new ground for me.

My database knowledge is very limited to be honest and yes I've only worked with MySQL so far.

 

[ArtOfWarfare]

If your database is going to be small enough and not have a lot of people writing to it concurrently, you may find just throwing a database on Dropbox is adequate. It probably violates their TOS, but oh well.

 

[Futhark]

Wow I've just looked up the Dropbox option. I didn't know this existed. I'll have a go at that I think and see how I get on.

 

[MattInOz]

Been looking at Dropbox datastore API for a project as well. There is also ParcelKit open source project as well which wraps that API to work as a backing store for core data which might be of interest to you.

There seems to be few of the of Cloud Stores that now have database API's that work with iOS now. Although if your only talking 2 even 3 dedicated devices and only one to start with then why not bog standard core data to start with, then work out the best way to handle multiple devices later.

 

[ChrisA]

105 staff and 1 iPad to start with but would like to eventually get another one so regardless of which iPad is used it will allow to enter data or search data. So this sounds like server side right? Is this easy to do?

Time keeping. You have some SERIOUS legal requirements to consider.

Don't modify a DBMS in real time. What you are going to have to do is keep a LOG FILE the maintains a list of all the sign-in sign-out events and keeps some kind of PROOF that it was the employee who did it and also some kind of proof that the log file is not tampered with. You can use checksums to show non tempering and as for proof of the right person the web cam seems like an ideal solution.

If some one disputes their pay you are going to have to prove your case.

A SQL DBS is a dynamic thing. Even a table holding "events" with times is not a log file. Because at any time records of events can be inverted or removed.

I think you want the iPad to be a simple terminal that send events over an encrypted link to a sever machine. You could have any number of iPads.

Have the iPad(s) send the event (and wait for a reply) but also keep a log locally. If you use a DMBS at all that is all on the server side.

Be sure to keep a mirror of the data and logs in real time off site

It's hard to believe that you need to write this yourself. Sounds like re-inventing the wheel.

 

[1458279]

It's hard to believe that you need to write this yourself. Sounds like re-inventing the wheel.

Just wondering if you have a more "ready made" solution. I'm considering a project (not time based) like this.

 

[xStep]

If your database is going to be small enough and not have a lot of people writing to it concurrently, you may find just throwing a database on Dropbox is adequate. It probably violates their TOS, but oh well.

I can't see how Dropbox would be appropriate here unless there is going to be one DB per person which is then integrated into a master DB. My understanding of Dropbox and services like it is that it allows transfers of files. This isn't appropriate for a multiuser DB.

 

[ArtOfWarfare]

I can't see how Dropbox would be appropriate here unless there is going to be one DB per person which is then integrated into a master DB. My understanding of Dropbox and services like it is that it allows transfers of files. This isn't appropriate for a multiuser DB.

As I said, if users aren't going to be writing to it concurrently, it should be adequate. The main reason I suggested it is it costs nothing and is very easy to set up. Google Drive would be another possibility, although Google halfasses everything they do so I'd be surprised if their APIs are anywhere near as good as Dropbox's.

 

[dejo]

I think where the remote database will be hosted is a more minor factor than some of the other issues that will need to be addressed.

 

[xStep]

As I said, if users aren't going to be writing to it concurrently, it should be adequate. The main reason I suggested it is it costs nothing and is very easy to set up. Google Drive would be another possibility, although Google halfasses everything they do so I'd be surprised if their APIs are anywhere near as good as Dropbox's.

Well, that isn't exactly what you said; "not have a lot of people writing to it concurrently". The highlight suggests more than one concurrent users. You can't do multi user writes to a file and expect good results.

The real point is for the OP. If multiple users are likely to try to update the DB at the same time, then a proper multi user DB setup is required.

 

[PhoneyDeveloper]

Forget about dropbox.

There are a number of commercial cloud database providers that have REST APIs that can be used from iOS and which can be free for small databases.

Look at parse.com, mongolabs.com, and others.

 

[moonman239]

My suggestion would be to build or find a server-side script that accepts POST requests from authenticated devices. Then create an Objective-C class with methods to send each request out. Do make sure that file is signed with a certificate or has a checksum.

Also, you might consider creating a local file.