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!
Related
I am working on an app for Android, but would like to have it ported in the future to iPhone and (if it seems to gain significant market share in the future) WP7/8.
I know nothing about any mobile platform other than Android. Should I be using C++ (NDK), Java, or something else to get as much portability as possible? I assume I will have to rewrite (or have someone rewrite) at lest part of it, but I would like to make as much of the codebase as possible portable.
Edit: It is a simple app that "scans" a barcode (camera) or has the number typed in, sends some information to a server, gets back some more info (probably in XML, but could be whatever works best) and displays it in a few simple screens.
Edit 2: The 4 parts I have, and would like to ideally make them portable are:
Scan a barcode (probably the hardest to make portable)
Allow entering a barcode number manually
Send and receive some custom data
Display a few screens (This can be in HTML, if I have an option to make it look "native", not like the browser window displaying a webpage it is)
For a non-trivial app that isn't a game, there are currently no mature solutions to this problem.
Tools like Titanium Mobile and PhoneGap are meant to help you do exactly what you want, but impose limitations on what your app can do and are so far at the cutting edge of development that they often introduce bugs of their own that you won't be able to fix. Additionally, you're at their developer's mercy when it comes to support for alternative platforms like WP7 or Blackberry. In some cases, these might be worth the risk, or you may get lucky, but you need to be wary before rushing to use them.
Often, the best technique is still just to develop independent codesbases. You can model them after each other in architectural terms, and if you do so it isn't typically that hard to translate between different platforms.
Another technique to aid in portability for many apps is to use embedded web browsers where it makes sense. This allows you design some of your views in HTML/CSS/Javascript rather than with native UI tools, and then just load them into the aforementioned embedded web browsers on each platform.
Depends on how many platforms you are aiming for.
I have some experience doing iPhone + Android. Honestly, I wouldn't spend too much time trying to learn a portability tool on top. I have done couple of apps (simple communication stuff + a light weight game) and my experience is so far - assumed you are familiar with both - it is far faster + easier to just write your app and then port it.
Besides the normal coding work, the most difficult tasks are to develop the app structure including the main classes and data structures - this you can copy basically 1 to 1 in terms of structure of course - not code.
Also since you will keep getting updates on different platforms like iOS (Android + Eclipse are a little slower it seems to come up with updates/upgrades), which make life easier all the time, you would most probably have a big disadvantage when relying on someone elses portability development toolkit.
So far - certainly not to be taken as a general rule - while development on iPhone took 100%, porting it on Android took at most 30-40%
This question is way too broad, it depends on what kind of app you're doing.
Generally speaking, if you're just as good off doing a web app, do that. It'll work across different platforms.
MonoTouch / MonoDroid by Xamarin (previously owned by Novell) allow you to write C# (the language used by WP7) for iOS/Android, respectively. It is not free, however.
I don't believe the frameworks go so far as to include cross-platform UI, but I'd say that's probably a good thing. At least your application logic can remain the same across platforms.
I've not used the framework myself, so I cannot vouch for it.
We do use MonoTouch/MonoDroid and it helps us to simultaneously support WM/WP7/Android/iOS. The common denominator of all these platforms (after employing Xamarin products) is .Net.
The policy of our company is to maintain toolkits for all platforms that provide similar UI. Then the apps can be written in a nearly platform-agnostic way. This isn't, however, a general statement as the independency refers to the specific types of applications.
I don't advise using our toolkits for your case as it looks like an overkill. However, investing into C#/.Net might not be a bad idea.
U should definitely go with the easiest route: Java.
You will still have to rework a lot while porting, but if you were using NDK, the overhead for Android itself might be similar.
(In an average app. As you havent provided too much information about the project, the answer couldnt be more specific. If you are developing a performance-critical app, like a 3D game, you should consider NDK for the high porfile program parts).
Edit: for this scanning solution, I would go with Java on android and wont bother with portability. For a project with such a clean application logic it wont worth the effort to make it portable (except if the aim of the project is to experiment with application portability, but as far as I got it, it isnt).
I am working in iPhone SDK.I have to convert from it to Crossplatform which may be either phonegap or titanium.As a iPhone Native application developer, I have some questions based on cross paltform.please consider the questions for other platforms android,etc also.I have already seen the stackoverflow Link.
1)Is it possible to get equal functionalities of all APIs which are in iPhone SDK through HTML5 and javascript?
2)If Apple releases New Version of iPhone SDK,will New APIs be included ASAP in Crossplatform?
3)If The App crashes in some situation, can I fix immediately through Device Debugging as we do in native Language?
4)The applications developed by Cross platform will be approved by Apple legaly?For example If i want to do live streaming in iphone , The restrictions have mentioned in Apple website.has it been followed by crossplatform?
5)will Application developed by cross platform take more memory?I mention the size of device build for appstore?If we develop the same through objective C,will size be reduced?
***My Conclusion is When we want to develop simple Applications for Multiple devices,crossplatform is suitable.Am I right?***I hope doing through native language(iphonensdk, Android) will avoid lot of Unnecessary things.
No.
If the API can be made available, it depends on how fast the creators of the framework implement it.
In principle, yes, as those frameworks employ a limited amount of OS capabilities to run web-technology (in most cases). This "wrapper" behaves as any native app does. For the content however the rules of the frameworks development language apply. It may be harder compared to native development to track down errors, since they must "pass the shell". Html errors for example may produce the same error for their enclosing webview again and again, despite being different in origin.
Propably.
That's hard to tell. It may depend on the framework. I wouldn't worry about the code as other ressources like imagery are usually the heavier load. But it may be very well the case that those frameworks bring along imagery necessary for their UI elements, since they do not rely on OS elements entirely. Compared to a native app which comes with no extra ressources at all, a crossplatform app with the same functionality might take more memory.
As to your conclusion: You're right. However I'd still encourage anyone to develop native applications whenever possible. Crossplatform frameworks tend to be slower at runtime and, in some cases, produce very ugly apps. I know several examples of apps which have been created with a variety of crossplatforms and I don't like any of them. They just don't feel right. Partly that's due to their UI elements which don't look and feel as you'd expect it on the platform you're on.
The principle behind crossplatform frameworks may appear to be logical, tempting and in some cases, straight economics mandate their use. But, for the time being, I find the results far from being satisfactory and for that reason would never touch a crossplatform framework.
In my experience (with a closed, private, expensive x-platform thing purchased by the employer), it was utterly frustrating, and incredibly difficult. Therefore, it is my preference to maintain multiple native apps.
The UI considerations that can be made/handled by the native app, as well as the functionality and speed gained by doing it natively, IMHO, far outweigh the benefit of having to write it 2 or 3 times.
In an ideal world, you would have a specialist for each platform that can lead the team on the "deep" things, and then everyone can generalize for all of the platforms, increasing their depth through the course of the project.
I am working on iPhone app development currently (primarily native app using Obj-C and some web app using jQTouch). My question is regarding the future of this space;
In say 3 years time, what do you think would be preferred (native or web app) ?
What are the strengths going to be for native app (I know for certain types like Games, people prefer native than browser-based, but will that remain that way forever)
Some people say HTML5 will replace native app development, as it will be "code once, run anywhere" kind of thing (like common for iPhone, Android, BB phones). So do you think HTML5 can completely eliminate native app development.
I know the mobile space is constantly changing with new technologies coming up regularly and hence one cannot say with certainty what the situation will be 3 years forward. But I think there are projections being made by many agencies. So are there any reputed ones which can give a general idea or some sense of what might happen in future.
My main aim is what exactly should be my focus (like what technology/platform/native-web apps), if I want to look at the mobile space for the next 5-10 years.
Please provide as many responses as possible.
My 2c.
The popularity of web based apps will continue to grow. Whether it will pass native apps I don't know. For them to be on par in terms of numbers in 3 years doesn't seem unrealistic.
Native apps have the following benefits:
Better performance (potentially)
Fewer restrictions on accessing device resources
Greater control of execution of application
HTML5 won't completely eliminate the need for native apps (see point 2 above). Even Google who are creating an entirely web based OS (ChromeOS) don't seem to be looking to get rid of Java/Dalvik for Android based dev.
"code once, run anywhere" is very unlikley for anything but the simplest of apps/functionality.
"Code once, compile for each supported platform then test everywhere" is much more realistic.
I'd recommend focusing your education on what makes a great mobile regardless of platform and looking at web based development.
1: Native. It will always be preferred, as it is the most convenient type of app. Personally, I only have one web-app on my phone.
2: The iOS-framework. It is really the largest upside of the native apps. And the fact that they are easily downloadable through the App Store.
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.