I am creating an iPhone application I need
tableview with rows and column
and fetch the rows and column data from mysql database
Please help me out. Thanks
First of all if you target iOS 6 or later then you should use UICollectionView for this purpose. It looks like a simple grid and much easier to manage than UITableView with 'rows and columns'.
Answering your second question then you might look into Core Data, simplifying definition - its entity based database engine built on SQL(in most cases).
There is complete tutorial how to combine em.
Hope it helps.
As standard iOS doesn't support tables with columns although (as #Mehdzor says) UICollectionView sort of does this.
To be honest if you can't make UITableView fit your needs then you are probably going to have to either design your own table or use a third party framework. Apple have done this when they developed Numbers for iOS but you have to be careful when you are working with small screens.
For your second question CoreData is brilliant. I use it myself for several projects and it is really easy to use. It really comes into its own when you get to synchronising devices via iCloud (a really, really, really difficult thing to do from scratch).
The only downside to CoreData is that it is controlled entirely by the Apple framework. As such you cannot easily port your app onto other systems. Other alternatives are things like Parse, or (if cloud synchronisation isn't necessary) you can control your own databases using the sqlite3 library. Although sqlite3 for Apple is written in C, it's not bad to use once you get your head round it.
EDIT: If your mySQL database is on a server then you could just use web services to query your database and let the server side logic do the actual work.
Related
So i'm following the ios tutorial here
http://developer.apple.com/library/ios/documentation/iPhone/Conceptual/SecondiOSAppTutorial/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011318-CH1-SW1
The data for the tableview is a custom class containing just strings and dates.
Here is what it looks like
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/SecondiOSAppTutorial/DesigningDataModel/DesigningDataModel.html
Can anyone suggest how to save this to data between launches of the app?
What about making the app Document based .. i.e. using UIDocument?
You could use NSCoding to store such simple data. You could probably even use NSUserDefaults but I wouldn't recommend it. Core Data is really the way to go unless you know you'll never need anything slightly more complex.
Check out this guide on how to persist simple data using NSCoding from www.raywenderlich.com - a really good tutorial site for people beginning iOS development.
You could use NSCoding or NSUserDefaults.
But for any real application that has a lot more than sample data you'll be looking at something like Core Data eventually.
From your comments I see that you think it's overkill for just a couple of fields. However, this is an ideal time to learn about and practice setting up a Core Data model and connecting it to a table view with a Fetched results controller.
I would like to know what I have to think about in order to download an SQL DB into core data? I am not sure what frameworks I would have to use or if there are any particular requirements when formatting the SQL DB.
Any help, suggestions, links to tutorials would be hugely appreciated.. I have done some searching around and its just hard to make sense of things because I am not sure if what I am looking for is even correct.
Im not sure if I understand what you are after, but maybe 2 links would be helpful:
an application that lets you load you data to a Sqlite DB from a lots of formats (Excel, xml, ...) is Navicat. It's an easy way of getting data to the DB. As David H mentioned, you could then work with the data without using Core Data via an Sqlite wrapper like FMDB. Then you can access the data with SQL commands.
A totally different tutorial is offered by nsscreencst.com: Importing into Core Data is a tutorial that shows how you can import JSON data to Core Data from a web API. This might be related to your use case. Unfortunately the videos there cost $9/month, but IMHO they are doing a terrific job.
(I'm not affiliated with either of the above companies)
This is just not possible - even though Core Data can use SQLite for storage there is no import/export. You really have two options:
1) If you have one database you want to use Core Data with within an iOS app, then you can write a really simple Mac App that interacts with your SQL store, and essentially replicates it in Core Data using a Core Data Schema you create based on your SQL database. The advantage of this is that is simpler to test and develop using a mac app. The final Core Data repository can then be used by your iOS app (by including the Core Data Schema with it).
2) Do all the import in your iOS app. This may take longer to develop but you can then dynamically download the SQL database into the phone and use SQLite to read it.
To import your data you have to create NSManagedObjects objects from every single record in your SQLite database. Depending on the complexity of your database model this can be very tricky.
There is a good introduction by Marcus Zarra on how to create NSManagedObjects from JSON: https://stackoverflow.com/a/2363996/480069. This should give you an idea on how to start. As Marcus said be aware of the relationships in your object graph so you don't end up in a loop when having complex relationships.
There are also a lot of good tutorials out there how to serialize NSManagedObjects, so just give Google a try: NSManagedObject serialize.
everyone. I've been experimenting with Cocoa and Objective-C programming on the Mac for a few months now, and I am wanting to start developing applications that manage large amounts of data. The trouble is, I'm not really sure where to start with databases.
I have a good background in Java programming with SQLite. I've read a bit about CoreData and I haven't been able to find any good resources for just manually connecting to the database. I'm looking for recommendations.
Should I try CoreData, and if so, can anyone recommend a good tutorial for someone new to the language? Or, should I try to manually connect and query an SQLite database somehow?
Check out the supremely awesome FMDB. It's an Objective-C wrapper around the C SQLite API and makes it really really easy to deal with SQLite databases in Cocoa.
Oh, and it comes with some documentation and the sample code is pretty easy to understand and is decently commented. Chances are that 99% of anything you'd want to do with a SQLite database are demonstrated in the example.
In my opinion, if you use anything else to access a SQLite database (that's not a CoreData store), you're doing it wrong.
Apple has several Core Data tutorials like this: http://developer.apple.com/cocoa/coredatatutorial/index.html
If you want to use sqlite, just use the sqlite C API:
http://www2.sqlite.org/cintro.html
For easy connection to sqlite you must use the next guide!
Little class for connection and consulte BD Sqlite
I do a few modify to add NSNull if the select no give items and fix a bug:
enter link description here
with 4 lines and this class in objetive c you can do all consult easy.
I am looking for an overview of data synchronization techniques available on the iPhone platform. We need the ability to be able to sync a subset of content from a server to a local database residing on the iPhone.
On other projects I have worked on, the data synchronization was handled by the database. Is that available in SQLite? If not, any suggestions on techniques? Rolling our own would not be my first choice.
Thanks in advance.
Unfortunately I don't think there's currently a tool/feature that does this. A similar question was posted, which links to an article how someone rolled their own.
In essence, you could create a "pending" queue table that kept track of the record id's that needed to be updated. When the app needed to synch, as long as you had a way to identify the local record with the server record it could synch it that way. And of course the opposite way from the server down.
iPhone SQLite DB and Web-based DB synchronization and interaction recommendations
There is one framework that could help you if you are using Core Data.
You shall have a look at ZSync. An overview is available here:
http://ideveloper.tv/freevideo/details?index=17089146
If you are using SQLite I strongly suggest that you consider switching to Core Data. You will certainly gain some performances and the integration of undo/redo.
You'll have to remove a whole bunch of custom code anyway... :)
Assume Hibernate for the ORM.
I'm not sure how to ask this. I want to build an application that can replace part of another. For example, say I have an application with various modules, called the "big" app. This application may handle HR, financial, purchases, skill sets, etc. But maybe, for whatever reason, I don't like the skill set module, but I like the rest of the application. I want to build an app that uses the same database that the rest of the "big" app uses but use my software as the front end for that piece.
I could build my app and have it hit the database directly with no ORM. My question is is there an advantage to using an ORM here. I'm thinking there is because if the "big" app goes away and another app is purchased, we could continue to use my version of skill set because I am using hibernate instead of hitting things directly. I'm still learning but I thought that my application used objects that I named and that in the case I just described I'd have to change my mapping files only or/and my code very little.
Here is another example. I have a legacy application and legacy database. It uses database X. I decide that I no longer like the old terminal emulator application that is used to get the data and that I want a graphical version. I can use hibernate with my application and when I finally decide to get rid of the legacy database and change to the latest Oracle or SQL Server, I can do so with minimal headache? Or is my database going to change so much that it wouldn't have matter anyway (I'm suggesting that upon changing to a new database more information will want to be captured)?
I was hoping for comments, if I am misunderstanding why hibernate/ORM might or might not be a benefit.
Thank you.
I do not think you will have a huge benefit frmo hibernate if the database schema changes to something completely different, you might have to change more than just your mapping - especially if more "structure" is added to the database (tables, column and such schema things). That said, if the database was structured mostly the same way, but lets say just the column names and tables names changes and a couple of tables are merged or something like that - you can get by with just changing your mapping.
But I would really recommend using hbernate for database agnosticity, that's is a pretty easy path.
AND then just because it doesn't exactly helps you if your entire database is changed, it such an incredible amount of other forces, that I would choose that over direct DB access most of the time.
Lastly you could think about using a service-layer such as the repository pattern that abstracs away the data access, so the business of your appilcation wouldn't need to change if the database changes.
Switching from one DBMS to another (ala Oracle to SQL Server) is one thing that using an ORM would certainly make much easier.
As for switching from one "big app" to another "big app", I doubt if using an ORM would help that much. It's likely that the database structure and business logic would be different enough that you would find yourself rewriting lots of code anyways.
You can generate domain objects with Hibernate Tools, if you do that than it will be painless and fast. however if you write all the objects by hand you will die. i think its good idea to rewrite part of the app and get to know hibernate better.
I think it's generally a bad idea to make any decision based on the
unknowns versus the knowns. Whether you're deciding on a data
access/persistence strategy, what car to buy, or what college to go
to, you should put the most weight on the things you know you want
today, rather than worrying about what may or may not happen tomorrow.
So when considering ORMs, I wouldn't worry too much about things such as apps
"going away" or DBMSs changing (unless that's either already been talked about, or
there's a history of this in your company). I'm not saying that these aren't things that will never happen, but rather that they should take a back seat to the generally much more important considerations of maintainability, performance, and developer productivity.
So in short, choose an ORM based on its ability to solve the problems and satisfy the requirements that you have today.