Is this possible? I would love to create multiple view controllers for each apple device. I know I could go in and add constraints to make all my labels and buttons line up properly, but after about 4 hours of messing with constraints and watching tutorials, I just can't get it right! Is there any possible way to just create multiple view controllers for each device?
You can, and I have done it before, but I wouldn't recommend it. I did that when AutoLayout was introduced and it all seemed too hard. I returned to AutoLayout when Apple introduced size classes. They make life much easier to have very different constraints for different devices. They also handle things like an iPhone 6 Plus being pretty much as big as an iPad mini.
You could probably spend a lot of time hacking away at making a work around for not being able to use auto-layout but you would definitely end up spending more time in the long run.
I struggled a lot with auto-layout when I started (and still wouldn't say i'm an expert) but after spending some time reading the millions of different tutorials I found it much easier.
It's difficult to recommend different sources for training material like this because everyone has a different preferred style. It's easy to recommend the official Apple docs (Auto Layout: https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/AutolayoutPG/index.html) but they can be so verbose that frankly, you end up getting bored and/or daunted so give up. Some people love youtube videos and some love blogs.
It's up to you to find a guide that helps but if you come back on Stack overflow with clearly explained, small and simple examples of UI elements that you are trying to manage with auto layout then people might try and explain what approach you should take and these instructions will come in different formats.
Related
I've done a bit of iPhone development (3 apps in the appstore currently) but the interface has been pretty plain. I've used the stock components for the most part (UITableViewController, etc.) with a little bit of customization, but for the most part everything looks pretty generic. I'd like to get started developing apps with a richer user interface, but haven't found any good resources to get me started.
What resources have you all come across that outline how to create more advanced iOS interfaces (both iPhone and iPad)? Books? Blog entries? Just looking at the apps I have installed right now, some of the interfaces I've been very impressed with are the ESPN Score Center, XFINITY TV, Facebook, etc.
What about 3rd party interface component libraries? Are there any you recommend that provide more advanced interface components than those in the stock iOS library?
I'd love to take a look at any resources that you recommend for getting started.
I love Ray Wenderlich's tutorials. He's got one on Core Graphics which allows you to draw your own Table Views with headers, buttons, and bezier-curved footers!
Here's a little secret that often gets overlooked: a lot of the cool UI elements you see are stock Apple elements that have been customised to the brink of no return.
The main reason for this is Apple have put a lot of time and effort into making components that just plain work. A UIScrollView, for example, has had many more combined hours of testing than any app you write could hope to achieve.
The trick is to know exactly how to customise elements. A UITabBar is a good example: I've seen several apps that use their own custom tab bars. The problem is, often they don't handle edge cases particularly well. You might have issues if somebody tries to hit two items at the same time (I've actually seen an app that used their own implementation of a tab-bar crash if you pressed two items at the same time).
But if you use Apple's UITabBarController and either subclass, categorise, or otherwise overload it to get the customisation you want, you get a lot of the low-level event handling stuff for free.
You would be amazed with what you can do with a UITableViewController, and you get things like view recycling for free (some of the apps I've worked on have things like independent cell resizing, customised animation of cells, horizontal implementations of a tableview, etc).
Not a particularly useful answer, I grant you, but the point I want to get across here is once you've designed your kick-ass UI step back and consider what can be achieved with the existing toolset before rolling your own. You'll thank me when you come to bug fixing!
I also like Three20. Until now I didn't use it in my projects, but I played with it. And there's some really cool stuff in it. ;-) I think that's one way to extend your standard User Interfaces.
Another really cool part is designing your own elements. I like this really. Because you then have in your App something nobody else has. :-D
I've started looking into using Opacity for Mac, it's a pretty neat desktop application where you can generate your own graphical elements (buttons, switches, icons, etc) and then automatically generate the CocoaTouch / Quartz2D classes and headers to drop in your app ... Some elements work best when they're natively drawn on the device, rather than stored/loaded as pngs, or whatever. Moreover, you get #2x Retina display support for free. While not an interface dress-up framework, the fact that it generates Quartz2D code for you makes this a real contender for anyone who's remotely graphically creative but short on complex 2D programming skills.
Speaking of beautiful interfaces, if you're looking for inspiration or actual graphical elements to put in your interface, I frequently get some great ideas at 365psd ... they actually provide the Photoshop documents to reproduce some eye dropping UI goods, for FREE. Some places may just give you a PNG, but this does little good if you want to scale it (#2x or iPad) or customize it to fit your needs. It's like open source for graphical UI design.
I need to implement cover flow in our iphone app. Our app need to display images from server. We already have webservice to return list of pictures. Number of pictures will grow over time to 1000s of pictures.
Here I need your help to decide which library is good for my situation without any memory issues. and any experiences you have in similar scenario.
I appreciate any input you can give in my scenario
Here is list of libraries in mind.
tapkul
OpenFlow
FlowCover
Please help deciding which library to use and
I can't help on the issue of which library is best to use, but be aware apps have been rejected in the past for doing including cover-flow like features.
If you really must include cover-flow functionality, I'd recommend you write a little test app with each of the available libraries and see which fits your requirements the best. You might also try memory profiling the different solutions and see which consumes the least resources.
There probably isn't a "one size fits all" answer to this question, as everyone's requirements will be slightly different.
I want to use three20's TTThumbsView & TTPhotoView to build something like Grindr. Instead of (1) subclassing these classes, I'd prefer to (2) analyze them and build take the necessary code & tweak it accordingly. Why? Because my concern is that option (1) will increase the download size of our app & slow it's performance. (Another thing I want to ues is three20's caching, but I don't really understand it because right now we're using Core Data. How does three20 caching work?)
If I'm only using part of three20, when I compile the app, will it also build in the other code that's not being used? Or will it leave it out? If it leaves it out, then that gives me some hope that maybe option (1) won't make the app a lot larger to download.
In terms of performance (speed). Will three20 run fast? There's a lot of subclassing going on. Doesn't that slow things down? The Facebook iPhone app seems pretty good, and that uses three20, right?
What do you think?
Thanks!
Matt
There's quite a few questions here:
Analysing the three20 code: People often try this, but it seems not many people have success with this. Here's an example of one project that gave up: http://github.com/enormego/PhotoViewer (the history is all in git I believe, so you can go back and see what they achieved before they gave up)
Three20 caching: can't help you there; you might want to ask a separate question about that. Generally it's best to only ask one question per question :)
Size of three20: I believe these views have a lot of dependencies other three20 classes, so whilst only the necessary code is built in, that's actually quite a lot of code.
Speed: Yep, it's what the iphone facebook uses, so you should be fine there. In fact that's the main reason people use three20 - it's very difficult to do a fast, good photoviewer, and three20 is the only open source project I'm aware of that has done it.
I was wondering if anyone knew of a simple way to implement graphing in an iPhone/iPad application. I've spent quite a bit of time googling and can't seem to find any sort of a solution. Maybe I'm just searching with the wrong terms since a lot of consumers are asking about "graphing" in terms of using their applications, not developing them, the search-space is rather polluted.
It seems like a lot of iPad/iPhone applications have embedded graphs... and I can't imagine that every developer has invented their own graphing engine from the ground up. Or, maybe they have... Does anyone have any suggestions?
Core Plot is one popular option.
I have herd wonders about core plot but for myself i wrote a graph View Class which creates a standard graph.
Have a look
http://sebkade.wordpress.com/2010/05/06/basic-graph-class-for-iphone/
hope it helps
From my experience graphs are best done through UIWebView's and then written in HTML/JavaScript - there are many great html/javascript libraries for graphings. Personally, I like
http://www.highcharts.com
but these exist as well.
http://www.sencha.com/products/touch/charts
https://developers.google.com/chart/
http://www.zingchart.com/#welcome
Are there any guidelines on pitfalls to avoid while developing iPhone applications?
Sure, thousands. The same is true for any software development. Unfortunately, the easiest way to enumerate them is to write them down on a sheet of paper while waiting for a friendly soul to release you from the one you just fell into.
However:
Don't try to reinvent the wheel. The iPhone API is very complete -- you just have to LOOK for the facility you need. Things are NOT always implemented the way you would expect. Read the guides, carefully. Look at the tutorials and analyze how they work. (Try changing a line here or there in the tutorial to see what difference the change makes.) The single biggest mistake I have made in 1 year of iPhone development is not trying hard enough to find the iPhone way of doing something.
Don't ignore memory management; master it early and often. Use the Object Allocation and Leaks tools in Instruments to check for memory leaks frequently. I'd recommend checking after you complete each feature or view; more often than that if you keep finding bugs. Eventually you may understand it so well you can stop doing this.
Don't just use the default build settings. Play around with them to understand what they do. Figure out certification and distribution. GET INTO THE DEVELOPER PROGRAM QUICKLY -- it can take a while to push through that pipeline. [ AND when you get that notification that you need to renew, get it on instantly -- there have been problems with that process. ]
Don't neglect to read the Human Interface Guidelines (HIG) carefully. If they say not to do something -- DON'T DO IT. Apple will reject applications that misuse their iconography.
Don't stint on marketing. Yes, the App Store puts your app in front of millions of people... In theory. But the odds of getting front-paged are slim. There are a lot of great apps on the App Store that haven't sold much because no one knows about them.
Don't rest on your laurels. If a new technology comes out, find out if it makes your job easier; if it does, take the time to learn it. Personal example: I'm just now trying to switch from SQLite-based data management to Core Data, because I was in a hurry at the time I started my most recent project; now I wish I had slowed down and thought about it.
Don't go into your design thinking (for example) "How do I implement my concept with a table view?" It's true that table views are natural for many informational and utility applications, but don't be constrained. Instead, think about what users will want to be able to do, how you can make it easier for them -- put things together that will be used together, etc. If you've never explored the concept of Use Cases, read up on them.
Don't hesitate to build composite views. Many of the questions I have seen here on Stack Overflow have to do with putting a toolbar at the top of a table, or having an image in the background of a text field. I understand the desire to do things the easy way, and as I state in #1 above, if there is an easy way, use it. But in many cases the solution is just to layer a couple of views with appropriate placement and transparency.
Think about what might be Apple-approved from the start.
App Rejected is one of several useful sites to help understand Apple's mostly undocumented standards. (One more.) (A previous question on app store rejection reasons.)
A few quick examples:
Using a UIWebView can get your app a 17+ rating.
Coding with an undocumented/private API = rejected
Version number < 1.0 might= rejected
Not enough feedback about network success/fail = rejected
Too much network use = rejected
Clearly limited free version vs full version = rejected
The word 'iPhone' in the app name = rejected
The above links contain many more examples, and more details about those examples.
Don't neglect the programming guides. While the documentation is quite extensive, the programming guides contains a veritable trove of useful tips and "insider" information that simply cannot be gleaned from reading method definitions. I spend just as much time reading the guides for a technology (say, Core Data) as I do actually implementing it.
Don't assume you know what a method does. If you have any degree of doubt about the functionality of a method, it is well worth your time to go look it up in the documentation to verify.
Wonderful examples from #Amagrammer above.
I would love to add that the first place to start is iPhone development is Photoshop. This is still the best advice I can give to anyone who is starting out. I now use OmniGraffle because it has awesome stencil templates.
What I find is that even for super simple app's, draw up your prototype and look for usability issues and work flow issues. It is 100x quicker to redraw your app than re-code it. I have fallen into this trap numerous times and now actually draw up some pretty simple functionality to see what it will look and feel like.
This advice will save you 10s maybe even 100s of hours in hopefully getting your app right first time and getting you to think through what the issues are. Throwing away code sucks and I have done it not because the code was bad but because it made the usability or solution worse. I think the best of us end up throwing code away and prototyping your design definitely will help in having to RTFM for something you did not have to build in the first place.
If you don't have an great designer, and can't do great design by yourself, then don't even start iPhone app development. This rule only applies if you want/need to make money with your apps.