I am building an iPhone app that contains medical information for medical professionals.
The data has a sort of taxonomy which is easily represented in the form of e.g. a mind map on a piece of paper. On the device, the idea is to navigate through a series of items in table views to get to a detail view with text and picture information. The no of child views/nodes varies from 1-4, and the number of items on each table view varies from 2 to 20. The detail items/views are about 120 in total.
Now, I have reasonably strong Obc-C/Cocoa skills (mostly mac), but have about zero experience from working with actual databases. So far, I have hard coded the information in nested NSArray/NSDictionary structures (much the way Apple demonstrates in its table view tutorial). This has obvious disadvantages, and I am considering swithcing to use some sort of database instead.
How would you, experienced iPhone programmers, solve a problem like this? SQLite database? Base app on Core Data?
Thankful for all sorts of help and suggestions.
-Gregor, Sweden
edit: implemented navigation/table view hierarchy with plist. Works like a charm. Will look into core data, if not for this project then for another with larger amounts of data.
I've created an app with an SQLite3 backend that worked out quite well. Performance was good.
If I were to start a new project from scratch, I'd definitely look at Core Data, as long as it's okay the project only runs on 3.0+ devices, as Core Data is a new feature in 3.0.
Ask your client if it's a big deal that the app not support 2.2.1 (last I looked at AdMob, that's still about 25% of iPhone users and 50% of iPod Touch users). If it is a big deal, then your answer is forced upon you.
Core Data in the iPhone 3.0 SDK. Adoption rates of the 3.0 SDK are huge! It's a software upgrade, free on iPhone. Hardware updates of Open GL ES 2.0 are more costly, people are slower to adopt the new hardware. But research online shows adoption of 3.0 is high.
Improved performance, uses SQL Lite underneath, and it's cross platform to Mac OSX. Lots of how to's out there for it as well.
// :)
CoreData on the iPhone makes this trivial, have a look at the Introduction Tutorial, then take a look at some of the other examples (there's complete versions of the tutorial app and the extended versions in the Dev Centre).
Look into RDF and OWL, you might find some C libs to handle data in those formats, which I think is more adequate than trying to fit graphs into a relational database.
Related
I am an iPhone developer and know that framework well. With the Mac App store on the verge, I'l like to learn more about Mac development. Are there any good guides/tutorial/etc. to help with the transition? I have looked around and not found much. Thanks for the help!
You basically need to learn the difference between UIKit and AppKit. (Foundation and Core Foundation are the same on both platforms.) They are subtly different; there are more frameworks which comes with the OS X than with the iOS; a framework with the same name might have more functionality on OS X, etc.
But that's basically it, if you distribute the app through the Mac App Store, because you don't have to learn how to package things by yourself.
The best book on Cocoa programming for Mac is this, but it might be too elementary for an experienced iOS programmer. But it's still a good book.
I guess we'll see a flood of books for people like you, showing the way of Mac development to competent iPhone programmers; but it hasn't happened yet. Maybe you might write one, from your own experience :)
Going the other way, I found that the skills that transfer are really just the low level stuff like Objective-C, Foundation and Core Foundation and the tools are the same.
Also a lot of the low level concepts are the same. There are still targets and action, IBOutlets and IBActions. However on a higher level things are very different. There is, for instance, a table view but you tend to use it in a different way and only when an actual table is required rather than as a framework for a whole GUI idiom. Also, table views have more than one column.
There are many advantages, for example you have much more freedom in how your UI will look. And you use garbage collection. With GC everything you've learned about Cocoa memory management becomes instantly redundant. It's very liberating.
What kind of practices do you do when developing iPhone apps? For instance, do you write up a technical design document of any sort. Do you write down the design of your app at all? Do you implement a certain methodology agile/scrum/waterfall etc...? I'm just curious when working on projects like an iPhone app, what kind of best practices do people use or do people just go at it?
I've worked on a few iPhone apps, and I've found this workflow works pretty well:
Figure out what the app is going to do. Create a one sentence description of the app that embodies what you're trying to do. If you can't explain the core functionality in one sentence, people won't get it!
Create interface mockups for each screen of the app on paper, and then in Adobe Fireworks. Fireworks' native file format is PNG, so it's easy to create images for use in the actual app later.
Figure out how you're going to architect your app using Model-View-Controller and the other iPhone app design patterns (delegates, dataSources, etc...). Don't try to do something other than MVC. The whole SDK is built around MVC!
Start coding! I usually start with the bare functionality first. For a drawing app, I implement the drawing controller and the important drawing views (color picker, etc..) first. I back things up to an offsite SVN repository as I go using Versions (I haven't had much luck with the repository support in Xcode)
Distribute a beta version of the app to a group of AdHoc testers. This helps a lot. Getting the app in the hands of a few extra people really helps isolate usability issues and bugs that are hard for a single developer to find.
Repeat until satisfied and Apple approves :-)
I haven't done much with iPhone development, but its irrelevant. I wouldn't consider it any different from any other developmental process.
The process is different for each case, some have at it and others follow their development methodologies.
As one who is about to dabble in his first iPhone app, I don't think there is any one methodology that rules over any other. You can apply any of the techniques you mention to an iPhone app, just like any other development effort.
A key thing about iPhone apps, or any Apple related development effort, is that Apple sort of forces you to follow certain design guidelines. That is good in some ways (less to concern yourself with) and bad in others (restrictive).
Also, Objective-C and Cocoa Touch can also lend itself to certain ways of programming.
Now, specifically for me, as a sole developer, I will probably:
Jot down high level features of what I want to be included in the first version
Do an interface mockup (either on paper or with a software tool)
Jot down some key objects and functions (psuedo-code)
Set up a source control mechanism (I think this is key)
Start going at it
Possible repeat of any or all of 1-3 :-)
I prefer to start with small proof-of-principle projects to test out different capabilities of the device that I need for my final product. This is especially important on a mobile device like the iPhone, because hardware limits on memory, processing power, graphics, or display size can render some ideas impractical. It's best to know that your application won't work as you imagined after only a couple of days of playing around, rather than after a month of development.
John Geleynse and others at Apple advocate starting your design with a single sentence that describes your product and its intended audience, and building everything around that mission statement. I've found that this works extremely well for determining what features to incorporate or leave out of a product, particularly on the iPhone. Having a simple core product description at the center of your design is also extremely helpful when you need to explain this product to others in your later marketing efforts.
Aside from that, I've found that iterative development incorporating lots of testing and user feedback has worked for me on every platform I've developed for.
I need help clearing up some questions regarding these several third party dev-support frameworks (e.g. ViXML, Titanium Mobile) which promise iPhone app development at lightning speed using only Javascript and XML, without knowledge of Objective-C.
Questions
Are there any features possible on a regular Xcode development platform that are NOT possible for someone creating an app using these frameworks?
Is there any real savings in money and time when working with these platforms?
The approach to simplify development like this has been tried time and again, on many different platforms.
You always have the problem that the development framework will lack some features the "real" system has, and while sometimes a passthrough mechanism is offered it is invariably clunky.
Sometimes they do offer speed gains, but the degree to which they benefit you depends on the domain you are in - Unity is a great example of a framework that obviously saves people a ton of time developing games.
I personally think, that outside of gaming I don't think the benefit of using a third party framework to be really worthwhile. All of the best apps are ones that leverage the system to the fullest in terms of animation or UI abilities, meaning that someone spending some time crafting will be able to make a nicer looking app than someone who has to rely on the abilities of a framework.
The other problem you can run into is that no matter how popular a third party framework is, you are always going to have lots more support for the official platform - like the number of books around today on Objective-C and iPhone development, or even the very active Objective-C support on this very site.
The only exception would be if you had to have a cross-platform app and the app supported development for all the platforms you need. But even then I would argue for making the iPhone app distinct and take fullest advantage of the platform, or your app will languish and other competitors will overcome you.
Q1) Yea, performance. Javascript is slow on the iPhone, because the processor is slow. It's just a cold hard truth. Heck, loading NIBs vs using hand coded views is slow, because of the processing and loading involved, and that's simple compared to Javascript. Javascript is wonderful, but partly because we have really fast processors today. The iPhone (nor the Pre for that matter) have particularly fast processors, and Javascript's performance suffers because of it.
I have not used the frameworks, so can not comment on their productivity claims.
For question 1: non-native apps may not be able to access GPS information or other hardware on the phone.
I'm an undergraduate university student who also writes iPhone applications. Next year I'm expected to do a final project, something that lasts the full year and involves a fair bit of software engineering.
My original plan was to write an object-relational wrapper around SQLite for the iPhone (or rather, to massively clean up and extend one I already have) and ultimately release it as open source. Unfortunately, with Core Data being added to iPhone OS 3.0, that's no longer really necessary. (At least, that's how it seems to me; any opinions on this?)
However, I'd still like to do a useful, technically interesting iPhone-related project next year. So here's my question: what do developers need? What sort of problems do you encounter in your apps which seem like they could be handled by some sort of library or framework? My focus is generally more on utility, productivity, and communication apps than games. And since I'm proposing this to a university, something that's either theoretically interesting or attractive to potential students would be preferred. And of course, it'll need to be something that they haven't added to the new version of iPhone OS.
It's in the early stages, but a bunch of scientifically-minded Cocoa developers (headed by Drew McCormack) have joined together to start a BSD-licensed data charting / plotting / visualization framework called Core Plot (mailing list here). This framework is cross-platform between Mac and iPhone, relying on Core Animation for rendering.
While you wouldn't be starting your own project fresh, contributing to this open source framework would be technically challenging and I believe that the framework will have far-reaching applications. I'm sure that the university would be impressed by the potential scientific and educational uses of such a framework.
A library that provides a very simple API that would enable any app to act as an OAuth consumer would be incredible! It could be used to enable data access against hundreds of OAuth-enabled data APIs all over the web, including those of Google, MySpace, Twitter, Yahoo, Flickr, etc. Imagine how many thousands of additional applications you could enable other developers to build with ease.
Your code could be included in pretty much every worthwhile iPhone app that any future developer writes!
I'd like to see a framework that abstracts the interface to various social networking sites. Having a standard API to send updates and post pictures to MySpace, Facebook, Flickr, Picassa, Blogger, Twitter, and other services would be very useful.
A general purpose framework to communicate with a particular iphone from any application with internet connectivity. iphone apps are great, but so much more can be delivered with serivces from the web - so some sort of communications would be nice.
Make some sort of API that can be used to talk to iphone from other connected applications - either web services or desktop, etc.
I ended up having to go in a different direction due to the rules of the project, but I'll keep these in mind as possibilities for future, non-university work. Thanks, everyone!
I want to implement Core Data into my iPhone app. So what is the best way to learn Core Data specifically for the iPhone? I have 4ish hours that i can devote to this today, so ideally I would be competent enough to add this (however slightly) into my app.
The only way i retain data now is through NSUserDefaults, just so that when the app is closed and reopened, their data is still there. I want to give the user the ability to save sets of data, read them, edit them, delete them, etc.
Getting Started with Core Data in the iPhone Dev Center did the trick for me. :-)
No, seriously, it might seem like obvious advice, but that one-page document lays out a nice strategy for which documents and tutorials to read and in which order. Once you work through the first tutorial it recommends, the weird terminology will feel a lot less weird.
If you don't already know about this, this is very useful:
Core Data Tutorial for iPhone OS
Two books that are great references for Core Data are "Core Data: Apple's API for Persisting Data on Mac OS X" by Marcus Zarra and "iPhone SDK Development" by Bill Dudney and Chris Adamson. Both walk you through sample code for handling Core Data on the iPhone, with slightly different perspectives on the framework. The Core Data book provides the best overall reference on the subject that you'll find, outside of Apple's own documentation.
Additionally, if you purchase the iPhone video track from this year's WWDC, the presentations "Introduction to Core Data on iPhone" and "What's New in Core Data" are great resources. ADC Select members also have access to Core Data presentations from older WWDCs, including ones that explain the fundamental concepts of the framework and how to tune the performance of your Core Data application.
Make sure you don't stop after the first document - Core Data Turorial for iPhone OS is excellent but then I tried to change the model and everything crashed with fairly cryptic error messages. Getting Started with Core Data is the next place to go. Unless you read the sections on versioning the data model you will probably run into big problems as soon as you start to adapt the example code for your own use.