I need to create an application capable to modify and manage files on IOS.
With IOS 5 is "easy" to create a Document-Based Application, but I need to support IOS 4 too.
Anyone knows if there is a way to create a Document-Based Applications in IOS 4?
Thanks in advance.
Short answer is no as UIDocument and UIManagedDocument only arrived with iOS 5
Long answer is yes. There are hundreds of document based apps for iOS. e.g Brushes, Sketchbook Pro which are all document based apps. My own app is document based, its not that hard to do.
What UIDocument/UIManagedDocument provides is a canned API for making a generic document. Feed it a URL and it does (most of) the rest of the housekeeping.
If you wish to do an iOS4 based app then stuff you will need to pay attention to is.
UIApplicationWillTerminateNotification/UIApplicationDidEnterBackgroundNotification
Opening a new document.
Saving a document.
Shutting a document.
Autosave (maybe)
Core Data stack , if you're using Core Data
www.raywenderlich.com has some great tutorials. Maybe even iOS4 based ones still.
IMO - Don't bother with iOS4 support. Like above post states 85% use iOS5 and anyone still on iOS4 probably isn't in your target market. Especially as this is (I assume) a new app and iOS6 will be around by the time you go to market.
Just going to ask, do you really need to support iOS 4?
The adoption of iOS is over 85% of devices.
Whats the basis for the need to continue iOS 4 support?
Related
Suppose I want to design a master detail application, Xcode6 master-detail project template for universal app includes UISplitViewController and splitViewController is new in iOS8. I want to support app for iOS7 also.
In general
What is the best way to design an universal app using Xcode6
storyboard that support both iOS8 and iOS7 ?
Is it better to use separate story board for different OS version ?
What are the best practices we should follow to make app compatible with both OS?
The 'best way' to create such an app will likely depend on what exactly your app needs to be able to do. Some ways will be better than others depending on any special behavior needed.
But it is definitely possible to use a single Universal storyboard in Xcode 6 that uses Size Classes and still target iOS 7, both iPhone and iPad, using UISplitViewController. I have successfully done just that. It did take a lot of work to ensure it worked properly and looked consistent on iOS 7 and 8. You have to be a little careful when it comes to performing the various new adaptive segues, as that is a huge difference between iOS 7 and 8. For example, detecting when you have a popover is going to require some work for the two different OSes, handling unwind segues will require some special handling, etc. It will require a lot of testing. Dedicate time to testing the iPhone 6 Plus - in landscape it will show both the master and detail on screen, but you can have control over that.
After going through that experience, I would much rather implement a single storyboard as opposed to two storyboards, one for each OS, and definitely stay away from creating a storyboard for each OS and then one for each device type.
You'll want to read up on the SDK Compatibility Guide to learn how to detect API availability. If you implement an API that doesn't exist on iOS 7 the app will crash, so you need to only run that code if that function exists for the OS the app is running on. For example, you may want to utilize the new UIBlurEffect API, but that doesn't exist on iOS 7. Gain an understanding of what deprecation means, and knowing what has changed in iOS 8 will greatly help. For example, the rotation APIs are deprecated in favor of Size Class trait collections, but those aren't available on iOS 7 so you'll need to continue to use the deprecated rotation API.
Also check out some WWDC videos from this year. They have a couple videos that discuss the new adaptive segues and Universal storyboards. Note that these storyboards ARE backwards compatible with iOS 7, but there are some size classes that aren't made available on iOS 7. See this question and the answer I provided for more information. WWDC videos from previous years also discuss how one can support multiple OSes, progressive enhancement, etc.
And of course when you have questions/problems Stack Overflow is a great resource. A lot of the questions I've posted in the past few months are related to this topic exactly, how to modify UISplitViewController behavior, obtain support for both OSes, using a single storyboard and the new adaptive segues, etc. You may wish to read through those to get an idea of what you can expect to run into when developing an app in the same fashion.
I've just installed ios7 on my iPhone, however I have not yet downloaded xCode5, so I've been producing my archives using iOS6 SDK and using TestFlight to test them on my phone. When running my app on iOS7, I'm noticing a lot of bugs that I didn't see in iOS6 (some that are unpredictable and very difficult to fix). I've been avoiding downloading xCode7 because I'm not yet ready to make the commitment to the new UI elements, but I'm wondering if I did produce my app using the iOS7 SDK, is it possible some of these bugs could be eliminated?
This is a very broad question. iOS 7, despite its advanced beta count, is still very much a work in progress. There are bugs that should be reported to Apple that should not happen. But beyond that, there are changes in the internal API that influence how the app behaves. Apple has done its best to try and preserve SDK 6 apps as much as possible, but there is breaking API which can cause crashes. One example off the top of my head is the class cluster they are now using with ABPersonViewController. Subclassing that in iOS 6 works fine, but in iOS 7, even when compiled with SDK 6, causes a crash in most cases. These issues can be resolved even with Xcode 4.6 and SDK 6.
Compiling with SDK 7 may help you fix some issues, but it will come with a plethora of issues of its own. Depending on how complex your view hierarchy is, you may have to invest a considerable amount of effort to support the new API and functionality. You don't really have a choice, as this is the future, but you should be prepared for this, and arrange your schedule accordingly.
I'm about to make an application for ipad that has the following specifications:
download JSON (or xml) from server
download short audiofiles from server (locations are in the JSON from above)
save these to the iPad for offline use.
based on these files the user gets to do some exercises
user progress/results need to be saved to the device so they can continue where they left off the next time they launch the app.
My question: Can this be done with only html/css/jquery Phonegap? Or should I go native and make this all in Objective-C? Or can I combine phonegap and Objective-C?
Now I'd like to know how I can save a json file on the device for offline use.
Also I'd like to know how to download audio (or images or whatever) and save those to the device.
This can be done with PhoneGap/Cordova and its HTML5 approach.
If it is iPad only, then go native.
Your app's high level requirements do not sound too complicated. For more complex apps always consider that facebook just went native for iOS because of their performance issues. In the end, this may be the way to go for a number of apps. PhoneGap or other HTML5 or cross compiling approaches for 1000+ devices plus native solutions for the market leaders.
It depends on what level UX your are aiming for and how you think your app may expand in the future.
If you need full control over the user experience, then you will need to go native. All the physics involved in scrolling/swiping will be done for you. How much content will you have? if it's thousands of items then again native will offer the best performance. You can also perform certain tasks on background threads (my app did image compression and resizing before uploading the image, for example).
Otherwise - if you just want to get something out quick, go with phonegap.
*I speak as a developer who started out with Phonegap but went Native for performance reasons. Others may have had better experiences.
Comparing application build in native Objective-C with applications build with Webtool like PhoneGap, in terms of being fast, Objective-C apps always win, but in terms of building it fast with zero knowledge of Objective-C Web apps win.
If you have knowledge of Objective-C, in my opinion go with native Objective-C app, else do it with PhoneGap.
BTW, those functionality mentioned in your question can be done with both.
Looking on-line I saw that I can write most of the application in Ansi-C code or as a website and present it in a webView control.
Then besides some general knowledge about iOS and the API... Do I really need to learn Objective C?
You could use something like PhoneGap, which wraps an HTML-based application into a native launcher app. It may not be as powerful as what you can do with a pure native app, but on the other hand, your code will not only run on iOS.
PhoneGap does offer access to some of the phone's API (camera, notifications, accelerometer and so on) that you normally only get in native apps (it exposes them as JavaScript objects), so you can do more than you could in a regular HTML5 webapp, even without learning Objective-C.
Most people overlook the fact the iPhone has an extremely capable web browser. You can create very powerful web apps and therefore avoid having to learn objective C.
Safari on the iPhone has a bunch of great HTML5 features, including local sqlite stoage - so for example you could easily make a todo list app which could sync up with your server when there's a net connection.
You can even add home screen icons etc.. personally I'm astonished people don't write iPhone web apps more!
This is a super useful guide on how to do it:
http://building-iphone-apps.labs.oreilly.com/
You can use C# to write iPhone apps using MonoTouch, but it costs money. Then again, so does developing for the iPhone the normal way.
The other answers are correct in that you /can/ use other languages... you really don't want to. You are never going to create a pleasant to use, standard, and HIG-abiding application without learning Objective-C. Truly, though, there's no reason /not/ to learn something new. It's not particularly difficult (like, say, C++), and Cocoa is a well-designed API.
Somewhat related, I personally refuse to install all the PhoneGap/etc apps in the App Store as I find them of significantly less inherent quality (especially as compared to the rest of the apps on the device), and I would suspect many non-developers would have similar issues with them, if not so specific.
Unless your app is all web, or uses a framework such as PhoneGap you have to have some working knowledge of obj-C. It's actually not that bad. It's C with Smalltalk bolted onto it.
It's generally much simpler than C++.
if u want true native app that can take advantage of the latest features on the latest iOS release, Objective-C is da language you gotta learn.
Objective-C is a very powerful language, and there are a ton of great frameworks - you are doing yourself a HUGE disservice by not learning the language, and your app quality will suffer as a result.
You can write an entire iPhone app in C++ using a framework like libnui.
Just wondering what code I would need to do this?
There's no CoreData for the iPhone (yet), so there's no way to use the same code in your iPhone and Mac app. You could write your own wrapper around sqlite that will run on both. The Omni group has an open source version of this (under a modified MIT license) which would probably be a good starting point.
In addition, there's no built in way to sync data, so you'll have to come up with a way to do that as well. Many apps run a server on the phone/mac and sync via that server. It generally requires that your phone is connected to the same wifi network as the mac.
Core Data does not exist on the iPhone, so you'll need to use something else for the iPhone portion at least. In fact, if you want to share a significant amount of code between the iPhone and Mac apps, you'll probably want to avoid Core Data altogether.